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 > >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. > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Wed Jan 24 08:11:05 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA26992 for ietf-whois-bks; Wed, 24 Jan 2001 08:11:05 -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 IAA26987 for ; Wed, 24 Jan 2001 08:11:02 -0800 (PST) Received: from jamessonyvaio (unknown [212.45.40.98]) by mail.i-dns.net (Postfix) with SMTP id C90FEFFC01; Thu, 25 Jan 2001 00:17:05 +0800 (SGT) Message-ID: <090501c08620$ea140570$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Eric Brunner-Williams in Portland Maine" Cc: References: <200101241538.f0OFcIn08736@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Thu, 25 Jan 2001 00:15:44 +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: I am just stating generic privacy concern. I dont have any strong motivation in either way. I also understand there are various legistration and policy wrt to this sort of stuff and it is probably too simple to say to-do-or-not-to-do. I suppose it will various from different implementation and deployment and under what justistration. But I think this is one of the example whereby it is probably bad idea for engineers to decide. What we need to come up with is a protocol which can handle either with audit trail or without. -James Seng ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" To: Cc: Sent: Wednesday, January 24, 2001 11:38 PM Subject: Re: Merging RRP and Whois > > ... 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 08:14:15 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27103 for ietf-whois-bks; Wed, 24 Jan 2001 08:14:15 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27099 for ; Wed, 24 Jan 2001 08:14:14 -0800 (PST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA08711; Wed, 24 Jan 2001 08:19:14 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f0OGJAI02136; Wed, 24 Jan 2001 08:19:10 -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 IAA21546; Wed, 24 Jan 2001 08:18:57 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010124111158.J24903@register.com> References: <200101240243.f0O2h2n07024@nic-naa.net> <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> <20010124111158.J24903@register.com> Date: Wed, 24 Jan 2001 17:18:53 +0100 To: George Belotsky , Edward Lewis From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Merging RRP and Whois Cc: James Seng/Personal , Eric Brunner-Williams in Portland Maine , Karl Auerbach , ietf-provreg@cafax.se, ietf-whois@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11.11 -0500 01-01-24, George Belotsky wrote: >It very important to keep in mind that a _protocol_ is being created >here. As this thread is cross-posted between two mailing lists, you should be more specific than saying "here". paf From owner-ietf-whois Wed Jan 24 08:19:40 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27285 for ietf-whois-bks; Wed, 24 Jan 2001 08:19:40 -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 IAA27281 for ; Wed, 24 Jan 2001 08:19:38 -0800 (PST) Received: from jamessonyvaio (unknown [212.45.40.98]) by mail.i-dns.net (Postfix) with SMTP id 710F1FFC01; Thu, 25 Jan 2001 00:25:41 +0800 (SGT) Message-ID: <093201c08622$1d92e4b0$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: "James Seng/Personal" , "Eric Brunner-Williams in Portland Maine" Cc: References: <200101241538.f0OFcIn08736@nic-naa.net> <090501c08620$ea140570$06272dd4@jamessonyvaio> Subject: Re: Merging RRP and Whois Date: Thu, 25 Jan 2001 00:24:21 +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: *sigh* Jetlag..i need sleep. Sorry for the typo and grammar mistakes. > I am just stating generic privacy concern. I dont have any strong > motivation in either way. s/generic/general/ > I also understand there are various legistration and policy wrt to this > sort of stuff and it is probably too simple to say to-do-or-not-to-do. I > suppose it will various from different implementation and deployment and > under what justistration. s/various/vary/ > But I think this is one of the example whereby it is probably bad idea > for engineers to decide. What we need to come up with is a protocol > which can handle either with audit trail or without. > > -James Seng -James "going to bed" Seng From owner-ietf-whois Wed Jan 24 08:16:40 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA27211 for ietf-whois-bks; Wed, 24 Jan 2001 08:16:40 -0800 (PST) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27204 for ; Wed, 24 Jan 2001 08:16:39 -0800 (PST) Received: (qmail 23244 invoked from network); 24 Jan 2001 16:25:27 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 24 Jan 2001 16:25:27 -0000 From: "Paul George" To: , Subject: RE: Merging RRP and Whois Date: Wed, 24 Jan 2001 11:22:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010124111158.J24903@register.com> Importance: Normal 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: Very well said George, however, if this truly is a generic protocol for the registration of any kind of object, how does the whois functionality figure into that? Isn't whois simply a means of looking up Internet domain name information? If it is more than that, than perhaps we can think about incorporating it into the protocol, but if it is specifically targeted toward internet domain info, then it should be left out. Paul George SARAF Software Solutions (703)538-5666 x234 -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On Behalf Of George Belotsky Sent: Wednesday, January 24, 2001 11:12 AM 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 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 > >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. > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Wed Jan 24 08:24:54 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA27534 for ietf-whois-bks; Wed, 24 Jan 2001 08:24:54 -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 IAA27528 for ; Wed, 24 Jan 2001 08:24:52 -0800 (PST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14LSoy-0002u0-00; Wed, 24 Jan 2001 17:30:56 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Paul George" Cc: , Subject: RE: Merging RRP and Whois References: <20010124111158.J24903@register.com> Message-Id: Date: Wed, 24 Jan 2001 17:30:56 +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Isn't whois simply a means of looking up Internet domain name > information? no it is not. while the domain indu$try uses he protocol, many others do too. and they have just as legitimate claims to its functionality as the domain exploition indu$try. randy From owner-ietf-whois Wed Jan 24 08:33:20 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28067 for ietf-whois-bks; Wed, 24 Jan 2001 08:33:20 -0800 (PST) Received: from ns1.saraf.net (ns1.saraf.com [207.226.147.228]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28062 for ; Wed, 24 Jan 2001 08:33:19 -0800 (PST) Received: (qmail 23612 invoked from network); 24 Jan 2001 16:42:07 -0000 Received: from unknown (HELO PGEORGE) (63.217.189.115) by ns1.saraf.net with SMTP; 24 Jan 2001 16:42:07 -0000 From: "Paul George" To: , Subject: RE: Merging RRP and Whois Date: Wed, 24 Jan 2001 11:39:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal 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: Fair enough, thanks for the info Randy. But I think my question is still valid. Does "whois" have a valid place in a generic regsitry/registrar protocol? Will ALL registration systems need "whois" functionality? Okay, if they don't need it, then they don't have to implement that part, but that could be said for a million other little bits of functionality..... Even though I think of any right now, I'm sure someone else can. :-) The fundemental question is : Is 'whois' an integral part of a protocol that is intended to provide a means for the registration of objects? IMHO, I think it is not. And I hope we can move forward on this soon. Paul -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Wednesday, January 24, 2001 11:31 AM To: Paul George Cc: ietf-provreg@cafax.se; ietf-whois@imc.org Subject: RE: Merging RRP and Whois > Isn't whois simply a means of looking up Internet domain name > information? no it is not. while the domain indu$try uses he protocol, many others do too. and they have just as legitimate claims to its functionality as the domain exploition indu$try. randy From owner-ietf-whois Wed Jan 24 09:15:12 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA29678 for ietf-whois-bks; Wed, 24 Jan 2001 09:15:12 -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 JAA29672 for ; Wed, 24 Jan 2001 09:15:03 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14LTa6-0003qz-00; Wed, 24 Jan 2001 12:19:38 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Wed, 24 Jan 2001 12:19:38 -0500 Date: Wed, 24 Jan 2001 12:19:38 -0500 From: George Belotsky To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Edward Lewis , 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: <20010124121938.K24903@register.com> References: <200101240243.f0O2h2n07024@nic-naa.net> <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> <20010124111158.J24903@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 Wed, Jan 24, 2001 at 05:18:53PM +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Good idea. Because the RRP group seems to be further along, 'here' applies more to the RRP. It is partially applicable to the Whois as well. Lots of issues have been raised on the two lists, including privacy and authentication. Of course, the policy is likely to be quite complex, and determined by laws, customs, etc. in various parts of the world. We must create a mechanism that can support the large variety of policies that are likely to emerge sooner or later. Because of the complexities involved, it would be best to create a single, evolving mechanism. In order to do so, it is very helpful to view the registration system as a number of object repositories (which may contain things other than domain names), with each repository being managed by a registry. The object repositories should all support a single interface, which allows for a variety of users. These include superusers (i.e. the registry performing maintenance) and privileged users (i.e. the registrars registering, modifying, deleting and transferring objects) as well as users with only moderate privileges (e.g. paid subscribers to an advanced Whois service) and minimally privileged users (i.e. users of the public Whois). If we start separating users into different privilege categories by writing a different protocol for each category, how many protocols will we end up with? Clearly, a single protocol is the most logical solution. George. On Wed, Jan 24, 2001 at 05:18:53PM +0100, Patrik Fältström wrote: > At 11.11 -0500 01-01-24, George Belotsky wrote: > >It very important to keep in mind that a _protocol_ is being created > >here. > > As this thread is cross-posted between two mailing lists, you should > be more specific than saying "here". > > paf > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Wed Jan 24 09:30:35 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA00102 for ietf-whois-bks; Wed, 24 Jan 2001 09:30:35 -0800 (PST) Received: from joanna.william.org (mail@joanna.william.org [195.153.6.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29997 for ; Wed, 24 Jan 2001 09:30:33 -0800 (PST) Received: from mjo by joanna.william.org with local (Exim 3.16 #1) id 14LTp8-0007YE-00 (Debian); Wed, 24 Jan 2001 17:35:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Jan 2001 17:35:10 +0000 (GMT) To: George Belotsky Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Edward Lewis , 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 In-Reply-To: <20010124121938.K24903@register.com> References: <200101240243.f0O2h2n07024@nic-naa.net> <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> <20010124111158.J24903@register.com> <20010124121938.K24903@register.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14959.4087.191697.458539@joanna.william.org> From: Martin Oldfield Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "George" == George Belotsky writes: -> snip <- George> In order to do so, it is very helpful to view the George> registration system as a number of object repositories George> (which may contain things other than domain names), with George> each repository being managed by a registry. The object George> repositories should all support a single interface, which George> allows for a variety of users. These include superusers George> (i.e. the registry performing maintenance) and privileged George> users (i.e. the registrars registering, modifying, George> deleting and transferring objects) as well as users with George> only moderate privileges (e.g. paid subscribers to an George> advanced Whois service) and minimally privileged users George> (i.e. users of the public Whois). George> If we start separating users into different privilege George> categories by writing a different protocol for each George> category, how many protocols will we end up with? George> Clearly, a single protocol is the most logical solution. Quite so! Presumably besides the notion of a general object registry, we would also need to concoct standard definitions for e.g. a domain, a contact, &c. ? If we don't do this then we'll lose interoperability to a proliferation of different domain definitions. If we're going to embrace such diversity, then would it also be prudent to let each registry publish details of the classes of objects they store, and the access policies which apply to them ? Cheers, -- Martin Oldfield, AdamsNames Ltd. From owner-ietf-whois Wed Jan 24 09:32:01 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA00158 for ietf-whois-bks; Wed, 24 Jan 2001 09:32:01 -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 JAA00148 for ; Wed, 24 Jan 2001 09:32:00 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14LTrG-00065N-00; Wed, 24 Jan 2001 12:37:22 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Wed, 24 Jan 2001 12:37:22 -0500 Date: Wed, 24 Jan 2001 12:37:22 -0500 From: George Belotsky To: Paul George Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010124123722.L24903@register.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pgeorge@saraf.com on Wed, Jan 24, 2001 at 11:39:16AM -0500 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul: The RRP already includes Whois-style functionality. One must be able to view information on objects (domain names for now). It is also clear that the Whois will need a more advanced protocol than what exists today. In the future, a more comprehensive solution will be required. With a little thought now, the RRP, with its extensibility and authentication features, can grow to be that comprehensive solutions. End users and other entities will then use the protcol also, not just registries and registrars. Alternatively, the RRP could become isolated as the comprehensive solution develops, thus placing it firmly on the path to deprecation. It would not take too much effort to simply use the Whois-like features (perhaps with a little extension) of the RRP to provide Whois services to end users. On Wed, Jan 24, 2001 at 11:39:16AM -0500, Paul George wrote: > Fair enough, thanks for the info Randy. But I think my question is still > valid. Does "whois" have a valid place in a generic regsitry/registrar > protocol? Will ALL registration systems need "whois" functionality? Okay, > if they don't need it, then they don't have to implement that part, but that > could be said for a million other little bits of functionality..... Even > though I think of any right now, I'm sure someone else can. :-) > > The fundemental question is : > > Is 'whois' an integral part of a protocol that is intended to provide a > means for the registration of objects? > > IMHO, I think it is not. And I hope we can move forward on this soon. > > Paul > > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, January 24, 2001 11:31 AM > To: Paul George > Cc: ietf-provreg@cafax.se; ietf-whois@imc.org > Subject: RE: Merging RRP and Whois > > > > Isn't whois simply a means of looking up Internet domain name > > information? > > no it is not. while the domain indu$try uses he protocol, many others do > too. and they have just as legitimate claims to its functionality as the > domain exploition indu$try. > > randy > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Wed Jan 24 10:26:58 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02780 for ietf-whois-bks; Wed, 24 Jan 2001 10:26:58 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02776 for ; Wed, 24 Jan 2001 10:26:54 -0800 (PST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA02945; Wed, 24 Jan 2001 10:32:28 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f0OIWO405755; Wed, 24 Jan 2001 10:32:24 -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 KAA25772; Wed, 24 Jan 2001 10:32:12 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <20010124123722.L24903@register.com> References: <20010124123722.L24903@register.com> Date: Wed, 24 Jan 2001 19:25:11 +0100 To: George Belotsky , Paul George From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Merging RRP and Whois Cc: ietf-provreg@cafax.se, ietf-whois@imc.org 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.37 -0500 01-01-24, George Belotsky wrote: >It would not take too much effort to simply use the Whois-like >features (perhaps with a little extension) of the RRP to provide Whois >services to end users. I think this is a VERY interesting path that you should consider seriously! Including anonymous access, and ability for registrants (yes, registrants) to because of data protection laws update whatever is necessary in the registry database in the case of a thick registry. Also, this connection might be needed also for DNSSEC key signing issues... I.e. if you do a protocol, and need overlapping functions, see if you should not do _one_... What goes on port 43 is a completely different story, and it should stay that way. paf -- with my AD hat on as you can see in the signature -- 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 10:32:38 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02952 for ietf-whois-bks; Wed, 24 Jan 2001 10:32:38 -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 KAA02947 for ; Wed, 24 Jan 2001 10:32:34 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14LUlj-0003EF-00; Wed, 24 Jan 2001 13:35:43 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Wed, 24 Jan 2001 13:35:42 -0500 Date: Wed, 24 Jan 2001 13:35:42 -0500 From: George Belotsky To: Martin Oldfield Cc: Patrik Fdltstrvm , Edward Lewis , 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: <20010124133542.M24903@register.com> References: <200101240243.f0O2h2n07024@nic-naa.net> <059701c085bf$13f8e3e0$06272dd4@jamessonyvaio> <20010124111158.J24903@register.com> <20010124121938.K24903@register.com> <14959.4087.191697.458539@joanna.william.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14959.4087.191697.458539@joanna.william.org>; from m@mail.tc on Wed, Jan 24, 2001 at 05:35:10PM +0000 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would expect that some object types (such as ones dealing with domain names) will be fully specified as the result of the current work on the RRP. Some thought should be given to future types -- but just enough to allow the protocol to grow later. Very fortunately, there is no need for too much work on these types now -- otherwise there would be no time to do it. A little can go a long way, however, to ensure the future of the protocol. On Wed, Jan 24, 2001 at 05:35:10PM +0000, Martin Oldfield wrote: > >>>>> "George" == George Belotsky writes: > > -> snip <- > > George> In order to do so, it is very helpful to view the > George> registration system as a number of object repositories > George> (which may contain things other than domain names), with > George> each repository being managed by a registry. The object > George> repositories should all support a single interface, which > George> allows for a variety of users. These include superusers > George> (i.e. the registry performing maintenance) and privileged > George> users (i.e. the registrars registering, modifying, > George> deleting and transferring objects) as well as users with > George> only moderate privileges (e.g. paid subscribers to an > George> advanced Whois service) and minimally privileged users > George> (i.e. users of the public Whois). > > George> If we start separating users into different privilege > George> categories by writing a different protocol for each > George> category, how many protocols will we end up with? > George> Clearly, a single protocol is the most logical solution. > > Quite so! > > Presumably besides the notion of a general object registry, we would > also need to concoct standard definitions for e.g. a domain, a > contact, &c. ? If we don't do this then we'll lose interoperability to > a proliferation of different domain definitions. > > If we're going to embrace such diversity, then would it also be > prudent to let each registry publish details of the classes of objects > they store, and the access policies which apply to them ? > > Cheers, > -- > Martin Oldfield, > AdamsNames Ltd. > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Wed Jan 24 10:53:58 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA04452 for ietf-whois-bks; Wed, 24 Jan 2001 10:53:58 -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 KAA04446 for ; Wed, 24 Jan 2001 10:53:57 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14LV8p-0002mf-00; Wed, 24 Jan 2001 13:59:35 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Wed, 24 Jan 2001 13:59:35 -0500 Date: Wed, 24 Jan 2001 13:59:35 -0500 From: George Belotsky To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Paul George Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010124135935.O24903@register.com> References: <20010124123722.L24903@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 Wed, Jan 24, 2001 at 07:25:11PM +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It would not be necessary to run the new protocol on port 43. The new protocol, however, should become the standard for future Whois-type queries. Backwards compatibility with the current Whois should definitely be maintained. Fortunately, with the current Whois standard this is not a problem. The existing protocol on port 43 can remain as long as needed. All future extensions, however, should be to the new protocol. In this way, we would avoid forcing the development of incompatible and diverging methods for accessing the same data. We would also avoid having to solve twice a large set set of very difficult problems, such as authentication, security, privacy and internationalization. On Wed, Jan 24, 2001 at 07:25:11PM +0100, Patrik Fältström wrote: > At 12.37 -0500 01-01-24, George Belotsky wrote: > >It would not take too much effort to simply use the Whois-like > >features (perhaps with a little extension) of the RRP to provide Whois > >services to end users. > > I think this is a VERY interesting path that you should consider > seriously! Including anonymous access, and ability for registrants > (yes, registrants) to because of data protection laws update whatever > is necessary in the registry database in the case of a thick > registry. Also, this connection might be needed also for DNSSEC key > signing issues... > > I.e. if you do a protocol, and need overlapping functions, see if you > should not do _one_... > > What goes on port 43 is a completely different story, and it should > stay that way. > > paf -- with my AD hat on as you can see in the signature > > > -- > 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 Wed Jan 24 11:43:24 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA10477 for ietf-whois-bks; Wed, 24 Jan 2001 11:43:24 -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 LAA10471 for ; Wed, 24 Jan 2001 11:43:22 -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 14LVuH-0003lb-00; Wed, 24 Jan 2001 14:48:37 -0500 Reply-To: From: "Ross Wm. Rader" To: "George Belotsky" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Paul George" Cc: , Subject: RE: Merging RRP and Whois Date: Wed, 24 Jan 2001 14:50:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010124135935.O24903@register.com> Importance: Normal Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Isn't the RRP (and therefore, won't the EPP likely be) a semi-private protocol, whereas whois is inherently public in nature? < -----Original Message----- < From: owner-ietf-whois@mail.imc.org < [mailto:owner-ietf-whois@mail.imc.org]On Behalf Of George Belotsky < Sent: Wednesday, January 24, 2001 2:00 PM < To: Patrik Fältström; Paul George < Cc: ietf-provreg@cafax.se; ietf-whois@imc.org < Subject: Re: Merging RRP and Whois < < < It would not be necessary to run the new protocol on port 43. The new < protocol, however, should become the standard for future Whois-type < queries. < < Backwards compatibility with the current Whois should definitely be < maintained. Fortunately, with the current Whois standard this is not < a problem. < < The existing protocol on port 43 can remain as long as needed. All < future extensions, however, should be to the new protocol. In this < way, we would avoid forcing the development of incompatible and < diverging methods for accessing the same data. We would also avoid < having to solve twice a large set set of very difficult problems, such < as authentication, security, privacy and internationalization. < < < < On Wed, Jan 24, 2001 at 07:25:11PM +0100, Patrik Fältström wrote: < > At 12.37 -0500 01-01-24, George Belotsky wrote: < > >It would not take too much effort to simply use the Whois-like < > >features (perhaps with a little extension) of the RRP to provide Whois < > >services to end users. < > < > I think this is a VERY interesting path that you should consider < > seriously! Including anonymous access, and ability for registrants < > (yes, registrants) to because of data protection laws update whatever < > is necessary in the registry database in the case of a thick < > registry. Also, this connection might be needed also for DNSSEC key < > signing issues... < > < > I.e. if you do a protocol, and need overlapping functions, see if you < > should not do _one_... < > < > What goes on port 43 is a completely different story, and it should < > stay that way. < > < > paf -- with my AD hat on as you can see in the signature < > < > < > -- < > 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 Wed Jan 24 11:49:10 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA11213 for ietf-whois-bks; Wed, 24 Jan 2001 11:49:10 -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 LAA11207 for ; Wed, 24 Jan 2001 11:49:08 -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 14LVzv-00041R-00; Wed, 24 Jan 2001 14:54:27 -0500 Reply-To: From: "Ross Wm. Rader" To: , "George Belotsky" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Paul George" Cc: , Subject: RE: Merging RRP and Whois Date: Wed, 24 Jan 2001 14:56:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Unfortunately, that didn't make as much sense as I thought it did... What I was trying get at was the there are a number of RRP/EPP implementations that are/will be exclusively private in nature. It *can* be a public implementation, but currently, I know of none. Whois on the other hand is mostly used in a public manner. There are private implementations, but again, most are public. Anyways, my point is that merging the two will lead to a point where one or the other must become more public or more private in nature. In some of the implementations that we manage this would be a good thing, in others, it would be a bad thing. I for one would prefer to keep things a little bit simpler than what this arrangement implies.... < -----Original Message----- < From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se]On < Behalf Of Ross Wm. Rader < Sent: Wednesday, January 24, 2001 2:50 PM < To: George Belotsky; Patrik Fältström; Paul George < Cc: ietf-provreg@cafax.se; ietf-whois@imc.org < Subject: RE: Merging RRP and Whois < < < Isn't the RRP (and therefore, won't the EPP likely be) a semi-private < protocol, whereas whois is inherently public in nature? < < < -----Original Message----- < < From: owner-ietf-whois@mail.imc.org < < [mailto:owner-ietf-whois@mail.imc.org]On Behalf Of George Belotsky < < Sent: Wednesday, January 24, 2001 2:00 PM < < To: Patrik Fältström; Paul George < < Cc: ietf-provreg@cafax.se; ietf-whois@imc.org < < Subject: Re: Merging RRP and Whois < < < < < < It would not be necessary to run the new protocol on port 43. The new < < protocol, however, should become the standard for future Whois-type < < queries. < < < < Backwards compatibility with the current Whois should definitely be < < maintained. Fortunately, with the current Whois standard this is not < < a problem. < < < < The existing protocol on port 43 can remain as long as needed. All < < future extensions, however, should be to the new protocol. In this < < way, we would avoid forcing the development of incompatible and < < diverging methods for accessing the same data. We would also avoid < < having to solve twice a large set set of very difficult problems, such < < as authentication, security, privacy and internationalization. < < < < < < < < On Wed, Jan 24, 2001 at 07:25:11PM +0100, Patrik Fältström wrote: < < > At 12.37 -0500 01-01-24, George Belotsky wrote: < < > >It would not take too much effort to simply use the Whois-like < < > >features (perhaps with a little extension) of the RRP to < provide Whois < < > >services to end users. < < > < < > I think this is a VERY interesting path that you should consider < < > seriously! Including anonymous access, and ability for registrants < < > (yes, registrants) to because of data protection laws < update whatever < < > is necessary in the registry database in the case of a thick < < > registry. Also, this connection might be needed also for DNSSEC key < < > signing issues... < < > < < > I.e. if you do a protocol, and need overlapping functions, < see if you < < > should not do _one_... < < > < < > What goes on port 43 is a completely different story, and it should < < > stay that way. < < > < < > paf -- with my AD hat on as you can see in the signature < < > < < > < < > -- < < > 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 Wed Jan 24 12:07:52 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11734 for ietf-whois-bks; Wed, 24 Jan 2001 12:07:52 -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 MAA11724 for ; Wed, 24 Jan 2001 12:07:48 -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 VAA24063; Wed, 24 Jan 2001 21:14:01 +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 VAA69987; Wed, 24 Jan 2001 21:13:56 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200101242013.VAA69987@bartok.sidn.nl> To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= cc: George Belotsky , Paul George , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-reply-to: Your message of Wed, 24 Jan 2001 19:25:11 +0100. Date: Wed, 24 Jan 2001 21:13:56 +0100 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I.e. if you do a protocol, and need overlapping functions, see if you should not do _one_... What goes on port 43 is a completely different story, and it should stay that way. What is going on on port 43 is indeed a complete different story. Looking at the dicussion going on about what the function of whois should or shouldn't be is an example about of this. But I wonder how big the overlap is really. In the hollenbeck draft the lookup function of whether an object exists is just a small portion of the whole draft. To exagerate a bit, since DNS is does also do lookups, why not add a whois function to it? jaap From owner-ietf-whois Wed Jan 24 12:15:08 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12010 for ietf-whois-bks; Wed, 24 Jan 2001 12:15:08 -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 MAA12003 for ; Wed, 24 Jan 2001 12:15: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 f0OKK1n09745; Wed, 24 Jan 2001 15:20:01 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101242020.f0OKK1n09745@nic-naa.net> To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= cc: George Belotsky , Paul George , 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 19:25:11 +0100." Date: Wed, 24 Jan 2001 15:20:01 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Patrik, Wearing your AD hat you suggest three cases for utility of a unique mechanism (rrp + whois sugar): anonymous access registrant access key management Anonymous read access isn't on my todo list. Non-critical features should be footnoted for the benefit of subsequent requirements gathering parties. Registrant write-access is trivially accomodated via registry access, so it isn't necessary. Why is a common mechanism useful? Registrant key management (as an instance of many things outside the scope of dns registrations) can be handled out-of-band, and need not require registrar participation. Wearing my participant hat I've yet to see a case for an RRP-like mechanism having whois-like semantics. Please have a look at the cpexchange work, we did try to make some progress on all three of these use cases, keeping the several privacy/data protection frameworks in mind, though from a marketer and/or large-sized vertically integrated vendor perspective -- we stll have the same regulatory shoals to work through. Cheers, Eric From owner-ietf-whois Wed Jan 24 12:50:14 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA15984 for ietf-whois-bks; Wed, 24 Jan 2001 12:50:14 -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 MAA15979 for ; Wed, 24 Jan 2001 12:50:13 -0800 (PST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14LWxp-0002xO-00; Wed, 24 Jan 2001 21:56:21 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Paul George" Cc: , Subject: RE: Merging RRP and Whois References: Message-Id: Date: Wed, 24 Jan 2001 21:56:21 +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Fair enough, thanks for the info Randy. But I think my question is still > valid. Does "whois" have a valid place in a generic regsitry/registrar > protocol? we can't know that until the requirements of the application are well and clearly stated. until then, all else is hot air. randy From owner-ietf-whois Wed Jan 24 15:29:36 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA25887 for ietf-whois-bks; Wed, 24 Jan 2001 15:29:36 -0800 (PST) Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25883 for ; Wed, 24 Jan 2001 15:29:33 -0800 (PST) Received: from dstc.edu.au (sunburn.dstc.edu.au [130.102.176.16]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id f0ONZJx28140 for ; Thu, 25 Jan 2001 09:35:19 +1000 (EST) To: ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-reply-to: Your message of "Wed, 24 Jan 2001 09:15:19 EST." <200101241415.f0OEFJn08525@nic-naa.net> Date: Thu, 25 Jan 2001 09:35:46 +1000 Message-ID: <23806.980379346@dstc.edu.au> From: George Michaelson Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [I trimmed the to/cc. Is this no longer de rigeur in replys? nobody else seems to. -ggm] 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. Not suprisingly national registries are also considering ICANN processes because the players in commercialized or competitively tendered national registries tend to also be ICANN active people. Thus, in consideration of a new competitive regime here in Australia, RRP has been mentioned and so has whois, public interest data, escrow, shadowing/sharing... A registry operator may seek to meet both the ICANN service requirements where applicable, and other requirements where applicable. And may also seek to refine other requirements in line with ICANN or vice-versa. In other words, convergeance here is in the interests of some people. cheers -George -- George Michaelson | DSTC Pty Ltd Email: ggm@dstc.edu.au | University of Qld 4072 Phone: +61 7 3365 4310 | Australia Fax: +61 7 3365 4311 | http://www.dstc.edu.au From owner-ietf-whois Wed Jan 24 16:45:29 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA29014 for ietf-whois-bks; Wed, 24 Jan 2001 16:45:29 -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 QAA29010 for ; Wed, 24 Jan 2001 16:45:28 -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 f0P0obn10397; Wed, 24 Jan 2001 19:50:37 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101250050.f0P0obn10397@nic-naa.net> To: George Michaelson cc: ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Thu, 25 Jan 2001 09:35:46 +1000." <23806.980379346@dstc.edu.au> Date: Wed, 24 Jan 2001 19:50:37 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I guess I was too obscure. ICANN defines a particular jurisdiction. Other jurisdictional considerations exist. Some nation-states may incorporate by reference the ICANN model. Some nation-states will not. "Convergence", at least in the area of data protection, is not something to put in the critical path, either of a 2001 RRP, or a someday-successor to whois:43. Of course there are those who would like to legislate away the occasional nation-state, but it isn't scheduled for IETF50. I'm not convinced of the utility or necessity, and quite certain of the converse, so lets leave the question to the hum-test, neh? Eric From owner-ietf-whois Wed Jan 24 17:06:17 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA29447 for ietf-whois-bks; Wed, 24 Jan 2001 17:06:17 -0800 (PST) Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA29439 for ; Wed, 24 Jan 2001 17:06:14 -0800 (PST) Received: from dstc.edu.au (sunburn.dstc.edu.au [130.102.176.16]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id f0P1Bpx05769; Thu, 25 Jan 2001 11:11:51 +1000 (EST) To: Eric Brunner-Williams in Portland Maine cc: ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-reply-to: Your message of "Wed, 24 Jan 2001 19:50:37 EST." <200101250050.f0P0obn10397@nic-naa.net> Date: Thu, 25 Jan 2001 11:12:18 +1000 Message-ID: <25190.980385138@dstc.edu.au> From: George Michaelson Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I guess I was too obscure. Yes. I didn't realize your comments were about jurisdiction. I thought they were about technology. I was trying to say some players have technology/cost issues which push them to considering other peoples protocols and work, to leverage the advantage of commonalities. Like, this is not unusual. I'm not convinced of the utility or necessity, and quite certain of the converse, so lets leave the question to the hum-test, neh? Sure. works for me. But don't expect this to go away in the n+1 fora outside of the IETF, because the topic isn't going to die by wish fullfilment. Outside of IETF, we have to make decisions what we require registry to do, and how we require them to do it. I'm in the role of a panel co-chair considering process in .AU - If a commercial entity comes to us, seeking to leverage their investment in RRP I have to at least try and consider that on its merits. Taint from ICANN or jurisdiction isn't the issue: reducing public infrastructure overheads and retaining stuff like the anti-spam volume checks, and the use of whois or some other datarep to escrow data for re-allocation if the tender switches elsewhere does matter. So I'm commenting here because I'm going to have to try and sift this kind of stuff when specifying requirements for parties looking to tender into the registry provision business. If one of them (and they have) says they want to use RRP, I have to understand if thats as well as whois, or in place of whois. And if they claim 'ietf compliance' Its good to know what that might mean. -cheers -George -- George Michaelson | DSTC Pty Ltd Email: ggm@dstc.edu.au | University of Qld 4072 Phone: +61 7 3365 4310 | Australia Fax: +61 7 3365 4311 | http://www.dstc.edu.au From owner-ietf-whois Wed Jan 24 20:55:33 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA05518 for ietf-whois-bks; Wed, 24 Jan 2001 20:55:33 -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 UAA05510 for ; Wed, 24 Jan 2001 20:55:27 -0800 (PST) Received: from jamessonyvaio (unknown [212.45.39.146]) by mail.i-dns.net (Postfix) with SMTP id 2781BFFC01; Thu, 25 Jan 2001 13:01:18 +0800 (SGT) Message-ID: <0afa01c0868b$ad5aa970$06272dd4@jamessonyvaio> From: "James Seng/Personal" To: =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= , "Jaap Akkerhuis" Cc: "George Belotsky" , "Paul George" , , References: <200101242013.VAA69987@bartok.sidn.nl> Subject: Re: Merging RRP and Whois Date: Thu, 25 Jan 2001 12:59:59 +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: Please don't go there... james > To exagerate a bit, since DNS is does also do lookups, why not add > a whois function to it? From owner-ietf-whois Wed Jan 24 21:06:14 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA05749 for ietf-whois-bks; Wed, 24 Jan 2001 21:06:14 -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 VAA05743 for ; Wed, 24 Jan 2001 21:06:09 -0800 (PST) Received: from jamessonyvaio (unknown [212.45.39.146]) by mail.i-dns.net (Postfix) with SMTP id 85026FFC09; Thu, 25 Jan 2001 13:12:12 +0800 (SGT) Message-ID: <0b2401c0868d$33fe04d0$06272dd4@jamessonyvaio> From: "James Seng" To: =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= , "Eric Brunner-Williams in Portland Maine" Cc: "George Belotsky" , "Paul George" , , , References: <200101242020.f0OKK1n09745@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Thu, 25 Jan 2001 13:10:52 +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, Once again, your problem is only a subset of the issue we dealing with. > Anonymous read access isn't on my todo list. Non-critical features should > be footnoted for the benefit of subsequent requirements gathering parties. Whois, by its current nature, is anonymous read-access. The most info you can extract would be the IP address of the querier. > Registrant write-access is trivially accomodated via registry access, so > it isn't necessary. Why is a common mechanism useful? No, it is neccessary for key-management whereby registrant _may_ have to contact the registry directly. And in domain names context, due to different policy, the "thickness" of the registrant data may sometimes be at the registry, sometimes at the registrar sometimes at the reseller etc. There need to be a way for registrant to inform all of them about their privacy consideration, and bear in mind this would somehow interact with the different local data privacy laws in various countries depending where the thickeness resident. > Registrant key management (as an instance of many things outside the scope > of dns registrations) can be handled out-of-band, and need not require > registrar participation. "out-of-band" means? If it is manual, it is kind of stupid considering we are trying to reduce man-power. If it is automatic, do you suggest we have another set of protocol to handle it? Either way, I think you are too short-sighted here. > Wearing my participant hat I've yet to see a case for an RRP-like mechanism > having whois-like semantics. Please have a look at the cpexchange work, we > did try to make some progress on all three of these use cases, keeping the > several privacy/data protection frameworks in mind, though from a marketer > and/or large-sized vertically integrated vendor perspective -- we stll have > the same regulatory shoals to work through. As an implementor who has tried to integrate WHOIS into RRP (our registry allows registrant to do whois-like queries thru our RRP), I can understand why you say this. It does makes life easier as software developers since it is one source, one semantic. It is unfortunate you can't hear the horrible yell of joy from my operation folk. -James Seng From owner-ietf-whois Wed Jan 24 22:08:47 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA07310 for ietf-whois-bks; Wed, 24 Jan 2001 22:08:47 -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 WAA07305 for ; Wed, 24 Jan 2001 22:08:45 -0800 (PST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14LfgR-00039K-00; Thu, 25 Jan 2001 07:14:59 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mark Kosters Cc: ietf-whois@imc.org Subject: Re: Merging RRP and Whois References: <20010124104922.D780@slam.admin.cto.netsol.com> Message-Id: Date: Thu, 25 Jan 2001 07:14:59 +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > 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? tradition is nice. if it works. as i have not seen clear requirements for domain assignment, it would be more foolish than usual for me to say, yes? randy From owner-ietf-whois Thu Jan 25 06:48:56 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA01311 for ietf-whois-bks; Thu, 25 Jan 2001 06:48:56 -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 GAA01307 for ; Thu, 25 Jan 2001 06:48:54 -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 f0PErbn12099; Thu, 25 Jan 2001 09:53:37 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101251453.f0PErbn12099@nic-naa.net> To: "James Seng" cc: =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= , "Eric Brunner-Williams in Portland Maine" , "George Belotsky" , "Paul George" , ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Merging RRP and Whois In-Reply-To: Your message of "Thu, 25 Jan 2001 13:10:52 +0800." <0b2401c0868d$33fe04d0$06272dd4@jamessonyvaio> Date: Thu, 25 Jan 2001 09:53:37 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: James, Patrik (AD hatted) wrote about cases for extending the RRP. I replied, in part pointing out that anonymous read access isn't on my todo list, or any registry provisioning requirement I have seen. Perhaps you have misunderstood the exchange. Perhaps I misunderstand your commentary. The second part of my reply concerned the role of the registrar. In the case Patrik offered, registrant modification of registry data without interposition by a registrar, several issues arise which don't in the interposition case: Technical issues (non-exhaustive): scaling the RRP aaa mechanisms, scoping the registry access mechanism, Economic issues (non-exhaustive): scoping registrar liability and compensation, Public Policy issues (non-exhaustive): registry competition with registrars As I mentioned, where the write-access is registrar-mediated, the aaa and access mechanism issues are simplified, and other issues don't arise in addition to those which already exist for the registrar-mediated service. In your commentary you mentioned privacy as a motivation, positing the "thickness" of the data, and presumably the policed data, in the care of several actors -- you listed registry, registrar, and reseller, then placed the duty to notice any of the registrant's privacy policy (which may be something other than a preference or a consideration, and need not be static) upon the registrant, to necessitate registrant participation in a registrar-registry service model. Since the actors having the roles of registrant, reseller, registrar, and registry are not fixed, in particular, the reseller and registrar parts may be fluid, and the registrant's policy not required to be fixed, if the protocol does not also notice the registrant of changes in the upstream service providors, then the direct access (to intermediaries!) mechanism fails to meet the sufficiency test for policing of provisioned data. Non-necessity was my point to Patrik, non-sufficiency my point to you (James). The third part of my reply concerned Patrik's speculation w.r.t. dnssec and key management. "Out of band" means by another mechanism. Eric From owner-ietf-whois Thu Jan 25 09:38:21 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14477 for ietf-whois-bks; Thu, 25 Jan 2001 09:38:21 -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 JAA14452 for ; Thu, 25 Jan 2001 09:38:14 -0800 (PST) Received: from jamessonyvaio (unknown [212.45.39.50]) by mail.i-dns.net (Postfix) with SMTP id B2605FFC04; Fri, 26 Jan 2001 01:44:21 +0800 (SGT) Message-ID: <003701c086f6$46260ef0$32272dd4@jamessonyvaio> From: "James Seng/Personal" To: "Eric Brunner-Williams in Portland Maine" Cc: , References: <200101251453.f0PErbn12099@nic-naa.net> Subject: Re: Merging RRP and Whois Date: Fri, 26 Jan 2001 01:43:02 +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, > Patrik (AD hatted) wrote about cases for extending the RRP. I replied, > in part pointing out that anonymous read access isn't on my todo list, > or any registry provisioning requirement I have seen. Perhaps you have > misunderstood the exchange. Perhaps I misunderstand your commentary. If you are having a private conversation with Patrik then please do it offline. If you post it to the list, then be prepare for disagreement, from anyone on the list. Your TODO list is only _part_ of the consideration. I am certain the group welcome your input but this does not mean the group are here to solve your problem only. (third time I am putting this down. please...do I have to do it 4th time?). > The second part of my reply concerned the role of the registrar. In the > case Patrik offered, registrant modification of registry data without > interposition by a registrar, several issues arise which don't in the > interposition case: [snip] I am not going to disagree with your analysis here because that is true now. 10 years ago, no one see any business in domain names. IANA do it as a matter-of-fact. 3 years ago, people start tieing down the NSI and wanted a share of the $$. Can you predict what will happen 3 or 5 years later? Will your issues remains true? So, please see beyond immediate needs. There are greater issues at large. And enforcing certain policy onto a protocol is probably the worst mistake we could make. And IMHO, there is no technical reason to forbid a registrant to access the registry directly, should certain policy or technical reqirement needs it. I am not saying the registry SHOULD (or MUST) do this, but that they MAY. > Since the actors having the roles of registrant, reseller, registrar, and > registry are not fixed, in particular, the reseller and registrar parts > may be fluid, and the registrant's policy not required to be fixed, if the > protocol does not also notice the registrant of changes in the upstream > service providors, then the direct access (to intermediaries!) mechanism > fails to meet the sufficiency test for policing of provisioned data. Perhaps. Perhaps not. I don't think we reach a stage whereby we know the protocol enough to say this. It is certainly something we need to consider while desiging. > The third part of my reply concerned Patrik's speculation w.r.t. dnssec > and key management. "Out of band" means by another mechanism. Great. I look forward to the day we repeat this all over again in some other WG formed to solve this "out of band" registration problem. -James Seng From owner-ietf-whois Thu Jan 25 15:13:25 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10147 for ietf-whois-bks; Thu, 25 Jan 2001 15:13:25 -0800 (PST) Received: from alliance.globalnetlink.com (root@alliance.globalnetlink.com [208.185.70.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10143 for ; Thu, 25 Jan 2001 15:13:23 -0800 (PST) From: budi@alliance.globalnetlink.com Received: from pentium3 (ppp24d.dialin.elga.net.id [202.173.64.152]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id SAA20445; Thu, 25 Jan 2001 18:00:20 -0600 Message-Id: <200101260000.SAA20445@alliance.globalnetlink.com> To: Date: Fri, 26 Jan 2001 06:22:39 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Merging RRP and Whois CC: In-reply-to: <003701c086f6$46260ef0$32272dd4@jamessonyvaio> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > And IMHO, there is no technical reason to forbid a registrant to access > the registry directly, should certain policy or technical reqirement > needs it. I am not saying the registry SHOULD (or MUST) do this, but > that they MAY. Agree. Why can't we simplify the requirement, ie. the system (protocol/implementation) should only allow *one* entity to access (read/write/update) to a record? This *one* entity could be registrar, reseller, registrant, registry, whatever. As long it is *one* entity. (That way it can accomodate any business model.) -- budi -- Homepage: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id From owner-ietf-whois Fri Jan 26 00:53:25 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA14975 for ietf-whois-bks; Fri, 26 Jan 2001 00:53:25 -0800 (PST) Received: from smtp.denic.de (denics1.denic.de [194.246.96.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA14970 for ; Fri, 26 Jan 2001 00:53:22 -0800 (PST) Received: from notes.denic.de (frankfurt.denic.de [194.246.96.101]) by smtp.denic.de with esmtp id 14M4iu-0000gy-00; Fri, 26 Jan 2001 09:59:12 +0100 To: budi@alliance.globalnetlink.com Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Re: Merging RRP and Whois X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: From: "Sabine Dolderer/Denic" Date: Fri, 26 Jan 2001 09:59:16 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 26.01.2001 09:59:27, Serialize complete at 26.01.2001 09:59:27 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 AAA14971 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 26.01.01 00:22 budi@alliance.globalnetlink.com wrote: > > > > And IMHO, there is no technical reason to forbid a registrant to access > > the registry directly, should certain policy or technical reqirement > > needs it. I am not saying the registry SHOULD (or MUST) do this, but > > that they MAY. > > Agree. Why can't we simplify the requirement, ie. the > system (protocol/implementation) should only allow > *one* entity to access (read/write/update) to a record? > This *one* entity could be registrar, reseller, registrant, > registry, whatever. As long it is *one* entity. > (That way it can accomodate any business model.) > Not any. There are still exceptions which sometimes happen. Even if we usually allow only changes by the registrar we have the cases were due to court decisions, emergent claims from registrants we are enforced to make changes. And therefore it is better if there is a possibility for the registry to define a hierarchie of authorisation. This hierarchie can contain only one entity but can fit also the needs which at least some ccTLDs have, Regards Sabine > > -- budi > -- > Homepage: > my presentation materials, papers, scrapbook, ... and more > What's your "web.id"? Register your web.id @ http://www.idnic.net.id > 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 26 06:16:50 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14457 for ietf-whois-bks; Fri, 26 Jan 2001 06:16:50 -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 GAA14450 for ; Fri, 26 Jan 2001 06:16:48 -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 PAA16305; Fri, 26 Jan 2001 15:20:36 +0100 (CET) Date: Fri, 26 Jan 2001 15:20:36 +0100 (CET) From: Shane Kerr To: Randy Bush cc: ietf-whois@imc.org Subject: Re: New Standard for 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: On Tue, 23 Jan 2001, Randy Bush wrote: > > 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? The proposal is to format the Whois *query* as XML. The only way an existing Whois server can do this and still be RFC 954 compliant (now a draft standard for over 15 years!) is by sending the entire XML document as a single line: Connect to the SRI-NIC service host at TCP service port 43 (decimal). Send a single "command line", ending with (ASCII CR and LF). Receive information in response to the command line. The server closes its connection as soon as the output is finished. While possible, does this ever really happen? I expect not. Not that this means that I think the proposal is a good idea.... -- Shane From owner-ietf-whois Fri Jan 26 07:06:57 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA16657 for ietf-whois-bks; Fri, 26 Jan 2001 07:06:57 -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 HAA16650 for ; Fri, 26 Jan 2001 07:06:55 -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 QAA29363; Fri, 26 Jan 2001 16:11:02 +0100 (CET) Date: Fri, 26 Jan 2001 16:11:02 +0100 (CET) From: Shane Kerr To: Eric Brunner-Williams in Portland Maine cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <200101232157.f0NLv1n06510@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: On Tue, 23 Jan 2001, Eric Brunner-Williams in Portland Maine wrote: > > 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. As someone who may have to actually implement a merged RRP/Whois protocol if someone in IETF decides that RRP should consume the hoary Whois spec, and has no interest (at all! really!!!) in Domain Name information, I care. I don't envision RRP being useful for a more general purpose distributed database (I could be wrong here), but even if it is, it really seems to be orthogonal to Whois. Other people have noted this already, and they're right. :) -- Shane Kerr Database Software Engineer RIPE NCC +31 20 535 4427 From owner-ietf-whois Fri Jan 26 07:05:46 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA16620 for ietf-whois-bks; Fri, 26 Jan 2001 07:05:46 -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 HAA16616 for ; Fri, 26 Jan 2001 07:05:44 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14MAWk-0005nJ-00; Fri, 26 Jan 2001 10:11:02 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Fri, 26 Jan 2001 10:11:02 -0500 Date: Fri, 26 Jan 2001 10:11:02 -0500 From: George Belotsky To: Shane Kerr Cc: Randy Bush , ietf-whois@imc.org Subject: Re: New Standard for Whois Message-ID: <20010126101102.A4948@register.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from shane@ripe.net on Fri, Jan 26, 2001 at 03:20:36PM +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It is not even necessary to have the new protocol on port 43. If it is on port 43, however, the service would not adhere to the old standard when the new protocol is being used. Hence, the only issue is to detect which protocol is in use, and follow the right standard. Parsing the first line of an XML document is sufficient to determine that XML is being sent. The entire document does not have to be on one line. If the first line is XML, it is assumed that an XML document follows, and the new protocol is used. If the first line is not XML, then it is assumed that the old standard is in effect. The server immediately returns the result, and closes the connection. George. On Fri, Jan 26, 2001 at 03:20:36PM +0100, Shane Kerr wrote: > On Tue, 23 Jan 2001, Randy Bush wrote: > > > > 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? > > The proposal is to format the Whois *query* as XML. The only way an > existing Whois server can do this and still be RFC 954 compliant (now a > draft standard for over 15 years!) is by sending the entire XML document > as a single line: > > Connect to the SRI-NIC service host at TCP service port 43 > (decimal). > > Send a single "command line", ending with (ASCII CR and > LF). > > Receive information in response to the command line. The server > closes its connection as soon as the output is finished. > > While possible, does this ever really happen? I expect not. > > Not that this means that I think the proposal is a good idea.... > > -- > Shane > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Fri Jan 26 07:26:33 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA19220 for ietf-whois-bks; Fri, 26 Jan 2001 07:26:33 -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 HAA19198 for ; Fri, 26 Jan 2001 07:26:29 -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 QAA03500; Fri, 26 Jan 2001 16:32:19 +0100 (CET) Date: Fri, 26 Jan 2001 16:32:19 +0100 (CET) From: Shane Kerr To: Mark Kosters cc: ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <20010124104922.D780@slam.admin.cto.netsol.com> 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: Mark, Surely domain name and ip assignment info need not be required to be accessed via the same protocol. But I hope we can agree that a given well-known port should only be used for a single protocol. Given this reality, do you want to ask all of YOUR users to change from port 43 to some other port? I know I don't want to undertake an education of this magnitude for the folks using our (or ARIN's or APNIC's) servers! Personally I like the idea of switching into a different mode based on initial query - we actually do that with our Whois server now. If you specify a given option on query, we don't drop the connection after the reply is complete. Doing this in a way compatible with all existing servers may be hard, but I don't think it's impossible. This, combined with some standard(s) for I/O formats seems like a reasonable goal, that can bring value to Whois servers everywhere, and is worthy of love. Shane On Wed, 24 Jan 2001, Mark Kosters wrote: > 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? > > 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. From owner-ietf-whois Fri Jan 26 09:01:53 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA29887 for ietf-whois-bks; Fri, 26 Jan 2001 09:01:53 -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 JAA29881 for ; Fri, 26 Jan 2001 09:01:51 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14MCLa-0005L1-00; Fri, 26 Jan 2001 12:07:38 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Fri, 26 Jan 2001 12:07:38 -0500 Date: Fri, 26 Jan 2001 12:07:38 -0500 From: George Belotsky To: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010126120738.B4948@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: At this point in the discussion, it helps to summarize some key points. Those who objected to using the same protocol for the Whois and RRP have basically made three types of arguments, as listed below. The counter-arguments are given along with each type of argument. 1. There is not enough time to consider the Whois extensions. --- This is not an argument. The same point can be raised in any context, on any issue. Having a deadline does not justify cutting corners. If you cut corners to meet a deadline, you have not done your job. Once again, the Challenger disaster is the classic example of this. Launching something 'on time' is no achievement if everyone then has to deal with the horrible consequences for years afterwards. 2. The Whois is not on my agenda. I don't want to think about it. --- Protocol design is one of the most difficult tasks in our field of endeavor -- it requires a lot of thought. The more inclusive a protocol is, the more value it has. In general, a limited protocol is not worth implementing unless it is very simple. It is clear that he RRP has to be a complex protocol. Thus, every effort should be made to leverage it as much as possible in sufficiently analogous situations. 3. The RRP and Whois are different from each other. --- The letters 'a' and 'b' are different from each other. Should I make separate keyboards for each one? Maybe a different keyboard for each character? It is possible to find differences in any two things. The point is, are they *sufficiently* different to warrant separating them. Uniform treatment makes for a consistent view, and greatly reduces information overload. Before severely limiting the scope of a complex and extensible protocol, the consequences of such an action must be fully realized. The Whois functionality will have to be extended. Entities other than domain names will soon have to be registered, and made accessible in a Whois-like facility. The RRP will take considerable effort to implement. It is not necessary to decide every single detail now. The exact form that the Whois extensions will take, whether the new service will continue running on port 43, etc. can be taken up by the Whois group in due course. To squander the effort required to adopt the RRP -- by ignoring the coming needs to extend the Whois and to register other entities -- would be an unforgivable mistake. Everywhere, the trend is towards generic programming, polymorphic interfaces, and broad standards that unite large problem domains across many platforms. There are strong reasons for these trends. The complexity of modern systems, and the speed of their development, make it impossible to view things in a fragmented, isolated fashion. Broad similarities must be exploited over minute differences to create flexible and adaptable solutions. Let us not lose the rare opportunity to create a lasting, growing protocol for working with registered objects on the Internet. The problems we disregard today will not disappear tomorrow. If we are thus forced to confront them in the near future, the deadlines will press harder, the work will be considerably larger in scope, and the mistakes of the past will make a heavy burden. The most likely result -- obsolescence of the RRP -- would be a benefit to no-one. George. ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Fri Jan 26 09:32:03 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01115 for ietf-whois-bks; Fri, 26 Jan 2001 09:32:03 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01109 for ; Fri, 26 Jan 2001 09:32:02 -0800 (PST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0QHcQU29106; Fri, 26 Jan 2001 09:38:26 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0QHb3h12444; Fri, 26 Jan 2001 09:37:03 -0800 Message-Id: <200101261737.f0QHb3h12444@zed.isi.edu> Subject: Re: Merging RRP and Whois To: george@register.com (George Belotsky) Date: Fri, 26 Jan 2001 09:37:03 -0800 (PST) Cc: ietf-provreg@cafax.se, ietf-whois@imc.org In-Reply-To: <20010126120738.B4948@register.com> from "George Belotsky" at Jan 26, 2001 12:07:38 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: % 3. The RRP and Whois are different from each other. % --- % The letters 'a' and 'b' are different from each other. Should I make % separate keyboards for each one? Maybe a different keyboard for each % character? It is possible to find differences in any two things. The % point is, are they *sufficiently* different to warrant separating % them. Uniform treatment makes for a consistent view, and greatly % reduces information overload. I'd say yes, they are different enough to seperate. Roughly the whois protcol, in all its varients & extentions is basically a READ-ONLY protocol. Roughly, the "provreg" protocol, whatever that is, will be a READ/WRITE protocol. One is a frontend for the "great unwashed" to learn about what is/can be seen (modulo appropriate credentials) while the other is a "back-office" protocol for syncronizing data between the cabals. % The Whois functionality will have to be extended. Entities other than % domain names will soon have to be registered, and made accessible in a % Whois-like facility. The RRP will take considerable effort to % implement. What... again! NSI extended SRIs whois, RIPE twisted it again as did the RA project. At least by that time, we had enough sense to move our perversity to another port. Then there is the venerable rWHOIS varient. It will run on both the traditional port 43 as well as its own port (thank the PTB!) Tweeking whois is "easy" for two reasons: Its dirt simple and its there... sort of the way DNS used to be :) I'd rather not see this WG jump down that rathole. Been there, Done that, and still smell bad. Now, having lambasted the idea of lumping whois into provreg, I've a goofy idea. Can PROVREG recommend a scalable solution to the consideration of NIC-HANDLES? To my knowledge, this has never been addressed properly, at least since the days when the IR was split. When we did the RA project, the thought was to tag the NIC-HANDLE with the registrars "stamp", e.g. WM110-NSI WM110-RIPE WM110-ARIN but this leads, as friend Bush commented at the RIPE-37 mtg, to inconsistancies between registration agents. IN a nutshell, do we need globally unique IDs to the registering agents? If so, who administers that ID space? --bill From owner-ietf-whois Fri Jan 26 09:46:59 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA02914 for ietf-whois-bks; Fri, 26 Jan 2001 09:46:59 -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 JAA02906 for ; Fri, 26 Jan 2001 09:46:56 -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 SAA00939; Fri, 26 Jan 2001 18:52:44 +0100 (CET) Date: Fri, 26 Jan 2001 18:52:43 +0100 (CET) From: Shane Kerr To: George Belotsky cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <20010126120738.B4948@register.com> 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, 26 Jan 2001, George Belotsky wrote: > 1. There is not enough time to consider the Whois extensions. > --- > This is not an argument. Agreed here. If people don't have enough time, then implement now and standardize later. IETF is about protocol standards (well, at least that's what I thought). > 2. The Whois is not on my agenda. I don't want to think about it. > --- Well, to be fair, RRP is not on my agenda. :) I think extending RRP to include a read-only mode may have value for those who use it, but to me that's not the same as merging. Change the topic to "Include Whois functionality in RRP" and take the thread off of the ietf-whois mailing list, I suppose.... > 3. The RRP and Whois are different from each other. > --- > The letters 'a' and 'b' are different from each other. Should I make > separate keyboards for each one? I hesitate to extend a possibly bogus analogy, but...do I need a keyboard that can input Kanji, Arabic, and Cyrillic symbols if I only speak English? > Before severely limiting the scope of a complex and extensible > protocol, the consequences of such an action must be fully realized. Sure. But there's a reason that people use Internet protocols (SMTP, POP/IMAP, RFC822, etc.) and not X.400 for e-mail, and a large part of it is that X.400 was designed to solve all problems everywhere. It has a lot of nice things: delivery receipt, read receipt, message expiry (if not delivered by a certain date), and so on. But it's also a fat bloated pig, and costs a fortune to implement. > Everywhere, the trend is towards generic programming, polymorphic > interfaces, and broad standards that unite large problem domains > across many platforms. There are strong reasons for these trends. > The complexity of modern systems, and the speed of their development, > make it impossible to view things in a fragmented, isolated fashion. > Broad similarities must be exploited over minute differences to create > flexible and adaptable solutions. Maybe. But we have: Whois: anonymous read-only access to something (possibly a database) RRP: authenticated read/write access to a domain database Extending RRP to allow anonymous read-only access is probably straightforward (said with the eternal optimism of an implmentor). It is not clear to me that adding authenticattion OR read/write access to the Whois protocol make sense. Again, stop discussing "RRP/Whois merge" and start talking RRPng and that's fine with me. If you were to think about extending RRP from a client/server database to a generic distributed registration database, then I'd love to start talking. But the domain folks have quite reasonably decided that this is a Hard Problem and to concentrate on making a workable business model instead. Are the RRP folks really interested in making a protocol that worries about object consistency in databases run by their competitors? If so, that would be cool, but I just can't imagine any responsible CTO buying into such a scenerio. DNS does this, because it's very narrowly focused with incentives for everybody to carefully manage the data, without any access concerns (it's all public), and so on. Personally, I don't think the idea of a global Whois handle nomenclature really buys that much. You need to take the next step of actually allowing foreign data into your registry. If you're going to do that, then you need to resolve all the sticky issues that implies. Again, if that's really what people want to develop, then lets get into it. But if it's not, then please let it die. So does anybody want to work on that problem in the Whois and/or RRP group? Non-heirarchical, distributed registration database. The topic of distributed databases has been covered a lot in academia, and we can steal a lot of work there. Also, some problems (database partitioning comes to mind) that PhD-types have spent a lot of time worrying about can possibly be ignored. But it's a big, scary, nasty problem. -- Shane Kerr Database Software Engineer RIPE NCC +31 20 535 4427 From owner-ietf-whois Fri Jan 26 11:50:47 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA09338 for ietf-whois-bks; Fri, 26 Jan 2001 11:50:47 -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 LAA09331 for ; Fri, 26 Jan 2001 11:50:45 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail2 with smtp (Exim 3.16 #2) id 14MEz6-0005n5-00; Fri, 26 Jan 2001 14:56:36 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Fri, 26 Jan 2001 14:56:36 -0500 Date: Fri, 26 Jan 2001 14:56:36 -0500 From: George Belotsky To: Shane Kerr Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010126145636.B7740@register.com> References: <20010126120738.B4948@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from shane@ripe.net on Fri, Jan 26, 2001 at 06:52:43PM +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have envisioned the following rough sequence of events/solution as minimizing the required effort (by the ProvReg group and others) while maximizing the achieved benefits. I want to make this explicit, in case some of the discussion here resulted because of confusion. 1. The ProvReg group designs a protocol. This protocol allows/assumes: * A centralized object repository (registry) is assumed. * The protocol allows registries with different properties to be implemented. The different registries do not have to talk to each other. * The protocol supports authentication, and grants levels of privilege based on the submitted credentials. Possibilities for access by registrars, registrants, unrelated third parties, etc. are all allowed (by the mechanism) and configurable. The policy for who is finally allowed access would be set elsewhere, and would likely vary from registry to registry. * Thought is given to future extensions -- but just enough not to cripple the protocol. This group does not spend much time on this issue, nor does it work on the extensions themselves. 2. The work of the ProvReg group becomes a standard. 3. The Whois group extends this protocol to handle Whois queries. The old Whois protocol remains, but future development proceeds with the new protocol. This work can start even before Step 2, above. 4. The Whois extensions become standard. 5. The protocol is extended to objects other than domain names. This work could possibly start before Step 4, above. The key concept here (others have proposed similar things as well) is that the ProvReg protocol becomes the standard method that the world uses to communicate with a registry. Thus, we get fewer things that need to be designed, fewer things that need to be implemented, and -- most importantly -- fewer (diverging) things that need to be maintained. George. On Fri, Jan 26, 2001 at 06:52:43PM +0100, Shane Kerr wrote: > On Fri, 26 Jan 2001, George Belotsky wrote: > > > 1. There is not enough time to consider the Whois extensions. > > --- > > This is not an argument. > > Agreed here. If people don't have enough time, then implement now and > standardize later. IETF is about protocol standards (well, at least > that's what I thought). > > > 2. The Whois is not on my agenda. I don't want to think about it. > > --- > > Well, to be fair, RRP is not on my agenda. :) > > I think extending RRP to include a read-only mode may have value for > those who use it, but to me that's not the same as merging. Change the > topic to "Include Whois functionality in RRP" and take the thread off of > the ietf-whois mailing list, I suppose.... > > > 3. The RRP and Whois are different from each other. > > --- > > The letters 'a' and 'b' are different from each other. Should I make > > separate keyboards for each one? > > I hesitate to extend a possibly bogus analogy, but...do I need a > keyboard that can input Kanji, Arabic, and Cyrillic symbols if I only > speak English? > > > Before severely limiting the scope of a complex and extensible > > protocol, the consequences of such an action must be fully realized. > > Sure. But there's a reason that people use Internet protocols (SMTP, > POP/IMAP, RFC822, etc.) and not X.400 for e-mail, and a large part of it > is that X.400 was designed to solve all problems everywhere. It has a > lot of nice things: delivery receipt, read receipt, message expiry (if > not delivered by a certain date), and so on. But it's also a fat > bloated pig, and costs a fortune to implement. > > > Everywhere, the trend is towards generic programming, polymorphic > > interfaces, and broad standards that unite large problem domains > > across many platforms. There are strong reasons for these trends. > > The complexity of modern systems, and the speed of their development, > > make it impossible to view things in a fragmented, isolated fashion. > > Broad similarities must be exploited over minute differences to create > > flexible and adaptable solutions. > > Maybe. But we have: > > Whois: anonymous read-only access to something (possibly a database) > RRP: authenticated read/write access to a domain database > > Extending RRP to allow anonymous read-only access is probably > straightforward (said with the eternal optimism of an implmentor). It > is not clear to me that adding authenticattion OR read/write access to > the Whois protocol make sense. Again, stop discussing "RRP/Whois merge" > and start talking RRPng and that's fine with me. > > If you were to think about extending RRP from a client/server database > to a generic distributed registration database, then I'd love to start > talking. But the domain folks have quite reasonably decided that this > is a Hard Problem and to concentrate on making a workable business model > instead. > > Are the RRP folks really interested in making a protocol that worries > about object consistency in databases run by their competitors? If so, > that would be cool, but I just can't imagine any responsible CTO buying > into such a scenerio. DNS does this, because it's very narrowly > focused with incentives for everybody to carefully manage the data, > without any access concerns (it's all public), and so on. > > Personally, I don't think the idea of a global Whois handle nomenclature > really buys that much. You need to take the next step of actually > allowing foreign data into your registry. If you're going to do that, > then you need to resolve all the sticky issues that implies. Again, if > that's really what people want to develop, then lets get into it. But > if it's not, then please let it die. > > So does anybody want to work on that problem in the Whois and/or RRP > group? Non-heirarchical, distributed registration database. The topic > of distributed databases has been covered a lot in academia, and we can > steal a lot of work there. Also, some problems (database partitioning > comes to mind) that PhD-types have spent a lot of time worrying about > can possibly be ignored. But it's a big, scary, nasty problem. > > -- > Shane Kerr > Database Software Engineer > RIPE NCC > +31 20 535 4427 > > > > -- ----------------------------- George Belotsky Senior Software Architect Register.com, inc. george@register.com 212-798-9127 (phone) 212-798-9876 (fax) From owner-ietf-whois Fri Jan 26 13:13:29 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA14713 for ietf-whois-bks; Fri, 26 Jan 2001 13:13:29 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14707 for ; Fri, 26 Jan 2001 13:13:28 -0800 (PST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0QLJqU07751; Fri, 26 Jan 2001 13:19:52 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0QLIT312712; Fri, 26 Jan 2001 13:18:29 -0800 Message-Id: <200101262118.f0QLIT312712@zed.isi.edu> Subject: Re: Merging RRP and Whois To: george@register.com (George Belotsky) Date: Fri, 26 Jan 2001 13:18:29 -0800 (PST) Cc: shane@ripe.net (Shane Kerr), ietf-provreg@cafax.se, ietf-whois@imc.org In-Reply-To: <20010126145636.B7740@register.com> from "George Belotsky" at Jan 26, 2001 02:56:36 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: % % I have envisioned the following rough sequence of events/solution as % minimizing the required effort (by the ProvReg group and others) while % maximizing the achieved benefits. I want to make this explicit, in % case some of the discussion here resulted because of confusion. % % 1. The ProvReg group designs a protocol. This protocol allows/assumes: % * A centralized object repository (registry) is assumed. Why is this assumption in place? One could (rightly) argue that the single largest cause of instability and scaleability is the insistance on using "A centralized ... repository". The problems with that tactic caused the original IR to segment into multiple regional IRs, each retaining/maintaining "A centralized repository". Its gotten worse with the addition of each new "routing database" & whois service by agency. Each presumes a single "centralized repository". I'd rather see a protocol to allow a composite, non authoritative structure be fabricated from collections of hundreds/thousands of broadly distributed attributes. That way I would own my data and be able to direct its distribution to/through others non-auth copies of my data. --bill From owner-ietf-whois Fri Jan 26 16:21:50 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA24807 for ietf-whois-bks; Fri, 26 Jan 2001 16:21:50 -0800 (PST) Received: from falcon.prod.itd.earthlink.net (falcon.prod.itd.earthlink.net [207.217.120.74]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA24803 for ; Fri, 26 Jan 2001 16:21:48 -0800 (PST) Received: from vulcan (1Cust144.tnt7.redmond.wa.da.uu.net [63.23.205.144]) by falcon.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id QAA14585; Fri, 26 Jan 2001 16:28:09 -0800 (PST) Message-ID: <002401c087f7$ed394840$140a0a0a@ambler.net> Reply-To: "Christopher Ambler" From: "Christopher Ambler" To: , References: <200101261737.f0QHb3h12444@zed.isi.edu> Subject: Re: Merging RRP and Whois Date: Fri, 26 Jan 2001 16:27:25 -0800 Organization: Image Online Design, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA24804 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Now, having lambasted the idea of lumping whois into provreg, I've a goofy > idea. Can PROVREG recommend a scalable solution to the consideration of > NIC-HANDLES? To my knowledge, this has never been addressed properly, at > least since the days when the IR was split. When we did the RA project, the > thought was to tag the NIC-HANDLE with the registrars "stamp", e.g. I'm sure this has come up in the past, but why not email addresses? They're unique, and identify the source. Master information on the handle is kept by whatever registry handles the TLD in question. That is, foo@bar.com information is handled by NSI. foo@bar.newtld is handled by the registry that runs "newtld." Transfer of handle information can be part of the RRP. Any registry, after authenticating, can accept changes to the handle info and pass it (along with the authentication information) to the registry that holds the records for that contact. This allows for email address changes, as they do change. It also allows for up-to-date contact information for each handle (subject, of course, to whatever privacy protection is in place), for messages of a technical nature (with a specifically wary eye towards adequate protection from spam harvesting). -- Christopher Ambler CTO, Image Online Design, Inc. The .Web Internet Domain Registry chris@the.web From owner-ietf-whois Fri Jan 26 17:09:16 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA25647 for ietf-whois-bks; Fri, 26 Jan 2001 17:09:16 -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 RAA25643 for ; Fri, 26 Jan 2001 17:09:14 -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 f0R1EYn16146; Fri, 26 Jan 2001 20:14:34 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200101270114.f0R1EYn16146@nic-naa.net> To: George Michaelson cc: 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 "Thu, 25 Jan 2001 11:12:18 +1000." <25190.980385138@dstc.edu.au> Date: Fri, 26 Jan 2001 20:14:33 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Yes. I didn't realize your comments were about jurisdiction. I thought they > were about technology. A mechanism that can support a required policy is preferential over one which cannot, and political geography has been present in the dns for quite some time. Territorial jurisdictions have been around longer. Having put onward-transport with jurisdictional integrity into the marketers profile exchange mechanism because of an oddly similar policy constraint, I know it can exist within the onward-transport of registrant "profiles", with all the personally identifying information they entail. In your role of panel co-chair, I suggest you chat with Roger Clarke and suggest to him that privacy in the .AU market, or in the regional market, is satisfied by "anti-spam volume checks". He may surprise you and mention the OECD guidelines, or even the phrase "data protection". Having read his work on gaming, I know he'll see the jurisdictional issue. In an effort to keep two lists from being further entangled, I'll stay to the RRP side of the fence, except to write a "privacy considerations" section to any whois draft needing one. Others of course may do so as well. Cheers, Eric From owner-ietf-whois Sat Jan 27 08:36:42 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23604 for ietf-whois-bks; Sat, 27 Jan 2001 08:36:42 -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 IAA23600 for ; Sat, 27 Jan 2001 08:36:40 -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 RAA11253; Sat, 27 Jan 2001 17:41:59 +0100 (CET) Date: Sat, 27 Jan 2001 17:41:59 +0100 (CET) From: Shane Kerr To: Bill Manning cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <200101262118.f0QLIT312712@zed.isi.edu> 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, 26 Jan 2001, Bill Manning wrote: > % > % I have envisioned the following rough sequence of events/solution as > % minimizing the required effort (by the ProvReg group and others) while > % maximizing the achieved benefits. I want to make this explicit, in > % case some of the discussion here resulted because of confusion. > % > % 1. The ProvReg group designs a protocol. This protocol allows/assumes: > % * A centralized object repository (registry) is assumed. > > Why is this assumption in place? > One could (rightly) argue that the single largest cause of > instability and scaleability is the insistance on using > "A centralized ... repository". The problems with that > tactic caused the original IR to segment into multiple > regional IRs, each retaining/maintaining "A centralized > repository". Its gotten worse with the addition of each new > "routing database" & whois service by agency. Each presumes > a single "centralized repository". > > I'd rather see a protocol to allow a composite, non authoritative > structure be fabricated from collections of hundreds/thousands > of broadly distributed attributes. That way I would own my > data and be able to direct its distribution to/through others > non-auth copies of my data. Agreed. As a simplifying assumption, a master data source is nice. But I can see a migration path from the current RIR (APNIC, ARIN, and RIPE NCC) and IRR (RADB, RIPE NCC, etc.) registries to a system that doesn't involve a centralized, or even a heirarchical, structure. Some centralization may end up being required (e.g. the standardized NIC handle format you mentioned earlier), but that doesn't mean we need a Registry/Registrar setup for all data sets. Again, RRP evolved into a Faster, Stronger, Smarter RRP doesn't really do anything for non-domain Whois users. Shane From owner-ietf-whois Sat Jan 27 08:56:02 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24648 for ietf-whois-bks; Sat, 27 Jan 2001 08:56:02 -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 IAA24638 for ; Sat, 27 Jan 2001 08:56:00 -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 SAA13199; Sat, 27 Jan 2001 18:01:56 +0100 (CET) Date: Sat, 27 Jan 2001 18:01:56 +0100 (CET) From: Shane Kerr To: Christopher Ambler cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <002401c087f7$ed394840$140a0a0a@ambler.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: On Fri, 26 Jan 2001, Christopher Ambler wrote: > > Now, having lambasted the idea of lumping whois into provreg, I've a goofy > > idea. Can PROVREG recommend a scalable solution to the consideration of > > NIC-HANDLES? To my knowledge, this has never been addressed properly, at > > least since the days when the IR was split. When we did the RA project, the > > thought was to tag the NIC-HANDLE with the registrars "stamp", e.g. > > I'm sure this has come up in the past, but why not email addresses? > They're unique, and identify the source. Master information on the > handle is kept by whatever registry handles the TLD in question. I can see that sending to both ietf-provreg and ietf-whois is going to cause some problems. :( NIC handles are used by people who have nothing to do with domains. I'd prefer something that ties the NIC-HDL with the database storing information, which will not be the database storing the domain on the e-mail address of the contact, except in domain databases. Otherwise either I must form some sort of relationship with a domain database operator, or I just can't use them. Shane ~ From owner-ietf-whois Sat Jan 27 23:29:29 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id XAA02714 for ietf-whois-bks; Sat, 27 Jan 2001 23:29:29 -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 XAA02696 for ; Sat, 27 Jan 2001 23:29:26 -0800 (PST) Received: from jamessonyvaio (1Cust223.tnt2.honolulu2.hi.da.uu.net [63.39.141.223]) by mail.i-dns.net (Postfix) with SMTP id F278FFFC03; Sun, 28 Jan 2001 15:35:33 +0800 (SGT) Message-ID: <002a01c088fc$bacb84d0$df8d273f@jamessonyvaio> From: "James Seng/Personal" To: "Bill Manning" , "George Belotsky" Cc: "Shane Kerr" , , References: <200101262118.f0QLIT312712@zed.isi.edu> Subject: Re: Merging RRP and Whois Date: Sun, 28 Jan 2001 09:02:21 +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: While I like the idea of having a collectives of distributed repository, ie not centralized, in some cases, a centralized repository is unavoidable. I think what we need is a balance of both. A centralized repository is probably very bad for scaling but you have control. A distributed repositories infrastructure may scale but it is slightly chaotic. Not all system needs to be centralized. A registry/directory for email address for example can be distributed (and should be). -James Seng > Why is this assumption in place? > One could (rightly) argue that the single largest cause of > instability and scaleability is the insistance on using > "A centralized ... repository". The problems with that > tactic caused the original IR to segment into multiple > regional IRs, each retaining/maintaining "A centralized > repository". Its gotten worse with the addition of each new > "routing database" & whois service by agency. Each presumes > a single "centralized repository". > > I'd rather see a protocol to allow a composite, non authoritative > structure be fabricated from collections of hundreds/thousands > of broadly distributed attributes. That way I would own my > data and be able to direct its distribution to/through others > non-auth copies of my data. From owner-ietf-whois Sun Jan 28 05:51:25 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA20703 for ietf-whois-bks; Sun, 28 Jan 2001 05:51:25 -0800 (PST) Received: from uclink4.berkeley.edu (uclink4.Berkeley.EDU [128.32.25.39]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20698 for ; Sun, 28 Jan 2001 05:51:23 -0800 (PST) Received: from 04-180.068.popsite.net (sheer@04-180.068.popsite.net [64.24.81.180]) by uclink4.berkeley.edu (8.10.1/8.10.1) with ESMTP id f0SDvoG13899; Sun, 28 Jan 2001 05:57:50 -0800 (PST) Date: Sun, 28 Jan 2001 06:49:19 +0000 (WET) From: Sheer El-Showk X-Sender: sheer@graymalkin.teranix.net To: Bill Manning cc: George Belotsky , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <200101261737.f0QHb3h12444@zed.isi.edu> 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: > Now, having lambasted the idea of lumping whois into provreg, I've a goofy > idea. Can PROVREG recommend a scalable solution to the consideration of > NIC-HANDLES? To my knowledge, this has never been addressed properly, at > least since the days when the IR was split. When we did the RA project, the > thought was to tag the NIC-HANDLE with the registrars "stamp", e.g. > > WM110-NSI > WM110-RIPE > WM110-ARIN > > but this leads, as friend Bush commented at the RIPE-37 mtg, to inconsistancies > between registration agents. IN a nutshell, do we need globally unique IDs > to the registering agents? If so, who administers that ID space? Why would we want global NIC handles? Transfers? Data-consistency? Making life easier for the registrant? None of these seem sufficiently important to merit the kind of effort (either bureacratic -- if its one big NIC Handle registry; or technical -- if the registries used a shared/synced NIC Handle DB). Especially because registries may not want to share their NIC handles for various privacy or reasons. That having been said, what I like about an idea like this is it would make it simpler to determine who is authoritative owner of a domain - an issue I think we should really consider since it seems to be done mostly by "out-of-band" methods (email's sent by the registry -- at least Verisign -- to determine the domain owner) -- which I agree should be eliminated. Still I think a focus on digitally certifying a domain is the right way to go, rather than centralizing user information. Sheer From owner-ietf-whois Mon Jan 29 07:33:38 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA27869 for ietf-whois-bks; Mon, 29 Jan 2001 07:33:38 -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 HAA27862 for ; Mon, 29 Jan 2001 07:33:36 -0800 (PST) Received: from [10.10.24.253] (helo=mail.register.com) by rcommail1 with smtp (Exim 3.16 #2) id 14NGOy-0005UP-00; Mon, 29 Jan 2001 10:39:32 -0500 Received: by mail.register.com (sSMTP sendmail emulation); Mon, 29 Jan 2001 10:39:32 -0500 Date: Mon, 29 Jan 2001 10:39:32 -0500 From: George Belotsky To: Bill Manning Cc: Shane Kerr , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010129103932.A735@register.com> References: <20010126145636.B7740@register.com> <200101262118.f0QLIT312712@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101262118.f0QLIT312712@zed.isi.edu>; from bmanning@ISI.EDU on Fri, Jan 26, 2001 at 01:18:29PM -0800 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The assumption of a centralized store would be made at the protocol level. The underlying implementation could well be distributed. Assuming a distributed database at the protocol level would complicate the client. On Fri, Jan 26, 2001 at 01:18:29PM -0800, Bill Manning wrote: > % > % I have envisioned the following rough sequence of events/solution as > % minimizing the required effort (by the ProvReg group and others) while > % maximizing the achieved benefits. I want to make this explicit, in > % case some of the discussion here resulted because of confusion. > % > % 1. The ProvReg group designs a protocol. This protocol allows/assumes: > % * A centralized object repository (registry) is assumed. > > Why is this assumption in place? > One could (rightly) argue that the single largest cause of > instability and scaleability is the insistance on using > "A centralized ... repository". The problems with that > tactic caused the original IR to segment into multiple > regional IRs, each retaining/maintaining "A centralized > repository". Its gotten worse with the addition of each new > "routing database" & whois service by agency. Each presumes > a single "centralized repository". > > I'd rather see a protocol to allow a composite, non authoritative > structure be fabricated from collections of hundreds/thousands > of broadly distributed attributes. That way I would own my > data and be able to direct its distribution to/through others > non-auth copies of my data. > > > --bill -- ----------------------------- 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 29 08:00:16 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA00598 for ietf-whois-bks; Mon, 29 Jan 2001 08:00:16 -0800 (PST) Received: from laudanum.saraf.com (root@[63.217.189.99]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00586 for ; Mon, 29 Jan 2001 08:00:14 -0800 (PST) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f0TG1W925122; Mon, 29 Jan 2001 11:01:33 -0500 Date: Mon, 29 Jan 2001 11:01:32 -0500 (EST) From: Sheer El-Showk To: George Belotsky cc: Bill Manning , Shane Kerr , ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <20010129103932.A735@register.com> 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: > > % 1. The ProvReg group designs a protocol. This protocol allows/assumes: > > % * A centralized object repository (registry) is assumed. > > > > Why is this assumption in place? > > One could (rightly) argue that the single largest cause of > > instability and scaleability is the insistance on using > > "A centralized ... repository". The problems with that Well, I wouldn't say this is necassarily true. DNS is extremely distributed, both in location and in authority (well ICANN on top, but at lower levels everyone only sees the servers above them as local authority, they don't all go straight to the root servers) and that has not helped make it any more stable (it just means you can have that many more sources of inaccuracy -- the authoritative domain server, a glue record in a higher level domain, a none-updated record in a secondary server). As for scalability of a centralized repository ... it shouldn't be a problem. Centralized doens't mean one server or one network ... it means one central authority. They can use as many redundant, load-balancing servers as they want -- the idea is that there is always one entity to turn to to get authoritative information regarding a domain or other registered object. > > tactic caused the original IR to segment into multiple > > regional IRs, each retaining/maintaining "A centralized > > repository". Its gotten worse with the addition of each new > > "routing database" & whois service by agency. Each presumes > > a single "centralized repository". > > > > I'd rather see a protocol to allow a composite, non authoritative > > structure be fabricated from collections of hundreds/thousands > > of broadly distributed attributes. That way I would own my > > data and be able to direct its distribution to/through others > > non-auth copies of my data. This sounds nice in principle, but how do you maintain data consistency, data-uniqueness, and how do you protect against data corruption. I'd be genuinly interested in discussing a system that would allow the data to be maintain its own integrity in some way and be distributed (eg just an interesting idea: unique world-wide NIC handle with your region specific NIC info being held in the ccTLD registries keyed to your unique identifier with local privilage systems in place -- sounds nice but a little complicated). Sheer From owner-ietf-whois Mon Jan 29 08:06:50 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA00793 for ietf-whois-bks; Mon, 29 Jan 2001 08:06:50 -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 IAA00789 for ; Mon, 29 Jan 2001 08:06:49 -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 RAA13082; Mon, 29 Jan 2001 17:12:24 +0100 (CET) Date: Mon, 29 Jan 2001 17:12:24 +0100 (CET) From: Shane Kerr To: George Belotsky cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-Reply-To: <20010129103932.A735@register.com> 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 Mon, 29 Jan 2001, George Belotsky wrote: > The assumption of a centralized store would be made at the > protocol level. The underlying implementation could well > be distributed. Assuming a distributed database at the > protocol level would complicate the client. Not necessarily. HTTP+HTML implements a distributed database with an extremely simple client (until you decide to render the HTML, I suppose) - not that it can't be done wrong (see "RWhois"). Shane From owner-ietf-whois Mon Jan 29 14:24:31 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA27157 for ietf-whois-bks; Mon, 29 Jan 2001 14:24:31 -0800 (PST) Received: from fulcrum ([204.70.128.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27152 for ; Mon, 29 Jan 2001 14:24:29 -0800 (PST) Received: from CONVERSION-DAEMON by cw.net (PMDF V5.2-33 #43876) id <0G7Y00N013UX37@cw.net> for ietf-whois@imc.org; Mon, 29 Jan 2001 17:30:33 -0500 (EST) Received: from mail-gw.ie.cw.net ([204.70.128.53]) by cw.net (PMDF V5.2-33 #43876) with ESMTP id <0G7Y00LF23UXSO@cw.net>; Mon, 29 Jan 2001 17:30:33 -0500 (EST) Received: by MAIL-GW with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jan 2001 17:30:49 -0500 Content-return: allowed Date: Mon, 29 Jan 2001 17:40:20 -0500 From: "Lu, Ping" Subject: RE: New Standard for Whois To: "'Shane Kerr'" , Randy Bush Cc: ietf-whois@imc.org Message-id: 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: While I would like to have XML-like capability to do a "whois-ng" query, I don't see how can you mix "whois" with "XML". Here are the reasons: 1. whois requires CRLF to be the terminator of a query. 2. XML uses <> as the delimitor and it is possible to have CRLF as part of data. 3. How can you ever escape the CRLF and not breaking the current whois implementation when you telnet into a whois server ? 4. The other way around is also difficult. How can you make sure some whois query that contains <...> is not mistaken as an XML tag ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net > -----Original Message----- > From: Shane Kerr [mailto:shane@ripe.net] > Sent: Friday, January 26, 2001 9:21 AM > To: Randy Bush > Cc: ietf-whois@imc.org > Subject: Re: New Standard for Whois > > > On Tue, 23 Jan 2001, Randy Bush wrote: > > > > 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? > > The proposal is to format the Whois *query* as XML. The only way an > existing Whois server can do this and still be RFC 954 > compliant (now a > draft standard for over 15 years!) is by sending the entire > XML document > as a single line: > > Connect to the SRI-NIC service host at TCP service port 43 > (decimal). > > Send a single "command line", ending with (ASCII CR and > LF). > > Receive information in response to the command line. The server > closes its connection as soon as the output is finished. > > While possible, does this ever really happen? I expect not. > > Not that this means that I think the proposal is a good idea.... > > -- > Shane > > From owner-ietf-whois Mon Jan 29 15:01:58 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA28139 for ietf-whois-bks; Mon, 29 Jan 2001 15:01:58 -0800 (PST) Received: from fulcrum ([204.70.128.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28135 for ; Mon, 29 Jan 2001 15:01:57 -0800 (PST) Received: from CONVERSION-DAEMON by cw.net (PMDF V5.2-33 #43876) id <0G7Y001015L8AN@cw.net> for ietf-whois@imc.org; Mon, 29 Jan 2001 18:07:56 -0500 (EST) Received: from mail-gw.ie.cw.net ([204.70.128.53]) by cw.net (PMDF V5.2-33 #43876) with ESMTP id <0G7Y00LNJ5L8SO@cw.net>; Mon, 29 Jan 2001 18:07:56 -0500 (EST) Received: by MAIL-GW with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jan 2001 18:08:12 -0500 Content-return: allowed Date: Mon, 29 Jan 2001 18:17:50 -0500 From: "Lu, Ping" Subject: RE: New Standard for Whois To: "'George Belotsky'" , Shane Kerr Cc: Randy Bush , ietf-whois@imc.org Message-id: 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: Again, The ambiguity is guranteed when you mix XML with whois. It is possible to have a XML record to be valid whois query on some lines while it is data inside a XML record. It is also possible to have several valid whois queries contains a XML look-like record across several lines. It is almost impossible to have either a user or a program to resolve this kind of ambiguity. Just think of puting a whois query in a XML record as the valid data will drive the programmer writing the parser goes crazy. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net > -----Original Message----- > From: George Belotsky [mailto:george@register.com] > Sent: Friday, January 26, 2001 10:11 AM > To: Shane Kerr > Cc: Randy Bush; ietf-whois@imc.org > Subject: Re: New Standard for Whois > > > It is not even necessary to have the new protocol on port 43. > > If it is on port 43, however, the service would not adhere to the old > standard when the new protocol is being used. > > Hence, the only issue is to detect which protocol is in use, and > follow the right standard. > > Parsing the first line of an XML document is sufficient to determine > that XML is being sent. The entire document does not have to be on > one line. If the first line is XML, it is assumed that an XML > document follows, and the new protocol is used. > > If the first line is not XML, then it is assumed that the old standard > is in effect. The server immediately returns the result, and closes > the connection. > > George. > > > > On Fri, Jan 26, 2001 at 03:20:36PM +0100, Shane Kerr wrote: > > On Tue, 23 Jan 2001, Randy Bush wrote: > > > > > > 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? > > > > The proposal is to format the Whois *query* as XML. The only way an > > existing Whois server can do this and still be RFC 954 > compliant (now a > > draft standard for over 15 years!) is by sending the entire > XML document > > as a single line: > > > > Connect to the SRI-NIC service host at TCP service port 43 > > (decimal). > > > > Send a single "command line", ending with (ASCII CR and > > LF). > > > > Receive information in response to the command line. > The server > > closes its connection as soon as the output is finished. > > > > While possible, does this ever really happen? I expect not. > > > > Not that this means that I think the proposal is a good idea.... > > > > -- > > Shane > > > > > > -- > ----------------------------- > 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 30 05:53:11 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA22800 for ietf-whois-bks; Tue, 30 Jan 2001 05:53:11 -0800 (PST) Received: from laudanum.saraf.com (root@[63.217.189.99]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA22795 for ; Tue, 30 Jan 2001 05:53:10 -0800 (PST) Received: from localhost (sheer@localhost) by laudanum.saraf.com (8.10.2/8.10.2) with ESMTP id f0UDskN27542; Tue, 30 Jan 2001 08:54:46 -0500 Date: Tue, 30 Jan 2001 08:54:46 -0500 (EST) From: Sheer El-Showk To: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Sorry -- 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: Hi, Sorry about the two double postings. I was using a non-subscribed email address and the postings didn't go through so I reposted ... I didn't know they'de just be delayed. Sheer On Sun, 28 Jan 2001, Sheer El-Showk wrote: > > Now, having lambasted the idea of lumping whois into provreg, I've a goofy > > idea. Can PROVREG recommend a scalable solution to the consideration of > > NIC-HANDLES? To my knowledge, this has never been addressed properly, at > > least since the days when the IR was split. When we did the RA project, the > > thought was to tag the NIC-HANDLE with the registrars "stamp", e.g. > > > > WM110-NSI > > WM110-RIPE > > WM110-ARIN > > > > but this leads, as friend Bush commented at the RIPE-37 mtg, to inconsistancies > > between registration agents. IN a nutshell, do we need globally unique IDs > > to the registering agents? If so, who administers that ID space? > > Why would we want global NIC handles? Transfers? Data-consistency? Making > life easier for the registrant? > > None of these seem sufficiently important to merit the kind of effort > (either bureacratic -- if its one big NIC Handle registry; or technical -- > if the registries used a shared/synced NIC Handle DB). Especially because > registries may not want to share their NIC handles for various privacy or > reasons. > > That having been said, what I like about an idea like this is it would > make it simpler to determine who is authoritative owner of a domain - an > issue I think we should really consider since it seems to be done mostly > by "out-of-band" methods (email's sent by the registry -- at least > Verisign -- to determine the domain owner) -- which I agree should > be eliminated. Still I think a focus on digitally certifying a domain is > the right way to go, rather than centralizing user information. > > Sheer > > From owner-ietf-whois Tue Jan 30 09:19:11 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA05964 for ietf-whois-bks; Tue, 30 Jan 2001 09:19:11 -0800 (PST) Received: from fulcrum ([204.70.128.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05958 for ; Tue, 30 Jan 2001 09:19:09 -0800 (PST) Received: from CONVERSION-DAEMON by cw.net (PMDF V5.2-33 #43876) id <0G7Z00901KDZ6X@cw.net> for ietf-whois@imc.org; Tue, 30 Jan 2001 12:25:11 -0500 (EST) Received: from mail-gw.ie.cw.net ([204.70.128.53]) by cw.net (PMDF V5.2-33 #43876) with ESMTP id <0G7Z007NQKDYJI@cw.net>; Tue, 30 Jan 2001 12:25:10 -0500 (EST) Received: by MAIL-GW with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jan 2001 12:25:29 -0500 Content-return: allowed Date: Tue, 30 Jan 2001 12:35:02 -0500 From: "Lu, Ping" Subject: RE: Sorry -- Re: Merging RRP and Whois To: "'Sheer El-Showk'" , ietf-provreg@cafax.se, ietf-whois@imc.org Message-id: 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 you mentioned the NIC-HANDLE problem is a global one. There is no question that NIC-HANDLE should be unique inside each Registry's database. But what happen if you want to peer with other ISPs who is registered all over the world ? Either you REFERENCE their objects from all the RIRs (ARIN, RIPE, APNIC ...) or you ask them to replicate their objects in your own Registry. The former will require the NIC-HANDLE to be global unique, the later will need all ISPs to maintain a seperate set of objects for each IR. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net > -----Original Message----- > From: Sheer El-Showk [mailto:sheer@laudanum.saraf.com] > Sent: Tuesday, January 30, 2001 8:55 AM > To: ietf-provreg@cafax.se; ietf-whois@imc.org > Subject: Sorry -- Re: Merging RRP and Whois > > > Hi, > > Sorry about the two double postings. I was using a > non-subscribed email > address and the postings didn't go through so I reposted ... > I didn't know > they'de just be delayed. > > Sheer > > On Sun, 28 Jan 2001, Sheer El-Showk wrote: > > > > Now, having lambasted the idea of lumping whois into > provreg, I've a goofy > > > idea. Can PROVREG recommend a scalable solution to the > consideration of > > > NIC-HANDLES? To my knowledge, this has never been > addressed properly, at > > > least since the days when the IR was split. When we did > the RA project, the > > > thought was to tag the NIC-HANDLE with the registrars > "stamp", e.g. > > > > > > WM110-NSI > > > WM110-RIPE > > > WM110-ARIN > > > > > > but this leads, as friend Bush commented at the RIPE-37 > mtg, to inconsistancies > > > between registration agents. IN a nutshell, do we need > globally unique IDs > > > to the registering agents? If so, who administers that ID space? > > > > Why would we want global NIC handles? Transfers? > Data-consistency? Making > > life easier for the registrant? > > > > None of these seem sufficiently important to merit the kind > of effort > > (either bureacratic -- if its one big NIC Handle registry; > or technical -- > > if the registries used a shared/synced NIC Handle DB). > Especially because > > registries may not want to share their NIC handles for > various privacy or > > reasons. > > > > That having been said, what I like about an idea like this > is it would > > make it simpler to determine who is authoritative owner of > a domain - an > > issue I think we should really consider since it seems to > be done mostly > > by "out-of-band" methods (email's sent by the registry -- at least > > Verisign -- to determine the domain owner) -- which I agree should > > be eliminated. Still I think a focus on digitally > certifying a domain is > > the right way to go, rather than centralizing user information. > > > > Sheer > > > > > From owner-ietf-whois Tue Jan 30 10:12:35 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA09973 for ietf-whois-bks; Tue, 30 Jan 2001 10:12:35 -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 KAA09964 for ; Tue, 30 Jan 2001 10:12:32 -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 TAA01081; Tue, 30 Jan 2001 19:17:12 +0100 (CET) Date: Tue, 30 Jan 2001 19:17:12 +0100 (CET) From: Shane Kerr To: "Lu, Ping" cc: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: RE: Sorry -- 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: On Tue, 30 Jan 2001, Lu, Ping wrote: > As you mentioned the NIC-HANDLE problem is a global one. > > There is no question that NIC-HANDLE should be unique inside each > Registry's database. > > But what happen if you want to peer with other ISPs who is > registered all over the world ? > > Either you REFERENCE their objects from all the RIRs (ARIN, RIPE, > APNIC ...) or you ask them to replicate their objects in your own > Registry. The former will require the NIC-HANDLE to be global > unique, the later will need all ISPs to maintain a seperate set of > objects for each IR. Indeed it will require much more than being globally unique. For instance, what happens if you have a database, PING, which a reference to an object, XYZ, in another database, KERR. If someone wants to delete XYZ from KERR, KERR can either prevent the delete or not. If KERR does not prevent the delete, you have a dangling reference, and possibly no contact information for the objects in PING that refer to XYZ. Suggestions have been made that PING could cache the object, and use the undeleted object. However, in this case, you would have either: 1. A copy of an object, say XYZ-KERR, that is not in the KERR database. 2. A renamed copy of the object, say XYZ-PING, that XYZ did not create or explicitly request the creation of. If KERR prevents the delete, then you have authentication issues. For example, if PING does not implement the same authentication that KERR does, then a user can create a reference to XYZ in PING and prevent an authenticated user from deleting the object in KERR. In the cases where a new object is created from cache or a deletion is prevented, KERR needs some sort of registration mechanism to know that PING has a reference to the object. (In the case of creation from cache, KERR needs to make sure that PING has the latest copy of the object before deleting it.) I haven't touched on modification here, but it should follow the same general issues. Creation will require appropriate registration for any foreign keys used and such. This registration and checking will of course slow down the modification of the databases, and also add a level of unreliability. In the case of objects in the RIPE database, we are extremely read-heavy, and write-light. However, referring to foreign objects means occasionally querying other servers to get the data. With a proper registration mechanism, objects can be cached locally. I would prefer NOT to see a DNS-style system, where it is just assumed that queries provide incorrect data occasionally. It may be the best answer, but I think it is avoidable. I believe that using references to other Whois databases requires a great deal of cooperation, at least on the protocol level. Is it scalable? I suggest that it probably is, for small numbers of Whois servers. For large numbers of servers, you'll probably need some sort of graph - a tree perhaps? ;) - to distribute the load. Perhaps some simulations should be done before moving too far along? A bigger question is whether organizations would be willing to bind their databases together like this, and if so in what fashion. I get very nervous considering the politics involved. Am I the only one who thinks it may be an unsurmountable problem? I've said it several times now, but this is a Hard Problem. I have heard Bill Manning say that he thinks it would be worthwhile solving. Others (unnamed) just seem to want a global NIC-HDL, which I don't think buys you anything unless you can use it. I don't think you can use it unless you tackle the issues here. It seems like a lot of work for very little real gain! Shane From owner-ietf-whois Tue Jan 30 12:09:46 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA16374 for ietf-whois-bks; Tue, 30 Jan 2001 12:09:46 -0800 (PST) Received: from fulcrum ([204.70.128.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16361 for ; Tue, 30 Jan 2001 12:09:34 -0800 (PST) Received: from CONVERSION-DAEMON by cw.net (PMDF V5.2-33 #43876) id <0G7Z00G01SA1NG@cw.net> for ietf-whois@imc.org; Tue, 30 Jan 2001 15:15:37 -0500 (EST) Received: from mail-gw.ie.cw.net ([204.70.128.53]) by cw.net (PMDF V5.2-33 #43876) with ESMTP id <0G7Z00G3NSA1FG@cw.net>; Tue, 30 Jan 2001 15:15:37 -0500 (EST) Received: by MAIL-GW with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jan 2001 15:15:55 -0500 Content-return: allowed Date: Tue, 30 Jan 2001 15:25:31 -0500 From: "Lu, Ping" Subject: RE: Sorry -- Re: Merging RRP and Whois To: "'Shane Kerr'" , "Lu, Ping" Cc: ietf-provreg@cafax.se, ietf-whois@imc.org Message-id: 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: I totally agree that the external (outside the local registry) reference is a difficult problem to solve. But nontheless there is a need to use them. Because the alternative ( let each ISPs to maintain a different set of objects for each IR ) is a manual process and is more prone to error. Just like the driver license. People only register in one state then all other states can reference the information even there is a risk this license may be revoked if you don't check frequently enough. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net > -----Original Message----- > From: Shane Kerr [mailto:shane@ripe.net] > Sent: Tuesday, January 30, 2001 1:17 PM > To: Lu, Ping > Cc: ietf-provreg@cafax.se; ietf-whois@imc.org > Subject: RE: Sorry -- Re: Merging RRP and Whois > > > On Tue, 30 Jan 2001, Lu, Ping wrote: > > > As you mentioned the NIC-HANDLE problem is a global one. > > > > There is no question that NIC-HANDLE should be unique inside each > > Registry's database. > > > > But what happen if you want to peer with other ISPs who is > > registered all over the world ? > > > > Either you REFERENCE their objects from all the RIRs (ARIN, RIPE, > > APNIC ...) or you ask them to replicate their objects in your own > > Registry. The former will require the NIC-HANDLE to be global > > unique, the later will need all ISPs to maintain a seperate set of > > objects for each IR. > > Indeed it will require much more than being globally unique. For > instance, what happens if you have a database, PING, which a reference > to an object, XYZ, in another database, KERR. If someone wants to > delete XYZ from KERR, KERR can either prevent the delete or not. > > If KERR does not prevent the delete, you have a dangling > reference, and > possibly no contact information for the objects in PING that refer to > XYZ. Suggestions have been made that PING could cache the object, and > use the undeleted object. However, in this case, you would > have either: > > 1. A copy of an object, say XYZ-KERR, that is not in the KERR > database. > > 2. A renamed copy of the object, say XYZ-PING, that XYZ did not create > or explicitly request the creation of. > > If KERR prevents the delete, then you have authentication issues. For > example, if PING does not implement the same authentication that KERR > does, then a user can create a reference to XYZ in PING and prevent an > authenticated user from deleting the object in KERR. > > In the cases where a new object is created from cache or a deletion is > prevented, KERR needs some sort of registration mechanism to know that > PING has a reference to the object. (In the case of creation from > cache, KERR needs to make sure that PING has the latest copy of the > object before deleting it.) > > I haven't touched on modification here, but it should follow the same > general issues. Creation will require appropriate > registration for any > foreign keys used and such. This registration and checking will of > course slow down the modification of the databases, and also > add a level > of unreliability. > > In the case of objects in the RIPE database, we are extremely > read-heavy, and write-light. However, referring to foreign objects > means occasionally querying other servers to get the data. With a > proper registration mechanism, objects can be cached locally. I would > prefer NOT to see a DNS-style system, where it is just assumed that > queries provide incorrect data occasionally. It may be the > best answer, > but I think it is avoidable. > > I believe that using references to other Whois databases requires a > great deal of cooperation, at least on the protocol level. Is it > scalable? I suggest that it probably is, for small numbers of Whois > servers. For large numbers of servers, you'll probably need some sort > of graph - a tree perhaps? ;) - to distribute the load. Perhaps some > simulations should be done before moving too far along? > > A bigger question is whether organizations would be willing to bind > their databases together like this, and if so in what fashion. I get > very nervous considering the politics involved. Am I the only one who > thinks it may be an unsurmountable problem? > > I've said it several times now, but this is a Hard Problem. I have > heard Bill Manning say that he thinks it would be worthwhile solving. > Others (unnamed) just seem to want a global NIC-HDL, which I > don't think > buys you anything unless you can use it. I don't think you can use it > unless you tackle the issues here. It seems like a lot of > work for very > little real gain! > > Shane > From owner-ietf-whois Tue Jan 30 14:09:41 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA22392 for ietf-whois-bks; Tue, 30 Jan 2001 14:09:41 -0800 (PST) Received: from alliance.globalnetlink.com (root@alliance.globalnetlink.com [208.185.70.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22388 for ; Tue, 30 Jan 2001 14:09:40 -0800 (PST) From: budi@alliance.globalnetlink.com Received: from pentium3 (ppp8d.dialin.elga.net.id [202.173.64.136]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id QAA21440; Tue, 30 Jan 2001 16:58:30 -0600 Message-Id: <200101302258.QAA21440@alliance.globalnetlink.com> To: ietf-provreg@cafax.se Date: Wed, 31 Jan 2001 05:19:35 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Merging RRP and Whois CC: ietf-whois@imc.org References: <002401c087f7$ed394840$140a0a0a@ambler.net> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 27 Jan 01, at 18:01, Shane Kerr wrote: ... > > I'm sure this has come up in the past, but why not email addresses? > > They're unique, and identify the source. Master information on the > > handle is kept by whatever registry handles the TLD in question. > > I can see that sending to both ietf-provreg and ietf-whois is going to > cause some problems. :( > > NIC handles are used by people who have nothing to do with domains. ... That's ok. Email address is unique and has nothing to do with domain registration and such. Most people keep their email addresses as their identities. -- budi -- Homepage: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id From owner-ietf-whois Tue Jan 30 15:36:46 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA26071 for ietf-whois-bks; Tue, 30 Jan 2001 15:36:46 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA26067 for ; Tue, 30 Jan 2001 15:36:45 -0800 (PST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0UNhUU07537; Tue, 30 Jan 2001 15:43:30 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0UNg8426756; Tue, 30 Jan 2001 15:42:08 -0800 Message-Id: <200101302342.f0UNg8426756@zed.isi.edu> Subject: Unique "Handles"? To: budi@alliance.globalnetlink.com Date: Tue, 30 Jan 2001 15:42:08 -0800 (PST) Cc: ietf-provreg@cafax.se, ietf-whois@imc.org In-Reply-To: <200101302258.QAA21440@alliance.globalnetlink.com> from "budi@alliance.globalnetlink.com" at Jan 31, 2001 05:19:35 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: % > NIC handles are used by people who have nothing to do with domains. % ... % % That's ok. Email address is unique and has nothing to do % with domain registration and such. Most people keep their % email addresses as their identities. % % -- budi Er... not really. I've had email addresses that have been revolked and reassigned to new people. Email addresses are not the persistant indentifer you are looking for. -- --bill From owner-ietf-whois Wed Jan 31 00:55:00 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA29107 for ietf-whois-bks; Wed, 31 Jan 2001 00:55:00 -0800 (PST) Received: from smtp.denic.de (denics1.denic.de [194.246.96.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA29099 for ; Wed, 31 Jan 2001 00:54:59 -0800 (PST) Received: from notes.denic.de (frankfurt.denic.de [194.246.96.101]) by smtp.denic.de with esmtp id 14Nt8W-0006PV-00; Wed, 31 Jan 2001 10:01:09 +0100 Subject: Antwort: Unique "Handles"? To: Bill Manning Cc: budi@alliance.globalnetlink.com, ietf-provreg@cafax.se, ietf-whois@imc.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "=?iso-8859-2?q?J=F6rg_Bauer=2FDenic?=" Date: Wed, 31 Jan 2001 09:59:21 +0100 X-MIMETrack: Serialize by Router on notes/Denic(Release 5.0.4 |June 8, 2000) at 31.01.2001 10:01:19 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 31.01.2001 00:42 Bill Manning wrote: > > % > NIC handles are used by people who have nothing to do with domains. > % ... > % > % That's ok. Email address is unique and has nothing to do > % with domain registration and such. Most people keep their > % email addresses as their identities. > % > % -- budi > > > Er... not really. I've had email addresses that > have been revolked and reassigned to new people. > Email addresses are not the persistant indentifer > you are looking for. > > -- > --bill I strongly agree !!!! > -- ----------------------------------+------------------------------------------- Joerg Bauer | eMail : Joerg.Bauer@denic.de DENIC eG | Fon : +49 69 272 35 180 Wiesenhuettenplatz 26 | Fax : +49 69 27235 235 D-60329 Frankfurt | ----------------------------------+------------------------------------------- From owner-ietf-whois Wed Jan 31 13:36:16 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA29403 for ietf-whois-bks; Wed, 31 Jan 2001 13:36:16 -0800 (PST) Received: from h236.s254.netsol.com (h243.s254.netsol.com [216.168.254.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29398 for ; Wed, 31 Jan 2001 13:36:15 -0800 (PST) Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f0VLgXG07544; Wed, 31 Jan 2001 16:42:33 -0500 Date: Wed, 31 Jan 2001 16:42:33 -0500 From: Mark Kosters To: Shane Kerr Cc: ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010131164233.F7003@netsol.com> References: <20010129103932.A735@register.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from shane@ripe.net on Mon, Jan 29, 2001 at 05:12:24PM +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jan 29, 2001 at 05:12:24PM +0100, Shane Kerr wrote: > Not necessarily. HTTP+HTML implements a distributed database with an > extremely simple client (until you decide to render the HTML, I > suppose) - not that it can't be done wrong (see "RWhois"). I wounder if you could explain in a little more detail why RWhois was done wrong? Mark -- Mark Kosters markk@internic.net InterNIC Registration Services 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 31 14:57:53 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04460 for ietf-whois-bks; Wed, 31 Jan 2001 14:57:53 -0800 (PST) Received: from alliance.globalnetlink.com (root@alliance.globalnetlink.com [208.185.70.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04456 for ; Wed, 31 Jan 2001 14:57:51 -0800 (PST) From: budi@alliance.globalnetlink.com Received: from pentium3 (ppp6.bdg.melsa.net.id [202.138.227.6]) by alliance.globalnetlink.com (8.9.1/8.9.1) with ESMTP id RAA26477; Wed, 31 Jan 2001 17:46:59 -0600 Message-Id: <200101312346.RAA26477@alliance.globalnetlink.com> To: Bill Manning Date: Thu, 1 Feb 2001 06:07:49 +0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Unique "Handles"? CC: ietf-provreg@cafax.se, ietf-whois@imc.org In-reply-to: <200101302342.f0UNg8426756@zed.isi.edu> References: <200101302258.QAA21440@alliance.globalnetlink.com> from "budi@alliance.globalnetlink.com" at Jan 31, 2001 05:19:35 AM X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 30 Jan 01, at 15:42, Bill Manning wrote: > Er... not really. I've had email addresses that > have been revolked and reassigned to new people. > Email addresses are not the persistant indentifer > you are looking for. That's ok, Bill. All you have to do is change/modify/ update your (nic) handle / identifier. (Just like updating a host/NS record in the database.) Note: how long does it have to be presistant? If you are acting as a role, eg. using hostmaster@some.domain then you want to delegate the role to the new hostmaster, don't you? Our original concern was to have a unique identifier that spans to many databases (so that we avoid clashes), no? The possibility to have identifiers clash can be reduced. So my unique handle maybe "budi.alliance.globalnetlink.com.budi.rahardjo.indonesia" (email adress is *part of* unique handle) My beef...: it's too long! But then again, it might be easier to memorize than BR#72X%$@! ;-) Maybe we don't have to memorize it either. Or... we can go with a digital certificate. (That may be too complicate since some countries may restrict access to certain cryptography algorithms.) Or ... find something else. -- budi -- Homepage: my presentation materials, papers, scrapbook, ... and more What's your "web.id"? Register your web.id @ http://www.idnic.net.id From owner-ietf-whois Wed Jan 31 14:59:59 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04611 for ietf-whois-bks; Wed, 31 Jan 2001 14:59:59 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04605 for ; Wed, 31 Jan 2001 14:59:58 -0800 (PST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0VN6mU19228; Wed, 31 Jan 2001 15:06:48 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0VN5Rp28980; Wed, 31 Jan 2001 15:05:27 -0800 Message-Id: <200101312305.f0VN5Rp28980@zed.isi.edu> Subject: Re: Unique "Handles"? To: budi@alliance.globalnetlink.com Date: Wed, 31 Jan 2001 15:05:27 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), ietf-provreg@cafax.se, ietf-whois@imc.org In-Reply-To: <200101312346.RAA26477@alliance.globalnetlink.com> from "budi@alliance.globalnetlink.com" at Feb 01, 2001 06:07:49 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: % % On 30 Jan 01, at 15:42, Bill Manning wrote: % % > Er... not really. I've had email addresses that % > have been revolked and reassigned to new people. % > Email addresses are not the persistant indentifer % > you are looking for. % % That's ok, Bill. All you have to do is change/modify/ % update your (nic) handle / identifier. % (Just like updating a host/NS record in the database.) % Note: how long does it have to be presistant? Er, how does the registrar know that I am me if I can't validate myself since the email "handle" no longer works? % Or... we can go with a digital certificate. % (That may be too complicate since some countries may % restrict access to certain cryptography algorithms.) % % Or ... find something else. Like a PGP key... :) % % % -- budi % -- % Homepage: % my presentation materials, papers, scrapbook, ... and more % What's your "web.id"? Register your web.id @ http://www.idnic.net.id % -- --bill From owner-ietf-whois Thu Feb 1 01:54:42 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA17398 for ietf-whois-bks; Thu, 1 Feb 2001 01:54:42 -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 BAA17392 for ; Thu, 1 Feb 2001 01:54:40 -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 LAA05800; Thu, 1 Feb 2001 11:00:29 +0100 (CET) Date: Thu, 1 Feb 2001 11:00:29 +0100 (CET) From: Shane Kerr To: Mark Kosters cc: Subject: Re: Merging RRP and Whois In-Reply-To: <20010131164233.F7003@netsol.com> 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 Wed, 31 Jan 2001, Mark Kosters wrote: > On Mon, Jan 29, 2001 at 05:12:24PM +0100, Shane Kerr wrote: > > Not necessarily. HTTP+HTML implements a distributed database with an > > extremely simple client (until you decide to render the HTML, I > > suppose) - not that it can't be done wrong (see "RWhois"). > > I wounder if you could explain in a little more detail why RWhois > was done wrong? Well, I guess there's only two problems: the client and the server. :) These may have been fixed while I wasn't looking. As I understand it, the client does not follow referrals. This kind of puts a damper on the whole Referral Whois. Other issues involve the server software. First, if you look at the rwhois mailing lists, you'll see a common problem is people not reindexing the database files and having the server give incorrect results. While you can attribute this to human error ("this sort of thing has happened before, Dave, and it has always been attributable to human error"), the fact that it happens again and again implies that the software should validate these files before loading and giving bogus results. The server software used to incorrectly track child processes, causing the server to refuse connections after extended use (I patched this at ARIN, did I ever send the patches?). Unlike the Whois protocol, the RWhois connection is persistent (well, it can be). This means that cheap methods of preventing clients from overloading the server (i.e. max connections per time) don't work. What we saw at ARIN was that an abusive client could crush the server (admittedly only a Sparc Ultra2 300 or something like that) when attempting to mine the database. The server needs to be restarted to reload the access lists, right? Plus, there's not any standard for what information should appear in an RWhois database. This means that a client has to be prepared for basically ANYTHING. At least the format of the output is specified. Actually, the ability to dynamically query the schema used by a particular server is nice, but without a "core" set of guaranteed values, it doesn't actually buy you much (ever written a TIFF viewer? - same problem). Also, the root for the RWhois tree doesn't appear to be well-maintained: >From http://www.rwhois.net/rwhois/prwhois.html Query Error A connection could not be made to the RWhois server running at root.rwhois.net:4321 $ ping root.rwhois.net PING root.rwhois.net (216.168.227.19): 56 data bytes bounced at 10.192.16.65: Access prohibited bounced at 10.192.16.65: Access prohibited bounced at 10.192.16.65: Access prohibited no reply from root.rwhois.net no reply from root.rwhois.net bounced at 10.192.16.65: Access prohibited bounced at 10.192.16.65: Access prohibited ^C $ traceroute root.rwhois.net traceroute to root.rwhois.net (216.168.227.19): 1-30 hops, 38 byte packets 1 e10.overtoom.ripe.net (193.0.1.126), 2.13 ms, 2.79 ms, 1.76 ms 2 Asd-nr02.NL.kpnqwest.net (134.222.249.81), 8.38 ms, 2.19 ms, 2.88 ms 19 sl-gw2-rly-4-0-0.sprintlink.net (144.232.14.46), 93.8 ms (ttl=240!), 94.4 ms (ttl=240!), 93.6 ms (ttl=240!) 20 sl-netsolut-2-0-0.sprintlink.net (144.232.184.78), 98.6 ms (ttl=239!), 102 ms (ttl=239!), 96.5 ms (ttl=239!) 21 10.192.16.65 (10.192.16.65), 95.4 ms (ttl=238!), 95.9 ms (ttl=238!), 95.5 ms (ttl=238!) 22 10.192.16.65 (10.192.16.65), 95.6 ms (ttl=238!) !U *, 96.2 ms (ttl=238!) !U Hmm...wasn't there a discussion about exposing private IP addresses on NANOG recently? Anyway, even when the root WAS working, it didn't actually refer IP queries to ARIN, which would have been the logical thing to do. At least, for the "referral" in RWhois to mean anything. Then there's the issue of acceptance and use in the wider community. Maintenance of RWhois software always seemed sporadic to me - but is that really unfair, considering the only ones who really need and/or use the protocol and software are ARIN and some of ARIN's larger ISP members. Admittedly, most of these items have nothing at all to do with the RWhois protocol itself. But with only a single implementation and a user base I can count on my toes, it's hard to separate the implementation problems from the protocol problems. Perhaps a modern, threaded RWhois server using an SQL back-end, with a client dropped into popular Linux distributions and on a web page would make my concerns seem silly. But would something like that actually allow Randy Bush to have a globally unique nic-handle? (That is why this list is here, right?) -- Shane From owner-ietf-whois Thu Feb 1 11:17:02 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA26512 for ietf-whois-bks; Thu, 1 Feb 2001 11:17:02 -0800 (PST) Received: from pinion.admin.cto.netsol.com (h227.s254.netsol.com [216.168.254.227]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26508 for ; Thu, 1 Feb 2001 11:17:00 -0800 (PST) Received: by pinion.admin.cto.netsol.com (Postfix, from userid 551) id F334A57DCC; Thu, 1 Feb 2001 14:23:24 -0500 (EST) To: ietf-whois@imc.org Subject: Re: Merging RRP and Whois References: Reply-To: davidb@research.netsol.com From: David Blacka Date: 01 Feb 2001 14:23:24 -0500 In-Reply-To: Message-ID: Lines: 111 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Channel Islands) 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: >>>>> "SK" == Shane Kerr writes: >> I wounder if you could explain in a little more detail why RWhois >> was done wrong? SK> Well, I guess there's only two problems: the client and the server. :) SK> SK> These may have been fixed while I wasn't looking. SK> Based on some of your observerations, I'm guessing that you haven't looked in a while. SK> As I understand it, the client does not follow referrals. This SK> kind of puts a damper on the whole Referral Whois. This was definitely an embarrassing problem for some time. As of early 2000, all the released clients follow referrals, including the web based ones. SK> Other issues involve the server software. SK> First, if you look at the rwhois mailing lists, you'll see a SK> common problem is people not reindexing the database files and SK> having the server give incorrect results. While you can SK> attribute this to human error ("this sort of thing has happened SK> before, Dave, and it has always been attributable to human SK> error"), the fact that it happens again and again implies that SK> the software should validate these files before loading and SK> giving bogus results. There are many, many unfriendly aspects to the rwhois server. This example actually isn't the most common problem. The most common problem is forgetting to index at all. SK> The server software used to incorrectly track child processes, SK> causing the server to refuse connections after extended use (I SK> patched this at ARIN, did I ever send the patches?). This has been fixed for a long time. I don't remember patches being sent in about this, particularly. SK> Unlike the Whois protocol, the RWhois connection is persistent SK> (well, it can be). This means that cheap methods of preventing SK> clients from overloading the server (i.e. max connections per SK> time) don't work. What we saw at ARIN was that an abusive client SK> could crush the server (admittedly only a Sparc Ultra2 300 or SK> something like that) when attempting to mine the database. The SK> server needs to be restarted to reload the access lists, right? No, this was never true, as the access control was implemented via TCP_Wrappers, which reads the ACL files for every request. This problem was solvable in a number of ways: you could've disabled the -holdconnect directive (which isn't all that nice), or the server could've been modified to count responses or requests per IP, rather than connections. Or you could've used a proxy that did that, which is what we did. SK> Plus, there's not any standard for what information should appear SK> in an RWhois database. This means that a client has to be SK> prepared for basically ANYTHING. At least the format of the SK> output is specified. Actually, the ability to dynamically query SK> the schema used by a particular server is nice, but without a SK> "core" set of guaranteed values, it doesn't actually buy you much SK> (ever written a TIFF viewer? - same problem). I can agree with this. Reliance on schema discovery presented a very difficult client programming problem. This is nit-picking, but there is a set of 'core' values: ID, Auth-Area, Class. They just don't extend into the application area. In the beginning of the project, it was thought that someone who wanted to use RWhois for a particular application would demand a particular core schema would be used. RWhois just didn't have a method for publishing these schema. SK> Also, the root for the RWhois tree doesn't appear to be SK> well-maintained: True. The RWhois project is basically on ice here. SK> Hmm...wasn't there a discussion about exposing private IP SK> addresses on NANOG recently? Anyway, even when the root WAS SK> working, it didn't actually refer IP queries to ARIN, which would SK> have been the logical thing to do. At least, for the "referral" SK> in RWhois to mean anything. The root has referred IP address stuff to ARIN for some time now. SK> Then there's the issue of acceptance and use in the wider SK> community. Maintenance of RWhois software always seemed sporadic SK> to me - but is that really unfair, considering the only ones who SK> really need and/or use the protocol and software are ARIN and SK> some of ARIN's larger ISP members. It always surprised me that no one, especially ARIN, stepped forward to take a more active role in RWhois. SK> Perhaps a modern, threaded RWhois server using an SQL back-end, SK> with a client dropped into popular Linux distributions and on a SK> web page would make my concerns seem silly. But would something SK> like that actually allow Randy Bush to have a globally unique SK> nic-handle? (That is why this list is here, right?) My guess is that a more modern RWhois client/server implementations would make the operational concerns take a back seat to more significant protocol problems. -- David Blacka Sr. Research Engineer Verisign Applied Research From owner-ietf-whois Thu Feb 1 12:46:29 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA03486 for ietf-whois-bks; Thu, 1 Feb 2001 12:46:29 -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 MAA03479 for ; Thu, 1 Feb 2001 12:46:27 -0800 (PST) Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f11Kkb612937; Thu, 1 Feb 2001 15:46:37 -0500 (EST) Date: Thu, 1 Feb 2001 15:46:15 -0500 From: Mark Kosters To: Shane Kerr Cc: ietf-whois@imc.org Subject: Re: Merging RRP and Whois Message-ID: <20010201154615.J11501@slam.admin.cto.netsol.com> References: <20010131164233.F7003@netsol.com> 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 Thu, Feb 01, 2001 at 11:00:29AM +0100 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Feb 01, 2001 at 11:00:29AM +0100, Shane Kerr wrote: > Plus, there's not any standard for what information should appear in an > RWhois database. This means that a client has to be prepared for > basically ANYTHING. At least the format of the output is specified. > Actually, the ability to dynamically query the schema used by a > particular server is nice, but without a "core" set of guaranteed > values, it doesn't actually buy you much (ever written a TIFF viewer? - > same problem). One of the problems that killed x.500 was its rigid fixed schema. There are multiple other reasons as well why x.500 died but won't go into it here. Another issue was the inability of the RIR's to come to some sort of agreement on a commmon schema. These two things pushed RWhois to use flexible schemas that had to be "discovered". > Also, the root for the RWhois tree doesn't appear to be well-maintained: > > >From http://www.rwhois.net/rwhois/prwhois.html > > Query Error > > A connection could not be made to the RWhois server running at > root.rwhois.net:4321 It was was wedged and now is fixed. Thanks for the notice. > $ traceroute root.rwhois.net > traceroute to root.rwhois.net (216.168.227.19): 1-30 hops, 38 byte packets > 1 e10.overtoom.ripe.net (193.0.1.126), 2.13 ms, 2.79 ms, 1.76 ms > 2 Asd-nr02.NL.kpnqwest.net (134.222.249.81), 8.38 ms, 2.19 ms, 2.88 ms > > 19 sl-gw2-rly-4-0-0.sprintlink.net (144.232.14.46), 93.8 ms (ttl=240!), 94.4 ms (ttl=240!), 93.6 ms (ttl=240!) > 20 sl-netsolut-2-0-0.sprintlink.net (144.232.184.78), 98.6 ms (ttl=239!), 102 ms (ttl=239!), 96.5 ms (ttl=239!) > 21 10.192.16.65 (10.192.16.65), 95.4 ms (ttl=238!), 95.9 ms (ttl=238!), 95.5 ms (ttl=238!) > 22 10.192.16.65 (10.192.16.65), 95.6 ms (ttl=238!) !U *, 96.2 ms (ttl=238!) !U > > Hmm...wasn't there a discussion about exposing private IP addresses on > NANOG recently? Anyway, even when the root WAS working, it didn't > actually refer IP queries to ARIN, which would have been the logical > thing to do. At least, for the "referral" in RWhois to mean anything. Apologies on the net 10 stuff. The routing people have been notified here to get that fixed. Regarding referrals on ip addresses, referrals do go to ARIN (if you want to check. > Admittedly, most of these items have nothing at all to do with the > RWhois protocol itself. But with only a single implementation and a > user base I can count on my toes, it's hard to separate the > implementation problems from the protocol problems. This is where I really wanted to go. If one was to make a new protocol, is there any thing would one want to want to add on to or modify in creating a new protocol? RWhois was built to solve this distributed "whois" info lookup problem. Perhaps some of the ideas could be used in a improved protocol that could be widely accepted. Thanks, 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 Thu Feb 1 15:47:37 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA13464 for ietf-whois-bks; Thu, 1 Feb 2001 15:47:37 -0800 (PST) Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13460 for ; Thu, 1 Feb 2001 15:47:34 -0800 (PST) Received: from dstc.edu.au (sunburn.dstc.edu.au [130.102.176.16]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id f11Nrie22114; Fri, 2 Feb 2001 09:53:44 +1000 (EST) To: Mark Kosters cc: Shane Kerr , ietf-whois@imc.org Subject: Re: Merging RRP and Whois In-reply-to: Your message of "Thu, 01 Feb 2001 15:46:15 EST." <20010201154615.J11501@slam.admin.cto.netsol.com> Date: Fri, 02 Feb 2001 09:54:14 +1000 Message-ID: <24595.981071654@dstc.edu.au> From: George Michaelson Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One of the problems that killed x.500 was its rigid fixed schema. There are multiple other reasons as well why x.500 died but won't go into it here. Another issue was the inability of the RIR's to come to some sort of agreement on a commmon schema. These two things pushed RWhois to use flexible schemas that had to be "discovered". Hang on: you want to say X.500 died becasue its schema was too rigid, but that RIRS have to come to an agreement on a common schema!? Ok. so nobody wants to re-visit that swamp, but I do want to comment on one thing: X.500 death reflected many things, including the realization there was a considerable IPR value in the directory contents, for each owner of that content: no company wanted that much exposed information just given away, if available at all. Whois as used by RIR is not a _generalized_ directory: Its purposeful and relates to information which is deemed to be in the public interest to maintain (be it exposed or not). As an example its in the public interest for a maintainer to have a record that lets them maintain routing records etc, even if the password they use is not exposed, or if its a role-handle and not a named person. Sure, its also in that ISPs interest, but that doesn't 'collide' - its complementary. So for me, a *narrow* purposeful distributed database, means a defined, tight schema. I think thats probably agreement btw. -George From owner-ietf-whois Sun Feb 4 18:07:52 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA13787 for ietf-whois-bks; Sun, 4 Feb 2001 18:07:52 -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 SAA13782 for ; Sun, 4 Feb 2001 18:07:46 -0800 (PST) Received: from zhuyulaptop (unknown [203.126.116.227]) by mail.i-dns.net (Postfix) with SMTP id 8D22FFFC04 for ; Mon, 5 Feb 2001 10:14:32 +0800 (SGT) Message-ID: <004801c08f19$34c95ce0$7d00a8c0@zhuyulaptop> From: "Zhu Yu" To: Subject: Date: Mon, 5 Feb 2001 10:13:18 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C08F5C.42C98480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C08F5C.42C98480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe ietf-whois ------=_NextPart_000_0045_01C08F5C.42C98480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
subscribe = ietf-whois
------=_NextPart_000_0045_01C08F5C.42C98480-- From owner-ietf-whois Mon Feb 12 11:32:26 2001 Received: by above.proper.com (8.9.3/8.9.3) id LAA16902 for ietf-whois-bks; Mon, 12 Feb 2001 11:32:26 -0800 (PST) Received: from heron.verisign.com ([216.168.233.95]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA16896 for ; Mon, 12 Feb 2001 11:32:25 -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 OAA17953 for ; Mon, 12 Feb 2001 14:31:57 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F9D5N>; Mon, 12 Feb 2001 14:26:37 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'ietf-whois@imc.org'" Subject: IETF-50 BOF? Date: Mon, 12 Feb 2001 14:26:37 -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: Will there be another whois BOF at IETF-50? There was nothing on the draft agenda as of a few moments ago. From owner-ietf-whois Wed Feb 21 02:05:36 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id CAA14291 for ietf-whois-bks; Wed, 21 Feb 2001 02:05:36 -0800 (PST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA14277 for ; Wed, 21 Feb 2001 02:05:34 -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 LAA24069 for ; Wed, 21 Feb 2001 11:04:02 +0100 (CET) Date: Wed, 21 Feb 2001 11:04:02 +0100 (CET) From: Shane Kerr To: ietf-whois@imc.org Subject: Suggestion about foreign NIC-HDL in Whois 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: All, As I was complai^Wtalking about Whois with a collegue last night (hi Ambrose!), I thought of an alternate method of handling foreign keys. Note on nomenclature: "local" means in the Whois database of the server being queried "foreign" means in the Whois database of a different server "object" means database record "key" means attribute of the record, usually a NIC-HDL To date, my thoughts have been: "If I have a reference to a foreign object, and something happens to that object, I am hosed." A sample object from the RIPE database as an example: inetnum: 192.168.1.0 - 192.168.1.255 netname: NET-TEN-HUT descr: A horse is a horse, of course, of course. country: NL admin-c: BOBS-ARIN tech-c: MARYK-ARIN status: ASSIGNED PA mnt-by: SHANE-MNT changed: shane@ripe.net 20010221 source: RIPE If BOBS-ARIN gets deleted, suddenly there is no administrative contact information. This can be prevented for objects in the same database, but for foreign objects, preventing this is Very Difficult, as I tried to express in previous e-mails. However, it occurred to me that this isn't really the problem that I thought it was. The person who is responsible for this inetnum object is the one who is also responsible for keeping it up to date. Rather than PREVENT the inconsistencies, we simply need to FIX them. A server needs to: 1. Detect inconsistencies. 2. Fix inconsistencies. 3. Insure required relationships are maintained. 4. Help database users maintain these relationships. In more detail: 1. Detect inconsistencies What I propose is that the Whois server verify the accuracy of a foreign object whenever a user attempts to access it. This occurs: A. When a foreign key is added to a local object. B. When a local object with a foreign key is queried. So when an object is created and a foreign object is referenced, the server needs to at that time verify the object exists. If it does not, then the database modification should be refused. Further, when a client queries and object with a reference to a foreign object, then it should verify that the foreign object exists at that time. If it does not, then an inconsistency has occurred and needs to be fixed. An update can be treated by verifying the new object, and if it fails, proceed to verify the old object as on query. 2. Fix inconsistencies If an inconsistency is detected, then it must be resolved. The easiest way to do this is to delete the attribute that references the missing data. Additional modifications to the object may be necessary, depending on the database (e.g. "changed" attribute added or a "remark" appended). Since most of the time this will occur during a query, this should be done transparently. That is, if I have a tech-c that is invalid, the rest of the attributes of the object should be returned to the query. 3. Insure required relationships are maintained. Unless done carefully, this automatic updating of objects may lead to invalid database states. For example, in the NET-TEN-HUT inetnum object above, if the BOBS-ARIN object is deleted, then an attempt to remove the admin-c attribute will result in a required attribute no longer being present. This can be prevented by adding additional logic to the creation of objects. In the case of RPSL objects, I suggest that this may be as simple as: "If all references to objects not stored locally are deleted, the object must still be valid." So a revised version of the sample object might be: inetnum: 192.168.1.0 - 192.168.1.255 netname: NET-TEN-HUT descr: A horse is a horse, of course, of course. country: NL admin-c: BOBS-ARIN admin-c: SHANE-RIPE tech-c: MARYK-ARIN tech-c: SHANE-RIPE status: ASSIGNED PA mnt-by: SHANE-MNT changed: shane@ripe.net 20010221 source: RIPE This allows database operators to guarantee they will have valid information about their records, even if all foreign objects are deleted. It is not as flexible as using foreign keys in the same way as local keys, but at least it allows their use. 4. Help database users maintain these relationships. A database that operates in this fashion should alert users to changes in their objects so they can update them accordingly if need be. For example in the sample object above, if MARYK-ARIN is deleted, then the maintainer of the object, SHANE-MNT, would be sent an e-mail documenting this. I would suggest that databases should keep a copy of the most recent version of the foreign object to be sent to the user. In this case, the user would get an e-mail like, "A record from the ARIN database called MARYK-ARIN has been deleted. It was referenced by NET-TEN-HUT. The latest information we had was: ...". One possible implication of this approach is a lot of extra Whois queries between servers if it becomes popular. In this event, a cache mechanism could be employed, with the usual benefits and caveats. This approach will prevent the possiblity of broken references, or the need for servers to create objects without a user requesting it (one of the proposed solutions to the problem). Thoughts? -- Shane From owner-ietf-whois Mon Feb 26 14:36:29 2001 Received: by above.proper.com (8.9.3/8.9.3) id OAA09635 for ietf-whois-bks; Mon, 26 Feb 2001 14:36:29 -0800 (PST) Received: from vortex.cto.netsol.com (h45.s254.netsol.com [216.168.254.45]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA09630 for ; Mon, 26 Feb 2001 14:36:28 -0800 (PST) Received: from zed.admin.cto.netsol.com (zed.admin.cto.netsol.com [216.168.254.216]) by vortex.cto.netsol.com (Postfix) with ESMTP id 390B3DE7A for ; Mon, 26 Feb 2001 17:35:57 -0500 (EST) Received: (from anewton@localhost) by zed.admin.cto.netsol.com (8.9.1b+Sun/8.9.1) id RAA27479 for ietf-whois@imc.org; Mon, 26 Feb 2001 17:09:58 -0500 (EST) Date: Mon, 26 Feb 2001 17:09:58 -0500 From: Andrew Newton To: ietf-whois@imc.org Subject: XDAP Message-ID: <20010226170958.B27421@zed.admin.cto.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have recenly submitted 3 drafts which are relevant to some of the discussions on this list. For all you who have read Scott's EPP drafts, you will notice a similar approach. http://www.ietf.org/internet-drafts/draft-newton-xdap-00.txt This document describes an application layer client-server protocol for a framework of representing the query and result operations of directory services. Specified in XML, the protocol defines generic directory query and result operations and a mechanism for extending these operations for specific directory service needs. http://www.ietf.org/internet-drafts/draft-newton-xdap-ipdir-00.txt This document describes an XDAP directory namespace and schema for registered Internet address information. The schema extends the necessary query and result operations of XDAP to provide a functional equivalent of the whois command syntaxes and results often used by IP registries. http://www.ietf.org/internet-drafts/draft-newton-xdap-domdir-00.txt This document describes an XDAP directory namespace and schema for registered DNS information. The schema extends the necessary query and result operations of XDAP to provide a functional equivalent of the whois command syntaxes and results often used by domain registries and registrars. -andy -- Andrew Newton anewton@research.netsol.com From owner-ietf-whois Sun Mar 4 11:49:16 2001 Received: by above.proper.com (8.9.3/8.9.3) id LAA11834 for ietf-whois-bks; Sun, 4 Mar 2001 11:49:16 -0800 (PST) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA11830 for ; Sun, 4 Mar 2001 11:49:15 -0800 (PST) Received: from w2000 (unknown [203.121.83.143]) by mail.i-dns.net (Postfix) with SMTP id CA56AFFC03; Mon, 5 Mar 2001 03:48:46 +0800 (SGT) Message-ID: <006801c0a4e3$a36ec150$018b10ac@dready.org> From: "William Tan" To: , Subject: Signed response Date: Mon, 5 Mar 2001 03:45:15 +0800 Organization: i-DNS.net Internation Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The PKIX WG has a Online Cert Status Protocol (OCSP) proposal where the CA runs a service like this answering queries about the status of issued certificates, signing the responses. The concept of signed response by the CA (in this case, registry / registrar) may be an important requirement for whois and status request on provreg. The reasons are: 1. Result of whois & status queries have been used by lawyers as evidence in court of law 2. Authenticity of content - client can verify the integrity of the answer (important data to sign would be 'Database-updated-date', the query result, or 'No-such-record-at-this-time'). Maybe we should consider this part of the requirement. wil. From owner-ietf-whois Mon Mar 5 05:02:30 2001 Received: by above.proper.com (8.9.3/8.9.3) id FAA21428 for ietf-whois-bks; Mon, 5 Mar 2001 05:02:30 -0800 (PST) Received: from heron.verisign.com ([216.168.233.95]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA21423 for ; Mon, 5 Mar 2001 05:02:29 -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 IAA03567; Mon, 5 Mar 2001 08:01:56 -0500 (EST) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1Q9F93NQ>; Mon, 5 Mar 2001 07:55:56 -0500 Message-ID: From: "Hollenbeck, Scott" To: "'William Tan'" , ietf-whois@imc.org, ietf-provreg@cafax.se Subject: RE: Signed response Date: Mon, 5 Mar 2001 07:55:55 -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: I believe GRRP requirement 11-[2] in the new -00 requirements draft covers the possibility of signature services if so desired by a registry operator. Those requirements don't apply to whois, though, so maybe it's something to consider if/when requirements for whois enhancements are developed. -----Original Message----- From: William Tan [mailto:william.tan@i-dns.net] Sent: Sunday, March 04, 2001 2:45 PM To: ietf-whois@imc.org; ietf-provreg@cafax.se Subject: Signed response The PKIX WG has a Online Cert Status Protocol (OCSP) proposal where the CA runs a service like this answering queries about the status of issued certificates, signing the responses. The concept of signed response by the CA (in this case, registry / registrar) may be an important requirement for whois and status request on provreg. The reasons are: 1. Result of whois & status queries have been used by lawyers as evidence in court of law 2. Authenticity of content - client can verify the integrity of the answer (important data to sign would be 'Database-updated-date', the query result, or 'No-such-record-at-this-time'). Maybe we should consider this part of the requirement. wil. From owner-ietf-whois Sun Apr 22 07:31:41 2001 Received: by above.proper.com (8.9.3/8.9.3) id HAA04679 for ietf-whois-bks; Sun, 22 Apr 2001 07:31:41 -0700 (PDT) Received: from nic-naa.net (dt0b4n5b.maine.rr.com [24.95.12.91]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA04674 for ; Sun, 22 Apr 2001 07:31:38 -0700 (PDT) Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f3MEUvG02218 for ; Sun, 22 Apr 2001 10:30:57 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200104221430.f3MEUvG02218@nic-naa.net> To: ietf-whois@imc.org Subject: Recent whois list traffic Date: Sun, 22 Apr 2001 10:30:57 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On March 4th, six weeks ago, Scott replied to a suggestion by William Tan sent to both the whois and provreg lists, on signature services. There is nothing further in the ietf-whois list archive [1]. If this list has gone dead, then all the heat and faint light of the IETF-49 BoF are memories, and someone (an AD or other capable and disinterested person) should sweep up the debris from this list and post the summary. This should not be the case. The :48 problem may be solved by abandonment, but that simply means that :48 implementors will find no other guidance in the IETF's {BCP,FYI,RFC,STD} series than rfc954 [2] (DS), and whatever the implementors and their delegating-authories negociate as manditory. These non-rfc954 mandates by their nature are implementor:delegating-authority specific, and could contain requirements similar to the "just use XML" suggestion made early in this list's life. The case for "anything other than -> response -> close connection" [3], e.g.: o the distinction between "technical" and "social" data [4], definitions and repositories, o policy-labeled (EU/OEDC: "data collection", US "privacy"), o encodings other than LDH ASCII (see "technical" and "social"), o referral (navigation for distributed data models), o schema -- a core and one (or more) extension mechanisms, and for those looking for adventure (and having read Harald's latest roman a cle, [5]) o uniqueness and scope, o repository method and method temporal properties, o consistency (consistency for distributed data models), o security (integrity, access, see also policy-labels, above), o update models (or invalidation), is still TBD, with little actual closure on either technical guidance to ICANN, one well-known delegating-authority, or on a post-43 WG Charter. I'm happy (sort of) taking my (.biz) whois:43 and post-43 implementor issues to other similarly situated (fat gTLD registry) implementors outside of the IETF, and (less so) to the .biz delegating-authority. However, this seems to lead to a whois:43 and/or post-43 set of services that has a rich, complex, even baroque taxonomy, in which implementors, models, and above all (pun) delegating-authorities fail to make use of the IETF as a (current) standards body. My sympathies to anyone pouring over Appendix O this weekend. Cheers, Eric References: [1] http://www.imc.org/ietf-whois/mail-archive/ [2] RFC0954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Status: DRAFT STANDARD) [3] Mark Kosters to ietf-whois, Re: Minutes from San Diego, 17 Jan 2001 [4] draft-ietf-provreg-dn-defn-00 [5] draft-alvestrand-directory-defs-02.txt From owner-ietf-whois Sun Apr 22 08:24:04 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA08619 for ietf-whois-bks; Sun, 22 Apr 2001 08:24:04 -0700 (PDT) Received: from mail.i-dns.net (mail.i-dns.net [203.126.116.228]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA08613 for ; Sun, 22 Apr 2001 08:24:02 -0700 (PDT) Received: from w2000 (unknown [203.121.54.22]) by mail.i-dns.net (Postfix) with SMTP id 8FC0DFFC0F; Sun, 22 Apr 2001 23:27:06 +0800 (SGT) Message-ID: <000f01c0cb3f$c0890fc0$0100a8c0@dready.org> From: "William Tan" To: , "Eric Brunner-Williams in Portland Maine" References: <200104221430.f3MEUvG02218@nic-naa.net> Subject: Re: Recent whois list traffic Date: Sun, 22 Apr 2001 23:20:20 +0800 Organization: i-DNS.net Internation Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit 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 sure hope it's not dead. I believe that Patrik Fältström has an unreleased draft for whois, which looks almost good-to-go to me. wil ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" To: Sent: Sunday, April 22, 2001 10:30 PM Subject: Recent whois list traffic > On March 4th, six weeks ago, Scott replied to a suggestion by William Tan > sent to both the whois and provreg lists, on signature services. There is > nothing further in the ietf-whois list archive [1]. If this list has gone > dead, then all the heat and faint light of the IETF-49 BoF are memories, > and someone (an AD or other capable and disinterested person) should sweep > up the debris from this list and post the summary. > > This should not be the case. The :48 problem may be solved by abandonment, > but that simply means that :48 implementors will find no other guidance in > the IETF's {BCP,FYI,RFC,STD} series than rfc954 [2] (DS), and whatever the > implementors and their delegating-authories negociate as manditory. These > non-rfc954 mandates by their nature are implementor:delegating-authority > specific, and could contain requirements similar to the "just use XML" > suggestion made early in this list's life. > > The case for "anything other than -> response -> close > connection" [3], e.g.: > o the distinction between "technical" and "social" data [4], > definitions and repositories, > o policy-labeled (EU/OEDC: "data collection", US "privacy"), > o encodings other than LDH ASCII (see "technical" and "social"), > o referral (navigation for distributed data models), > o schema -- a core and one (or more) extension mechanisms, > and for those looking for adventure (and having read Harald's latest roman > a cle, [5]) > o uniqueness and scope, > o repository method and method temporal properties, > o consistency (consistency for distributed data models), > o security (integrity, access, see also policy-labels, above), > o update models (or invalidation), > is still TBD, with little actual closure on either technical guidance to > ICANN, one well-known delegating-authority, or on a post-43 WG Charter. > > I'm happy (sort of) taking my (.biz) whois:43 and post-43 implementor issues > to other similarly situated (fat gTLD registry) implementors outside of the > IETF, and (less so) to the .biz delegating-authority. However, this seems to > lead to a whois:43 and/or post-43 set of services that has a rich, complex, > even baroque taxonomy, in which implementors, models, and above all (pun) > delegating-authorities fail to make use of the IETF as a (current) standards > body. > > My sympathies to anyone pouring over Appendix O this weekend. > > Cheers, > Eric > > References: > [1] http://www.imc.org/ietf-whois/mail-archive/ > [2] RFC0954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. > Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) > (Status: DRAFT STANDARD) > [3] Mark Kosters to ietf-whois, Re: Minutes from San Diego, 17 Jan 2001 > [4] draft-ietf-provreg-dn-defn-00 > [5] draft-alvestrand-directory-defs-02.txt From owner-ietf-whois Wed Jun 20 06:58:51 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KDwpk20142 for ietf-whois-bks; Wed, 20 Jun 2001 06:58:51 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KDwok20138 for ; Wed, 20 Jun 2001 06:58:50 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f5KDvgM18829; Wed, 20 Jun 2001 09:57:42 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106201357.f5KDvgM18829@nic-naa.net> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: discuss@apps.ietf.org, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Scheduling for London In-Reply-To: Your message of "Mon, 18 Jun 2001 15:57:12 +0200." <7726865.992879832@localhost> Date: Wed, 20 Jun 2001 09:57:42 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Patrik, I suggest we (again) attempt something in the whois-space, with clear demarkations between :43 massage (presentation issues), :xx structure (centralized, collaborative/delegated/... post-43 mega-massage (the whole xml opera) Eric From owner-ietf-whois Wed Jun 20 09:49:51 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KGnpl29204 for ietf-whois-bks; Wed, 20 Jun 2001 09:49:51 -0700 (PDT) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KGnnk29200 for ; Wed, 20 Jun 2001 09:49:49 -0700 (PDT) Received: from [10.0.1.3] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA16895; Wed, 20 Jun 2001 18:49:38 +0200 (MET DST) Date: Wed, 20 Jun 2001 18:47:04 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Eric Brunner-Williams in Portland Maine cc: discuss@apps.ietf.org, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Scheduling for London Message-ID: <1254047.993062824@localhost> In-Reply-To: <200106201357.f5KDvgM18829@nic-naa.net> References: <200106201357.f5KDvgM18829@nic-naa.net> X-Mailer: Mulberry/2.1.0a6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --On 01-06-20 09.57 -0400 Eric Brunner-Williams in Portland Maine wrote: > I suggest we (again) attempt something in the whois-space, with clear > demarkations between > :43 massage (presentation issues), > :xx structure (centralized, collaborative/delegated/... > post-43 mega-massage (the whole xml opera) I am happy to do that. Will you take the lead and come up with an agenda for the BOF? paf From owner-ietf-whois Wed Jun 20 10:28:40 2001 Received: by above.proper.com (8.11.3/8.11.3) id f5KHSeM00530 for ietf-whois-bks; Wed, 20 Jun 2001 10:28:40 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KHSdk00526 for ; Wed, 20 Jun 2001 10:28:39 -0700 (PDT) Received: from bbdesk.brandenburg.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA06678; Wed, 20 Jun 2001 10:28:32 -0700 Message-Id: <5.1.0.14.2.20010620101104.03824e68@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Jun 2001 10:14:53 -0700 To: Eric Brunner-Williams in Portland Maine From: Dave Crocker Subject: Re: Scheduling for London Cc: discuss@apps.ietf.org, ietf-whois@imc.org, brunner@nic-naa.net In-Reply-To: <200106201357.f5KDvgM18829@nic-naa.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 06:57 AM 6/20/2001, Eric Brunner-Williams in Portland Maine wrote: >I suggest we (again) attempt something in the whois-space, with clear >demarkations between > :43 massage (presentation issues), > :xx structure (centralized, collaborative/delegated/... > post-43 mega-massage (the whole xml opera) (patrik's confirmation is happily noted, however...) Given that we have had two false starts on this topic, already, I'd like to raise the concern that the previous false start seemed -- to me, at least -- pretty clearly to be focused ONLY on creation of a data structure standard for :43 responses. However the discussion got sidetracked with other, larger and more difficult issues. Perhaps the agenda was not as clear as I thought it was. Hence, being more clear this time will suffice (he said, optimistically.) Perhaps something deeper is at issue. If so, can we try to surface it and dispatch it? d/ ---------- Dave Crocker Brandenburg InternetWorking tel: +1.408.246.8253; fax: +1.408.273.6464 From owner-ietf-whois Wed Jun 20 12:56:28 2001 Received: by above.proper.com (8.11.3/8.11.3) id f5KJuSr04253 for ietf-whois-bks; Wed, 20 Jun 2001 12:56:28 -0700 (PDT) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KJuQk04249 for ; Wed, 20 Jun 2001 12:56:26 -0700 (PDT) Received: from [0.0.0.0] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA18498; Wed, 20 Jun 2001 21:55:34 +0200 (MET DST) Date: Wed, 20 Jun 2001 21:47:27 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Dave Crocker , Eric Brunner-Williams in Portland Maine cc: discuss@apps.ietf.org, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: Scheduling for London Message-ID: <1446963.993073647@localhost> In-Reply-To: <5.1.0.14.2.20010620101104.03824e68@brandenburg.com> References: <5.1.0.14.2.20010620101104.03824e68@brandenburg.com> X-Mailer: Mulberry/2.1.0a6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --On 01-06-20 10.14 -0700 Dave Crocker wrote: > Perhaps the agenda was not as clear as I thought it was. Hence, being > more clear this time will suffice (he said, optimistically.) > > Perhaps something deeper is at issue. If so, can we try to surface it > and dispatch it? That's why I wanted someone to take the lead. I.e. my positive reaction was because (a) something _has_ to be done, especially with the port 43 protocol, and for other things we have the LDAP proposal from Verisign/NSI and (b) given an agenda which all of us with knifes in our backs is happy with, I will schedule the BOF. But, as Dave says, this is not a walk in the park. Significant work is needed before a meeting will be fruitful. paf From owner-ietf-whois Wed Jun 20 14:07:17 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KL7Hh06052 for ietf-whois-bks; Wed, 20 Jun 2001 14:07:17 -0700 (PDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KL7Fk06048 for ; Wed, 20 Jun 2001 14:07:15 -0700 (PDT) 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 RAA09006; Wed, 20 Jun 2001 17:07:11 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 16:58:33 -0400 Message-ID: From: "Hollenbeck, Scott" To: discuss@apps.ietf.org, ietf-whois@imc.org Subject: RE: Scheduling for London Date: Wed, 20 Jun 2001 16:58:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f5KL7Fk06049 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Wednesday, June 20, 2001 3:47 PM > To: Dave Crocker; Eric Brunner-Williams in Portland Maine > Cc: discuss@apps.ietf.org; ietf-whois@imc.org; brunner@nic-naa.net > Subject: Re: Scheduling for London > But, as Dave says, this is not a walk in the park. Significant work is > needed before a meeting will be fruitful. How relevant do folks see the work previously agreed to within ICANN circles to prescribe the info that must be returned in response to a domain name query? Good building block, or still too muddled to form the basis of something to work from? From owner-ietf-whois Wed Jun 20 14:11:46 2001 Received: by above.proper.com (8.11.3/8.11.3) id f5KLBkx06205 for ietf-whois-bks; Wed, 20 Jun 2001 14:11:46 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KLBjk06201 for ; Wed, 20 Jun 2001 14:11:45 -0700 (PDT) Received: from bbdesk.brandenburg.com (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA13898; Wed, 20 Jun 2001 14:11:41 -0700 Message-Id: <5.1.0.14.2.20010620141128.024a1f30@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Jun 2001 14:13:21 -0700 To: "Hollenbeck, Scott" From: Dave Crocker Subject: RE: Scheduling for London Cc: discuss@apps.ietf.org, ietf-whois@imc.org In-Reply-To: Mime-Version: 1.0 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: ahhh. yes. Thanks, Scott. NOW I remember why things got bogged down: The problem is with needing to distinguish mechanism from policy. The constrained IETF efforts needs to specify mechanism only. If possible, it should "require" no specific data in a response. Any that it DOES require should be very minimal and utterly essential to operational requirements. The real policy work, for deciding what to put in a response, can be debated elsewhere. d/ At 01:58 PM 6/20/2001, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: Patrik Fältström [mailto:paf@cisco.com] > > Sent: Wednesday, June 20, 2001 3:47 PM > > To: Dave Crocker; Eric Brunner-Williams in Portland Maine > > Cc: discuss@apps.ietf.org; ietf-whois@imc.org; brunner@nic-naa.net > > Subject: Re: Scheduling for London > > > > But, as Dave says, this is not a walk in the park. Significant work is > > needed before a meeting will be fruitful. > >How relevant do folks see the work previously agreed to within ICANN circles >to prescribe the info that must be returned in response to a domain name >query? Good building block, or still too muddled to form the basis of >something to work from? > > ---------- Dave Crocker Brandenburg InternetWorking tel: +1.408.246.8253; fax: +1.408.273.6464 From owner-ietf-whois Wed Jun 20 14:14:44 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KLEii06313 for ietf-whois-bks; Wed, 20 Jun 2001 14:14:44 -0700 (PDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KLEhk06309 for ; Wed, 20 Jun 2001 14:14:43 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CpJA-000O5Q-00; Wed, 20 Jun 2001 14:14:40 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Hollenbeck, Scott" Cc: discuss@apps.ietf.org, ietf-whois@imc.org Subject: RE: Scheduling for London References: Message-Id: Date: Wed, 20 Jun 2001 14:14:40 -0700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > How relevant do folks see the work previously agreed to within ICANN circles > to prescribe the info that must be returned in response to a domain name > query? not to port 43 whois. but we've had this discussion before, have we not? randy From owner-ietf-whois Wed Jun 20 14:58:56 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KLwun07612 for ietf-whois-bks; Wed, 20 Jun 2001 14:58:56 -0700 (PDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KLwpk07607 for ; Wed, 20 Jun 2001 14:58:55 -0700 (PDT) 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 RAA09228; Wed, 20 Jun 2001 17:58:14 -0400 (EDT) Received: by regdom-ex01.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 17:49:35 -0400 Message-ID: From: "Hollenbeck, Scott" To: "'Randy Bush'" Cc: discuss@apps.ietf.org, ietf-whois@imc.org Subject: RE: Scheduling for London Date: Wed, 20 Jun 2001 17:49:31 -0400 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: > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, June 20, 2001 5:15 PM > To: Hollenbeck, Scott > Cc: discuss@apps.ietf.org; ietf-whois@imc.org > Subject: RE: Scheduling for London > > > > How relevant do folks see the work previously agreed to within ICANN circles > > to prescribe the info that must be returned in response to a domain name > > query? > > not to port 43 whois. but we've had this discussion before, > have we not? Indeed we have, with the chaotic results described earlier on this thread. Now that Dave's question regarding how we managed to get bogged down has been partially answered, we should carefully consider the scope of a BoF agenda to make sure that we don't resurrect this topic again -- with the possible exception of being very clear that it's _not_ relevant. From owner-ietf-whois Thu Jun 21 09:26:11 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5LGQBv07657 for ietf-whois-bks; Thu, 21 Jun 2001 09:26:11 -0700 (PDT) Received: from penguin.ripe.net (penguin.ripe.net [193.0.1.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5LGQ9k07653 for ; Thu, 21 Jun 2001 09:26:09 -0700 (PDT) Received: (from shane@localhost) by penguin.ripe.net (8.10.2/8.10.2) id f5LGPLp00963; Thu, 21 Jun 2001 18:25:21 +0200 Date: Thu, 21 Jun 2001 18:25:21 +0200 From: Shane Kerr To: "Hollenbeck, Scott" Cc: discuss@apps.ietf.org, ietf-whois@imc.org Subject: Re: Scheduling for London Message-ID: <20010621182518.A949@penguin.ripe.net> References: 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 shollenbeck@verisign.com at 2001-06-20 16:58:29 -0400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2001-06-20 16:58:29 -0400, Hollenbeck, Scott wrote: > > > -----Original Message----- > > From: Patrik Fältström [mailto:paf@cisco.com] > > Sent: Wednesday, June 20, 2001 3:47 PM > > To: Dave Crocker; Eric Brunner-Williams in Portland Maine > > Cc: discuss@apps.ietf.org; ietf-whois@imc.org; brunner@nic-naa.net > > Subject: Re: Scheduling for London > > > But, as Dave says, this is not a walk in the park. Significant work > > is needed before a meeting will be fruitful. > > How relevant do folks see the work previously agreed to within ICANN > circles to prescribe the info that must be returned in response to a > domain name query? Good building block, or still too muddled to form > the basis of something to work from? While I may not be "relevant", could you please point me and any other folks who might not be part of the ICANN circles to some place we could find out what the info that must be returned is? (FWIW, while the RIPE NCC is an RIR, we do domain name queries on the side.) Thanks! -- Shane From owner-ietf-whois Wed Jun 27 06:22:02 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5RDM2V09712 for ietf-whois-bks; Wed, 27 Jun 2001 06:22:02 -0700 (PDT) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RDM0m09705 for ; Wed, 27 Jun 2001 06:22:00 -0700 (PDT) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.4/8.11.4) with ESMTP id f5RDKw703417; Wed, 27 Jun 2001 15:20:59 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200106271320.f5RDKw703417@bartok.sidn.nl> To: Dave Crocker cc: "Hollenbeck, Scott" , discuss@apps.ietf.org, ietf-whois@imc.org Subject: Re: Scheduling for London In-reply-to: Your message of Wed, 20 Jun 2001 14:13:21 -0700. <5.1.0.14.2.20010620141128.024a1f30@brandenburg.com> Date: Wed, 27 Jun 2001 15:20:58 +0200 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The real policy work, for deciding what to put in a response, can be debated elsewhere. I believe that the DNSO is trying to so, see: DNSO Names Council Whois Survey, http://www.icann.org/dnso/whois-survey-en-10jun01.htm for details. Policy is starting to be the big thing. The Dutch registration chamber (a kinf of privacy in database protection agency) planning to look into what a whois service might provide and what not. And this is of course not only for domain related data, but also for the adress people, such as the RIPE NCC whois service. jaap From owner-ietf-whois Wed Jun 27 09:53:46 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5RGrke20662 for ietf-whois-bks; Wed, 27 Jun 2001 09:53:46 -0700 (PDT) Received: from penguin.ripe.net (penguin.ripe.net [193.0.1.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5RGrim20658 for ; Wed, 27 Jun 2001 09:53:44 -0700 (PDT) Received: (from shane@localhost) by penguin.ripe.net (8.10.2/8.10.2) id f5RGrXm28015; Wed, 27 Jun 2001 18:53:33 +0200 Date: Wed, 27 Jun 2001 18:53:33 +0200 From: Shane Kerr To: Jaap Akkerhuis Cc: discuss@apps.ietf.org, ietf-whois@imc.org Subject: Re: Scheduling for London Message-ID: <20010627185333.J24596@penguin.ripe.net> References: <5.1.0.14.2.20010620141128.024a1f30@brandenburg.com> <200106271320.f5RDKw703417@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106271320.f5RDKw703417@bartok.sidn.nl>; from jaap@sidn.nl at 2001-06-27 15:20:58 +0200 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2001-06-27 15:20:58 +0200, Jaap Akkerhuis wrote: > > > The real policy work, for deciding what to put in a response, can be > debated elsewhere. > > I believe that the DNSO is trying to so, see: DNSO Names Council Whois > Survey, http://www.icann.org/dnso/whois-survey-en-10jun01.htm > for details. > > Policy is starting to be the big thing. The Dutch registration chamber > (a kinf of privacy in database protection agency) planning to look > into what a whois service might provide and what not. And this is of > course not only for domain related data, but also for the adress > people, such as the RIPE NCC whois service. Indeed. We have been contacted by the Dutch information authority concerning the information in our Whois database, and are working with them on this issue. -- Shane Kerr RIPE NCC From owner-ietf-whois Tue Jul 31 10:52:06 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6VHq6708753 for ietf-whois-bks; Tue, 31 Jul 2001 10:52:06 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VHq4s08749 for ; Tue, 31 Jul 2001 10:52:05 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.4/8.9.3) with ESMTP id f6VHoDN28992; Tue, 31 Jul 2001 13:50:13 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200107311750.f6VHoDN28992@nic-naa.net> To: ietf-provreg@cafax.se, ietf-whois@imc.org cc: brunner@nic-naa.net, dcrocker@brandenburg.com Subject: IETF-51 WhoisFix BoF Announcement Date: Tue, 31 Jul 2001 13:50:12 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: FYI, The agenda will be posted on the IETF-51 web site in a day or so. Thanks, Eric WHOISFix BoF co-chair ANNOUNCEMENT ------------ Yet another attempt will be made to create a working group providing minimal enhancements to the WHOIS (port 43) service. This BOF will review a proposed charter and a proposed specification for enhancements. This round of effort will be marked by extremely narrow focus and extremely tight management to maintain that focus. The technical goals for the enhancement effort will be to: specify a common, structured query format, specify a means for server query redirection, specify server-server queries, and specify standardized whois structured response formats. Character set and data protection (privacy) issues are included in the query and response format goals. From owner-ietf-whois Tue Jul 31 11:47:01 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6VIl1409798 for ietf-whois-bks; Tue, 31 Jul 2001 11:47:01 -0700 (PDT) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VIkxs09792 for ; Tue, 31 Jul 2001 11:46:59 -0700 (PDT) Received: from rrader2k.pc.internal.tucows.com ([10.0.10.4] helo=RRADER2K) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 15ReXK-0005Uf-00; Tue, 31 Jul 2001 14:46:34 -0400 Message-ID: <039801c119f1$22c6a120$040a000a@RRADER2K> Reply-To: "Ross Wm. Rader" From: "Ross Wm. Rader" To: , , "Eric Brunner-Williams in Portland Maine" Cc: , References: <200107311750.f6VHoDN28992@nic-naa.net> Subject: Re: IETF-51 WhoisFix BoF Announcement Date: Tue, 31 Jul 2001 14:46:40 -0400 Organization: Tucows Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Eric, Correct me if my recollection is wrong, but the last go-round of this was severely bogged down by a focus on the protocol specified in RFC 954 when in fact the discussion was more suited to the concepts and facilities presented in 1580 (starting on page 38). Is it the intent to focus on the latter than the former this time around? While I couldn't agree more that changes are due, it strikes me that updating 954 may prove to be next to impossible because of the hidden install base... Sorry if this is off-topic for this list - I won't be in London to speak my piece... -rwr ----- Original Message ----- From: "Eric Brunner-Williams in Portland Maine" To: ; Cc: ; Sent: Tuesday, July 31, 2001 1:50 PM Subject: IETF-51 WhoisFix BoF Announcement > > FYI, > > The agenda will be posted on the IETF-51 web site in a day or so. > > Thanks, > Eric > WHOISFix BoF co-chair > > ANNOUNCEMENT > ------------ > Yet another attempt will be made to create a working group providing > minimal enhancements to the WHOIS (port 43) service. > > This BOF will review a proposed charter and a proposed specification > for enhancements. This round of effort will be marked by extremely > narrow focus and extremely tight management to maintain that focus. > > The technical goals for the enhancement effort will be to: > specify a common, structured query format, > specify a means for server query redirection, > specify server-server queries, and > specify standardized whois structured response formats. > > Character set and data protection (privacy) issues are included in the query > and response format goals. From owner-ietf-whois Wed Aug 1 00:55:37 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f717tbK09835 for ietf-whois-bks; Wed, 1 Aug 2001 00:55:37 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f717tYs09830 for ; Wed, 1 Aug 2001 00:55:35 -0700 (PDT) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.11.4/8.11.4) with ESMTP id f717tTi05722; Wed, 1 Aug 2001 09:55:29 +0200 Received: (from shane@localhost) by x17.ripe.net (8.10.2/8.10.2) id f717tSB04126; Wed, 1 Aug 2001 09:55:28 +0200 Date: Wed, 1 Aug 2001 09:55:28 +0200 From: Shane Kerr To: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement Message-ID: <20010801095528.C4082@x17.ripe.net> References: <200107311750.f6VHoDN28992@nic-naa.net> <039801c119f1$22c6a120$040a000a@RRADER2K> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <039801c119f1$22c6a120$040a000a@RRADER2K>; from ross@tucows.com at 2001-07-31 14:46:40 -0400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2001-07-31 14:46:40 -0400, Ross Wm. Rader wrote: > > Correct me if my recollection is wrong, but the last go-round of this > was severely bogged down by a focus on the protocol specified in RFC > 954 when in fact the discussion was more suited to the concepts and > facilities presented in 1580 (starting on page 38). Is it the intent > to focus on the latter than the former this time around? Hmm... I wouldn't necessarily have a problem focusing on the *concepts* behind 1580, but the *details* have mostly changed, I think. Does anyone run a mail Whois server these days? ;) > While I couldn't agree more that changes are due, it strikes me that > updating 954 may prove to be next to impossible because of the hidden > install base... I wonder, would it make sense to consider putting together a survey of Whois (and similar) servers and clients, to get a feel for what Whois really means these days? It would be nice to know how it is actually used, so we don't spend too much time scratching our heads. If people consider this a good idea, I can go ahead and present a brief summary of what I think should be in such a document. > Sorry if this is off-topic for this list - I won't be in London to > speak my piece... This seems totally on-topic to me! At least, for the Whois BOF. Should we take the ProvReg WG off of the recipient list? -- Shane From owner-ietf-whois Wed Aug 1 02:17:34 2001 Received: by above.proper.com (8.11.3/8.11.3) id f719HYH17334 for ietf-whois-bks; Wed, 1 Aug 2001 02:17:34 -0700 (PDT) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f719HVs17330 for ; Wed, 1 Aug 2001 02:17:32 -0700 (PDT) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.4/8.11.4) with ESMTP id f719HJH41923; Wed, 1 Aug 2001 11:17:19 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200108010917.f719HJH41923@bartok.sidn.nl> To: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement In-reply-to: Your message of Wed, 01 Aug 2001 09:55:28 +0200. <20010801095528.C4082@x17.ripe.net> Date: Wed, 01 Aug 2001 11:17:19 +0200 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I wonder, would it make sense to consider putting together a survey of Whois (and similar) servers and clients, to get a feel for what Whois really means these days? It would be nice to know how it is actually used, so we don't spend too much time scratching our heads. If people consider this a good idea, I can go ahead and present a brief summary of what I think should be in such a document. The DNSO is already running such a survey. See http://www.icann.org/dnso/whois-survey-en-10jun01.htm for details. This seems totally on-topic to me! At least, for the Whois BOF. Should we take the ProvReg WG off of the recipient list? Probably, allthough I didn't yet. jaap From owner-ietf-whois Wed Aug 1 02:38:41 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f719cfA18663 for ietf-whois-bks; Wed, 1 Aug 2001 02:38:41 -0700 (PDT) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f719cds18658 for ; Wed, 1 Aug 2001 02:38:39 -0700 (PDT) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.4/8.11.4) with ESMTP id f719cYH42039 for ; Wed, 1 Aug 2001 11:38:34 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200108010938.f719cYH42039@bartok.sidn.nl> To: ietf-whois@imc.org Subject: DNSO Announcement about WHOIS survey In-reply-to: Your message of Wed, 01 Aug 2001 11:17:19 +0200. <200108010917.f719HJH41923@bartok.sidn.nl> Date: Wed, 01 Aug 2001 11:38:34 +0200 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Just in case anybody missed it, here is the latest announcement about the survey. jaap Date: Tue, 31 Jul 2001 20:20:28 +0200 (MET DST) From: DNSO Secretariat To: announce@dnso.org Subject: [announce] Extention to the WHOIS Consultaion period [ To: council@dnso.org ] [ To: announce@dnso.org, ga@dnso.org ] [ To: liaison7c@dnso.org ] The Names Council WHOIS Committee of the DNSO today agreed to extend the WHOIS consultation period until the 14th August 2001. The survey http://www.icann.org/dnso/whois-survey-en-10jun01.htm is available in English, French, Spanish Russian and Japanese is part of a major international survey which has already been completed by over 2000 respondents. The purpose of the survey is to potentially review the current policy regarding the availability names and addresses associated with the registered holders of domain name (internet addresses). The WHOIS Committee will be reviewing all comments submitted and then drafting a report reflecting the views of the respondents, identifying where there is satisfaction with the WHOIS environment and where improvements to the ICANN WHOIS policy could be considered. All internet users are invited to participate in the survey. A preliminary report will be given to the Names Council meeting during the ICANN Montevideo, Uruguay meeting, scheduled between the 7-10th September 2001. DNSO Secretariat -- From owner-ietf-whois Wed Aug 1 06:42:54 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71Dgs828882 for ietf-whois-bks; Wed, 1 Aug 2001 06:42:54 -0700 (PDT) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71Dgrs28875 for ; Wed, 1 Aug 2001 06:42:53 -0700 (PDT) Received: from rrader2k.pc.internal.tucows.com ([10.0.10.4] helo=RRADER2K) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 15RwGt-0004BT-00 for ietf-whois@imc.org; Wed, 01 Aug 2001 09:42:47 -0400 Message-ID: <003801c11a8f$dd5b2cb0$040a000a@RRADER2K> Reply-To: "Ross Wm. Rader" From: "Ross Wm. Rader" To: References: <200108010917.f719HJH41923@bartok.sidn.nl> Subject: Re: IETF-51 WhoisFix BoF Announcement Date: Wed, 1 Aug 2001 09:42:53 -0400 Organization: Tucows Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > The DNSO is already running such a survey. See > http://www.icann.org/dnso/whois-survey-en-10jun01.htm for details. ...which is completely domain/registry/registrar specific. Completely fine by me, but the results are most certainly going to be skewed towards one particular application. AFAIK, no attempt whatsoever has been made within this survey to attempt to take into account non-domain applications. > > This seems totally on-topic to me! At least, for the Whois BOF. Should > we take the ProvReg WG off of the recipient list? > > Probably, allthough I didn't yet. ;) I did. -rwr From owner-ietf-whois Wed Aug 1 06:49:41 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71Dnf429102 for ietf-whois-bks; Wed, 1 Aug 2001 06:49:41 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71Dnds29097 for ; Wed, 1 Aug 2001 06:49:39 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.4/8.9.3) with ESMTP id f71DlrN32089; Wed, 1 Aug 2001 09:47:53 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200108011347.f71DlrN32089@nic-naa.net> To: Shane Kerr cc: ietf-provreg@cafax.se, ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: IETF-51 WhoisFix BoF Announcement In-Reply-To: Your message of "Wed, 01 Aug 2001 09:55:28 +0200." <20010801095528.C4082@x17.ripe.net> Date: Wed, 01 Aug 2001 09:47:53 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Shane, Ross, and others, The annoucement went to several lists, provreg included. It is not in provreg's scope to discuss whois. I suggest sending comments to me or Dave, or the ietf-whois list, or even the apps and or ops area open discussion lists. Cheers, Eric From owner-ietf-whois Wed Aug 1 07:15:44 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71EFi129812 for ietf-whois-bks; Wed, 1 Aug 2001 07:15:44 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71EFhs29808 for ; Wed, 1 Aug 2001 07:15:43 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.4/8.9.3) with ESMTP id f71EE5N32211; Wed, 1 Aug 2001 10:14:05 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200108011414.f71EE5N32211@nic-naa.net> To: Jaap Akkerhuis cc: ietf-whois@imc.org, brunner@nic-naa.net, paul.kane@io.io Subject: Re: DNSO Announcement about WHOIS survey In-Reply-To: Your message of "Wed, 01 Aug 2001 11:38:34 +0200." <200108010938.f719cYH42039@bartok.sidn.nl> Date: Wed, 01 Aug 2001 10:14:05 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The survey solicits a response via form. I submitted my response via email. The person I suggest sending email responses to is Paul Kane, who can be reached at: paul.kane@io.io. I know my response was forwarded to him. In my response I took pains to distinguish between operational requirements which are met on port 43, and other requirements which need not be met on port 43, and may be better met by another protocol on another port. Knowing that the author of the survey is the DNSO, I did not address the aspects of a survey intended to inform an ASO-interested, as well as a DNSO-interested reader. Ross is correct in pointing out this limitation of the DNSO's survey. There are other limitations as well. Those known to me I mentioned in my response, which I'll post to this list if there is interest. NOTE WELL: the IETF-51 WHOISFix BOF announcement, agenda, proposed charter, proposed timeline and deliverables, are self-contained and will be available at the IETF-51 Agenda URL [1] shortly, having been sent to the secretariate on 07/30. Eric [1] http://www.ietf.org/meetings/wg_agenda_51.html From owner-ietf-whois Wed Aug 1 07:35:48 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71EZmF00511 for ietf-whois-bks; Wed, 1 Aug 2001 07:35:48 -0700 (PDT) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71EZls00507 for ; Wed, 1 Aug 2001 07:35:47 -0700 (PDT) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.4/8.11.4) with ESMTP id f71EZeH42797; Wed, 1 Aug 2001 16:35:40 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200108011435.f71EZeH42797@bartok.sidn.nl> To: "Ross Wm. Rader" cc: ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement In-reply-to: Your message of Wed, 01 Aug 2001 09:42:53 -0400. <003801c11a8f$dd5b2cb0$040a000a@RRADER2K> Date: Wed, 01 Aug 2001 16:35:40 +0200 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ...which is completely domain/registry/registrar specific. Completely fine by me, but the results are most certainly going to be skewed towards one particular application. AFAIK, no attempt whatsoever has been made within this survey to attempt to take into account non-domain applications. At least, you can point that out to them, as Eric suggested. Talking about Paul Kane, he will probably around. I forgot the details of the agenda, but I hope one of the items is to discuss the scope of applications which wil use port 43 and theirs limits. I remember that, eons ago, we used it in-house as a source to look up digitized pictures of colleges and in the institute next door they used it to find empty conference rooms. We have things as ldap and friends to do these. jaap From owner-ietf-whois Wed Aug 1 07:47:20 2001 Received: by above.proper.com (8.11.3/8.11.3) id f71ElKJ02689 for ietf-whois-bks; Wed, 1 Aug 2001 07:47:20 -0700 (PDT) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71ElIs02685 for ; Wed, 1 Aug 2001 07:47:18 -0700 (PDT) Received: from rrader2k.pc.internal.tucows.com ([10.0.10.4] helo=RRADER2K) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 15RxHE-0000b8-00; Wed, 01 Aug 2001 10:47:12 -0400 Message-ID: <00fc01c11a98$dd498a60$040a000a@RRADER2K> Reply-To: "Ross Wm. Rader" From: "Ross Wm. Rader" To: "Jaap Akkerhuis" Cc: References: <200108011435.f71EZeH42797@bartok.sidn.nl> Subject: Re: IETF-51 WhoisFix BoF Announcement Date: Wed, 1 Aug 2001 10:47:19 -0400 Organization: Tucows Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Jaap Akkerhuis" To: "Ross Wm. Rader" Cc: Sent: Wednesday, August 01, 2001 10:35 AM Subject: Re: IETF-51 WhoisFix BoF Announcement > > > ...which is completely domain/registry/registrar specific. Completely fine > by me, but the results are most certainly going to be skewed > towards one particular application. AFAIK, no attempt whatsoever > has been made within this survey to attempt to take into account > non-domain applications. > > At least, you can point that out to them, as Eric suggested. Talking > about Paul Kane, he will probably around. My point was not to criticize the DNSO effort but to point out that a) the applicability of their results will be of limited (but still useful value) to the Whois BoF effort and b) that discussing Whois in purely a domain context is just plain wrong unless the BoF consciously determines this limitation and reduces the scope accordingly. In other words, if the goal is to replace or augment 954, then let's say so, but be extremely clear that the range of applications based on 954 or not purely domain-specific. If on the other hand, the goal is to augment the functionality of domain-specific whois, then let's take a look at what is currently going on over port 43 and look to rfc 1580 for historical guidance.... > > I forgot the details of the agenda, but I hope one of the items is > to discuss the scope of applications which wil use port 43 and > theirs limits. > -rwr From owner-ietf-whois Wed Aug 1 09:53:46 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71Grk610590 for ietf-whois-bks; Wed, 1 Aug 2001 09:53:46 -0700 (PDT) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71Grjs10585 for ; Wed, 1 Aug 2001 09:53:45 -0700 (PDT) Received: from [10.10.20.173] (helo=[169.254.254.68]) by rcommail2 with esmtp (Exim 3.16 #2) id 15RzFV-0002Vn-00; Wed, 01 Aug 2001 12:53:33 -0400 Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: <00fc01c11a98$dd498a60$040a000a@RRADER2K> References: <200108011435.f71EZeH42797@bartok.sidn.nl> <00fc01c11a98$dd498a60$040a000a@RRADER2K> Date: Wed, 1 Aug 2001 12:53:26 -0400 To: "Ross Wm. Rader" , "Jaap Akkerhuis" From: "Jordyn A. Buchanan" Subject: Re: IETF-51 WhoisFix BoF Announcement Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Ross Wm. Rader" wrote: > point was not to criticize the DNSO effort but to point out that a) the >applicability of their results will be of limited (but still useful value) >to the Whois BoF effort and b) that discussing Whois in purely a domain >context is just plain wrong unless the BoF consciously determines this >limitation and reduces the scope accordingly. In other words, if the goal is >to replace or augment 954, then let's say so, but be extremely clear that >the range of applications based on 954 or not purely domain-specific. If on >the other hand, the goal is to augment the functionality of domain-specific >whois, then let's take a look at what is currently going on over port 43 and >look to rfc 1580 for historical guidance.... RFC 1580 is an interesting, historical and informational document. It also doesn't accurately reflect the way that Whois is being used by very many (if any) people today. If our goal is to try and take a look at what is currently going on over port 43, RFC 1580 is not going to be very descriptive of the status quo. As long as the structure imposed on port 43 queries is made in a way that doesn't prevent unstructured queries from functioning as they do now (which probably just means that new clients still need to be able to deal with unstructured results somehow, probably just by dumping them to the screen as occurs now), the existence of other types of queries becomes not very important. Those other uses will simply continued unaffected. Jordyn From owner-ietf-whois Wed Aug 1 10:19:41 2001 Received: by above.proper.com (8.11.3/8.11.3) id f71HJfA11492 for ietf-whois-bks; Wed, 1 Aug 2001 10:19:41 -0700 (PDT) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71HJds11485 for ; Wed, 1 Aug 2001 10:19:39 -0700 (PDT) Received: from rrader2k.pc.internal.tucows.com ([10.0.10.4] helo=RRADER2K) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 15Rzec-00031T-00 for ietf-whois@imc.org; Wed, 01 Aug 2001 13:19:30 -0400 Message-ID: <022801c11aae$2375f810$040a000a@RRADER2K> Reply-To: "Ross Wm. Rader" From: "Ross Wm. Rader" Cc: References: <200108011435.f71EZeH42797@bartok.sidn.nl> <00fc01c11a98$dd498a60$040a000a@RRADER2K> Subject: Re: IETF-51 WhoisFix BoF Announcement Date: Wed, 1 Aug 2001 13:19:36 -0400 Organization: Tucows Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >look to rfc 1580 for historical guidance.... > > RFC 1580 is an interesting, historical and informational document. Agreed. > It also doesn't accurately reflect the way that Whois is being used > by very many (if any) people today. Disagree - I, for one, use it very much as described in 1580 on a regular basis... > If our goal is to try and take a > look at what is currently going on over port 43, RFC 1580 is not > going to be very descriptive of the status quo. >From 1580... "WHOIS provides directory service to network users. This service is a way of finding e-mail addresses, postal addresses and telephone numbers. It may also deliver information about networks, networking organizations, domains and sites." "In its current implementation, WHOIS has some limitations which prevent it from becoming an efficient directory service for a large volume of information and numerous requests: the various WHOIS servers have no knowledge of each other, a database is maintained at each server site, and, finally, new functionalities have been implemented locally at various sites and not propagated." "WHOIS is available to users on the international TCP/IP network (the Internet). A WHOIS server is accessible across the network from a user program running on local machines or via an interactive Telnet session to the site which hosts the server." "In general, WHOIS servers should only be used for isolated queries about specific information. Typically, it is not acceptable to make an extended series of queries to obtain large sections of the directory. Such a strategy is unfair both because of excessive consumption of server resources, and because the directory information belongs to individuals. In particular, extracting lists of people for commercial purposes is strictly prohibited." Sections 6.4.1, 6.4.2 and 6.5 also provide some great cues for new implementations.... It sounds pretty descriptive of a number of status quo's to me... > > As long as the structure imposed on port 43 queries is made in a way > that doesn't prevent unstructured queries from functioning as they do > now (which probably just means that new clients still need to be able > to deal with unstructured results somehow, probably just by dumping > them to the screen as occurs now), the existence of other types of > queries becomes not very important. Those other uses will simply > continued unaffected. > To rephrase your last sentence..."We must make sure that other uses will continue unaffected." -rwr From owner-ietf-whois Wed Aug 1 10:28:02 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71HS2B11700 for ietf-whois-bks; Wed, 1 Aug 2001 10:28:02 -0700 (PDT) Received: from newman.cto.netsol.com (h44.s231.netsol.com [216.168.231.44]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71HS1s11693 for ; Wed, 1 Aug 2001 10:28:01 -0700 (PDT) Received: from zed.admin.cto.netsol.com (zed.admin.cto.netsol.com [216.168.231.216]) by newman.cto.netsol.com (Postfix) with ESMTP id 54A2E43835; Wed, 1 Aug 2001 13:27:58 -0400 (EDT) Received: (from anewton@localhost) by zed.admin.cto.netsol.com (8.9.3+Sun/8.9.1) id NAA08491; Wed, 1 Aug 2001 13:25:28 -0400 (EDT) Date: Wed, 1 Aug 2001 13:25:28 -0400 From: Andrew Newton To: "Ross Wm. Rader" Cc: Jaap Akkerhuis , ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement Message-ID: <20010801132528.B8437@zed.admin.cto.netsol.com> References: <200108011435.f71EZeH42797@bartok.sidn.nl> <00fc01c11a98$dd498a60$040a000a@RRADER2K> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <00fc01c11a98$dd498a60$040a000a@RRADER2K>; from ross@tucows.com on Wed, Aug 01, 2001 at 10:47:19AM -0400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 01, 2001 at 10:47:19AM -0400, Ross Wm. Rader wrote: > > My point was not to criticize the DNSO effort but to point out that a) the > applicability of their results will be of limited (but still useful value) > to the Whois BoF effort and b) that discussing Whois in purely a domain > context is just plain wrong unless the BoF consciously determines this > limitation and reduces the scope accordingly. In other words, if the goal is > to replace or augment 954, then let's say so, but be extremely clear that > the range of applications based on 954 or not purely domain-specific. If on > the other hand, the goal is to augment the functionality of domain-specific > whois, then let's take a look at what is currently going on over port 43 and > look to rfc 1580 for historical guidance.... Are you suggesting that there are multiple ways in which the BOF should properly scope its work, such as: 1) in reference to domains only 2) domains, IP registries, etc. 3) the most commonly known use(es) of whois (which is probably #2) 4) as a general directory service. -- Andrew Newton VeriSign Applied Research anewton@research.netsol.com From owner-ietf-whois Wed Aug 1 10:31:04 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71HV4x11794 for ietf-whois-bks; Wed, 1 Aug 2001 10:31:04 -0700 (PDT) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71HV2s11789 for ; Wed, 1 Aug 2001 10:31:02 -0700 (PDT) Received: from rrader2k.pc.internal.tucows.com ([10.0.10.4] helo=RRADER2K) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 15Rzph-0003v4-00 for ietf-whois@imc.org; Wed, 01 Aug 2001 13:30:57 -0400 Message-ID: <024601c11aaf$bd2d0dd0$040a000a@RRADER2K> Reply-To: "Ross Wm. Rader" From: "Ross Wm. Rader" Cc: References: <200108011435.f71EZeH42797@bartok.sidn.nl> <00fc01c11a98$dd498a60$040a000a@RRADER2K> <20010801132528.B8437@zed.admin.cto.netsol.com> Subject: Re: IETF-51 WhoisFix BoF Announcement Date: Wed, 1 Aug 2001 13:31:03 -0400 Organization: Tucows Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Are you suggesting that there are multiple ways in which the BOF should > properly scope its work, such as: > 1) in reference to domains only > 2) domains, IP registries, etc. > 3) the most commonly known use(es) of whois (which is probably #2) > 4) as a general directory service. Precisely - your translation is appreciated ;) Lack of awareness around these issues seemed to completely distract the BoF last time around. "WhoisNext" is of tremendous value to an incredibly large number of entities and I really want to see this effort move forward. -rwr From owner-ietf-whois Wed Aug 1 11:02:06 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71I26412588 for ietf-whois-bks; Wed, 1 Aug 2001 11:02:06 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71I25s12584 for ; Wed, 1 Aug 2001 11:02:05 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.4/8.9.3) with ESMTP id f71I0PN33222; Wed, 1 Aug 2001 14:00:25 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200108011800.f71I0PN33222@nic-naa.net> To: "Ross Wm. Rader" cc: ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: IETF-51 WhoisFix BoF Announcement In-Reply-To: Your message of "Wed, 01 Aug 2001 13:31:03 EDT." <024601c11aaf$bd2d0dd0$040a000a@RRADER2K> Date: Wed, 01 Aug 2001 14:00:25 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > "WhoisNext" is of tremendous value to an incredibly large number of entities > and I really want to see this effort move forward. Then you'll probably want to organize a "WhoisNext" BOF for IETF-52. Eric From owner-ietf-whois Wed Aug 1 11:02:25 2001 Received: by above.proper.com (8.11.3/8.11.3) id f71I2PV12601 for ietf-whois-bks; Wed, 1 Aug 2001 11:02:25 -0700 (PDT) Received: from newman.cto.netsol.com (h44.s231.netsol.com [216.168.231.44]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71I2Ps12597 for ; Wed, 1 Aug 2001 11:02:25 -0700 (PDT) Received: from zed.admin.cto.netsol.com (zed.admin.cto.netsol.com [216.168.231.216]) by newman.cto.netsol.com (Postfix) with ESMTP id 1719043835; Wed, 1 Aug 2001 14:02:22 -0400 (EDT) Received: (from anewton@localhost) by zed.admin.cto.netsol.com (8.9.3+Sun/8.9.1) id NAA08526; Wed, 1 Aug 2001 13:59:53 -0400 (EDT) Date: Wed, 1 Aug 2001 13:59:53 -0400 From: Andrew Newton To: "Ross Wm. Rader" Cc: ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement Message-ID: <20010801135953.A8512@zed.admin.cto.netsol.com> References: <200108011435.f71EZeH42797@bartok.sidn.nl> <00fc01c11a98$dd498a60$040a000a@RRADER2K> <20010801132528.B8437@zed.admin.cto.netsol.com> <024601c11aaf$bd2d0dd0$040a000a@RRADER2K> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <024601c11aaf$bd2d0dd0$040a000a@RRADER2K>; from ross@tucows.com on Wed, Aug 01, 2001 at 01:31:03PM -0400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 01, 2001 at 01:31:03PM -0400, Ross Wm. Rader wrote: > Precisely - your translation is appreciated ;) Lack of awareness around > these issues seemed to completely distract the BoF last time around. > "WhoisNext" is of tremendous value to an incredibly large number of entities > and I really want to see this effort move forward. I'm gonna consider myself a member of the non-enlightened camp with respect to uses of whois outside of domain registries/registrars and IP and routing registries. If it isn't too much trouble, can you list a few of the applications or application types outside of these areas and the possible improvements of to whois which would help them? -andy -- Andrew Newton VeriSign Applied Research anewton@research.netsol.com From owner-ietf-whois Wed Aug 1 11:16:30 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71IGUI13003 for ietf-whois-bks; Wed, 1 Aug 2001 11:16:30 -0700 (PDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71IGSs12998 for ; Wed, 1 Aug 2001 11:16:28 -0700 (PDT) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA07395; Wed, 1 Aug 2001 14:16:18 -0400 (EDT) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 14:16:25 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60B843B@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Eric Brunner-Williams in Portland Maine'" , "Ross Wm. Rader" Cc: ietf-whois@imc.org Subject: RE: IETF-51 WhoisFix BoF Announcement Date: Wed, 1 Aug 2001 14:10:57 -0400 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: >-----Original Message----- >From: Eric Brunner-Williams in Portland Maine >[mailto:brunner@nic-naa.net] >Sent: Wednesday, August 01, 2001 2:00 PM >To: Ross Wm. Rader >Cc: ietf-whois@imc.org; brunner@nic-naa.net >Subject: Re: IETF-51 WhoisFix BoF Announcement > > > >> "WhoisNext" is of tremendous value to an incredibly large number of entities >> and I really want to see this effort move forward. > >Then you'll probably want to organize a "WhoisNext" BOF for IETF-52. Maybe I'm reading this incorrectly, but it still looks like folks might have fundamentally different views on what the scope of the next whois BOF should be. If this is the case, and given that we can hold only so many BOFs on this topic [1], I think it would have been wise to discuss scope and charter for the BOF BEFORE the BOF was scheduled. If the whoisfix BOF fails to produce any tangible results, will it even be possible to try again? [1] http://www.ietf.org/meetings/1bof-procedures.txt From owner-ietf-whois Wed Aug 1 11:30:30 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71IUUg13462 for ietf-whois-bks; Wed, 1 Aug 2001 11:30:30 -0700 (PDT) Received: from h236.s254.netsol.com (h236.s231.netsol.com [216.168.231.236]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71IUTs13458 for ; Wed, 1 Aug 2001 11:30:29 -0700 (PDT) Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f71IUJ203587; Wed, 1 Aug 2001 14:30:19 -0400 (EDT) Date: Wed, 1 Aug 2001 14:30:19 -0400 From: Mark Kosters To: Jaap Akkerhuis Cc: ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement Message-ID: <20010801143019.I3354@slam.admin.cto.netsol.com> References: <003801c11a8f$dd5b2cb0$040a000a@RRADER2K> <200108011435.f71EZeH42797@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200108011435.f71EZeH42797@bartok.sidn.nl>; from jaap@sidn.nl on Wed, Aug 01, 2001 at 04:35:40PM +0200 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 01, 2001 at 04:35:40PM +0200, Jaap Akkerhuis wrote: > I remember that, eons ago, we used it in-house as a source to look > up digitized pictures of colleges and in the institute next door > they used it to find empty conference rooms. We have things as > ldap and friends to do these. LDAP is something that we have been playing with for a while. An example of an ldap service that accesses domain registration data is at: http://www.ldap.research.netsol.com An internet draft that describes this is at: http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-00.txt We have done some thinking on how to handle RIR data and think it may be possible to make it work. RIR data is a bit more complex in dealing with allocation and allocations within an allocation types of searches. Regards, Mark -- Mark Kosters markk@netsol.com Verisign Applied Research From owner-ietf-whois Wed Aug 1 11:33:02 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71IX2Z13540 for ietf-whois-bks; Wed, 1 Aug 2001 11:33:02 -0700 (PDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71IX0s13536 for ; Wed, 1 Aug 2001 11:33:00 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15S0ng-0003Zf-00; Wed, 01 Aug 2001 11:32:56 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Scott Hollenbeck Cc: ietf-whois@imc.org Subject: RE: IETF-51 WhoisFix BoF Announcement References: <3CD14E451751BD42BA48AAA50B07BAD60B843B@vsvapostal3.prod.netsol.com> Message-Id: Date: Wed, 01 Aug 2001 11:32:56 -0700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Maybe I'm reading this incorrectly, but it still looks like folks might > have fundamentally different views on what the scope of the next whois BOF > should be. If this is the case, and given that we can hold only so many > BOFs on this topic [1], I think it would have been wise to discuss scope > and charter for the BOF BEFORE the BOF was scheduled. yes, but how many times? i know that this is the internet, so we have to go around the same cycle every six months. but the rate seems to be increasing. this bof may not break whois port 43 as defined because it is used for many services, some of which we do not even know. otoh, this bof may explore overlays for specific applications, such as trying to address the problems of multiple identities (the handle mess), regularizing overlay applications so screen-scraping can be automated, etc. randy From owner-ietf-whois Wed Aug 1 11:36:05 2001 Received: by above.proper.com (8.11.3/8.11.3) id f71Ia5M13616 for ietf-whois-bks; Wed, 1 Aug 2001 11:36:05 -0700 (PDT) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71Ia3s13612 for ; Wed, 1 Aug 2001 11:36:04 -0700 (PDT) Received: from [10.10.20.173] (helo=[169.254.254.68]) by rcommail2 with esmtp (Exim 3.16 #2) id 15S0py-0002qk-00; Wed, 01 Aug 2001 14:35:18 -0400 Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60B843B@vsvapostal3.prod.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD60B843B@vsvapostal3.prod.netsol.com> Date: Wed, 1 Aug 2001 14:31:05 -0400 To: "Hollenbeck, Scott" , "'Eric Brunner-Williams in Portland Maine'" , "Ross Wm. Rader" From: "Jordyn A. Buchanan" Subject: RE: IETF-51 WhoisFix BoF Announcement Cc: ietf-whois@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:10 PM -0400 8/1/01, Hollenbeck, Scott wrote: > >Maybe I'm reading this incorrectly, but it still looks like folks might have >fundamentally different views on what the scope of the next whois BOF should >be. If this is the case, and given that we can hold only so many BOFs on >this topic [1], I think it would have been wise to discuss scope and charter >for the BOF BEFORE the BOF was scheduled. If the whoisfix BOF fails to >produce any tangible results, will it even be possible to try again? Without attempting to speak too much for someone else, I think that this is Eric's whole point. He's presented a fairly narrow list of activities for discussion within the BOF. These all relate to port 43 whois, and hopefully fixing it in a way that is backwards compatible with the existing query model. I'm actually just assuming that backwards compatibility is one of Eric's goals, but I don't see anything in the announcement which seems to contradict it. If other people want to create a new protocol that does something else, they can do that. As we discovered at IETF 49, trying to have both of those discussions in the same room isn't so productive. Jordyn From owner-ietf-whois Wed Aug 1 11:28:57 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71ISvU13356 for ietf-whois-bks; Wed, 1 Aug 2001 11:28:57 -0700 (PDT) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71ISts13352 for ; Wed, 1 Aug 2001 11:28:55 -0700 (PDT) Received: from rrader2k.pc.internal.tucows.com ([10.0.10.4] helo=RRADER2K) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 15S0jj-000814-00 for ietf-whois@imc.org; Wed, 01 Aug 2001 14:28:51 -0400 Message-ID: <02bf01c11ab7$d3c82090$040a000a@RRADER2K> Reply-To: "Ross Wm. Rader" From: "Ross Wm. Rader" Cc: References: <200108011435.f71EZeH42797@bartok.sidn.nl> <00fc01c11a98$dd498a60$040a000a@RRADER2K> <20010801132528.B8437@zed.admin.cto.netsol.com> <024601c11aaf$bd2d0dd0$040a000a@RRADER2K> <20010801135953.A8512@zed.admin.cto.netsol.com> Subject: Re: IETF-51 WhoisFix BoF Announcement Date: Wed, 1 Aug 2001 14:28:57 -0400 Organization: Tucows Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I'm gonna consider myself a member of the non-enlightened camp with respect > to uses of whois outside of domain registries/registrars and IP and routing > registries. If it isn't too much trouble, can you list a few of the > applications or application types outside of these areas and the possible > improvements of to whois which would help them? A number come to mind - the most apparent of which typically use whois as a simplified interface to a more complex data directory internal to corporations (ie telephone/employee lookup services). As far as specific improvements go, I have none except the hope that whatever the BoF proposes to (hopefully) undertake doesn't break existing deployments. Klensin made a great point last time round that speaks directly to my point - (forgive my brutal paraphrase) "don't propose to understand what people do with these drafts behind closed doors - try to understand how what you are proposing will break what those people do." Regardless of his specific words, his point was extremely clear - at least from my standpoint. This is why I brought up 954 and 1580 in the first place. RFC 954 is a very precise statement of what whois actually is. 1580 discusses specific deployments. If the work is focused on 954, then it goes without saying that the statements in 1580 (and the brother of 1580 that a corporation has writtent to describe their internal service deployment) should still hold true post-fix. -rwr From owner-ietf-whois Wed Aug 1 12:47:23 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71JlNA15734 for ietf-whois-bks; Wed, 1 Aug 2001 12:47:23 -0700 (PDT) Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71JlLs15729 for ; Wed, 1 Aug 2001 12:47:21 -0700 (PDT) Received: from sverresborg.uninett.no (IDENT:root@sverresborg.uninett.no [158.38.60.92]) by tyholt.uninett.no (8.11.3/8.11.3) with ESMTP id f71JlLw09820; Wed, 1 Aug 2001 21:47:21 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.10.1/8.10.1) id f71Jfpf13354; Wed, 1 Aug 2001 21:41:51 +0200 Date: Wed, 1 Aug 2001 21:41:51 +0200 From: Stig Venaas To: Mark Kosters Cc: Jaap Akkerhuis , ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement Message-ID: <20010801214151.A13318@sverresborg.uninett.no> References: <003801c11a8f$dd5b2cb0$040a000a@RRADER2K> <200108011435.f71EZeH42797@bartok.sidn.nl> <20010801143019.I3354@slam.admin.cto.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010801143019.I3354@slam.admin.cto.netsol.com>; from markk@netsol.com on Wed, Aug 01, 2001 at 02:30:19PM -0400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 01, 2001 at 02:30:19PM -0400, Mark Kosters wrote: > LDAP is something that we have been playing with for a while. An example > of an ldap service that accesses domain registration data is at: > http://www.ldap.research.netsol.com I'm doing some work for NORID, the registry responsible for the .no domain. We have plans for storing our "whois"-data in LDAP as well. If several registries stored their data in LDAP and we could agree to some degree on schemas things could get very interesting. It would then be possible to share tools, and it could be possible for a user to use the same tools for different registries. With referrals one could also have data in different LDAP servers with- out the user necessarily knowing it. Some "whois"-implementations today have chaining which has some of the same effect, but referrals are better in my opinion. Currently our registrars are left with the same "whois" interface as everyone else. With LDAP one could give them access to more data or more powerful queries once they authenticate. Well, just some thoughts, Stig From owner-ietf-whois Wed Aug 1 12:57:30 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71JvUP16113 for ietf-whois-bks; Wed, 1 Aug 2001 12:57:30 -0700 (PDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71JvSs16109 for ; Wed, 1 Aug 2001 12:57:28 -0700 (PDT) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA12092; Wed, 1 Aug 2001 15:57:25 -0400 (EDT) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 15:57:31 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60B843D@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Jordyn A. Buchanan'" Cc: ietf-whois@imc.org Subject: RE: IETF-51 WhoisFix BoF Announcement Date: Wed, 1 Aug 2001 15:52:05 -0400 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: >-----Original Message----- >From: Jordyn A. Buchanan [mailto:jordyn@register.com] >Sent: Wednesday, August 01, 2001 2:31 PM >To: Hollenbeck, Scott; 'Eric Brunner-Williams in Portland Maine'; Ross >Wm. Rader >Cc: ietf-whois@imc.org >Subject: RE: IETF-51 WhoisFix BoF Announcement > > >Without attempting to speak too much for someone else, I think that >this is Eric's whole point. He's presented a fairly narrow list of >activities for discussion within the BOF. These all relate to port >43 whois, and hopefully fixing it in a way that is backwards >compatible with the existing query model. I'm actually just assuming >that backwards compatibility is one of Eric's goals, but I don't see >anything in the announcement which seems to contradict it. > >If other people want to create a new protocol that does something >else, they can do that. As we discovered at IETF 49, trying to have >both of those discussions in the same room isn't so productive. Agreed. I didn't suggest that we should try to have both discussions in the same room, and Randy makes a valid point in noting that we can talk about this forever. I also agree that we should try to define a narrow scope and move forward. I want to be sure that we agree that this particular scope is the one to move forward with. If not, as long as the folks who have non-port 43 interests don't get shut out of doing a "Whois: The Next Generation" effort in the future we should be able to do something productive next week. From owner-ietf-whois Wed Aug 1 14:04:12 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71L4C818368 for ietf-whois-bks; Wed, 1 Aug 2001 14:04:12 -0700 (PDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71L4As18364 for ; Wed, 1 Aug 2001 14:04:10 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15S3A5-0008W8-00 for ietf-whois@imc.org; Wed, 01 Aug 2001 14:04:13 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-whois@imc.org Subject: RE: IETF-51 WhoisFix BoF Announcement References: <3CD14E451751BD42BA48AAA50B07BAD60B843D@vsvapostal3.prod.netsol.com> Message-Id: Date: Wed, 01 Aug 2001 14:04:13 -0700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: conjecture: the dominant *legitimate* use of whois today has not been mentioned. nerd logic: o spam scrapers are not counted, as they are not legitimate in my book o other uses of domain and addres whois lookup are not automated o the one big automated use is router config builds using the routing registries randy From owner-ietf-whois Wed Aug 1 14:29:38 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71LTcU19236 for ietf-whois-bks; Wed, 1 Aug 2001 14:29:38 -0700 (PDT) Received: from rcommail2 (outgoing2.jrcy.register.com [209.67.50.16]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71LTbs19232 for ; Wed, 1 Aug 2001 14:29:37 -0700 (PDT) Received: from [10.10.20.173] (helo=[169.254.254.68]) by rcommail2 with esmtp (Exim 3.16 #2) id 15S3Y3-0004aJ-00; Wed, 01 Aug 2001 17:28:59 -0400 Mime-Version: 1.0 X-Sender: jbuchanan@mail.register.com Message-Id: In-Reply-To: References: <3CD14E451751BD42BA48AAA50B07BAD60B843D@vsvapostal3.prod.netsol.com> Date: Wed, 1 Aug 2001 17:29:03 -0400 To: Randy Bush , ietf-whois@imc.org From: "Jordyn A. Buchanan" Subject: RE: IETF-51 WhoisFix BoF Announcement Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:04 PM -0700 8/1/01, Randy Bush wrote: >conjecture: the dominant *legitimate* use of whois today has not been >mentioned. > >nerd logic: > o spam scrapers are not counted, as they are not legitimate in my book > o other uses of domain and addres whois lookup are not automated > o the one big automated use is router config builds using the routing > registries In the Whois BoF at IETF 49, three major uses of Whois were identified: o Registries, registrars, etc. for domain names o RIRs for IP allocations, ASNs, etc. o RRs for routing policy data (Other people can probably categorize these more eloquently, but hopefully the idea is clear.) There are certainly other applications, but this list feels right in terms of common uses on the public Internet. It seems reasonable that the WhoisFix effort should attempt to address all three of these uses, so certainly we should be thinking about the RRs. I'll venture another legitimate use, but won't speculate about its dominance relative to router config builds: transfers of domain names between ICANN-accredited registrars. Jordyn From owner-ietf-whois Wed Aug 1 17:09:42 2001 Received: by above.proper.com (8.11.3/8.11.3) id f7209ge22459 for ietf-whois-bks; Wed, 1 Aug 2001 17:09:42 -0700 (PDT) Received: from newman.cto.netsol.com (h44.s231.netsol.com [216.168.231.44]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7209gs22455 for ; Wed, 1 Aug 2001 17:09:42 -0700 (PDT) Received: from zed.admin.cto.netsol.com (zed.admin.cto.netsol.com [216.168.231.216]) by newman.cto.netsol.com (Postfix) with ESMTP id 4498143835; Wed, 1 Aug 2001 20:09:40 -0400 (EDT) Received: (from anewton@localhost) by zed.admin.cto.netsol.com (8.9.3+Sun/8.9.1) id UAA09032; Wed, 1 Aug 2001 20:07:11 -0400 (EDT) Date: Wed, 1 Aug 2001 20:07:11 -0400 From: Andrew Newton To: "Hollenbeck, Scott" Cc: ietf-whois@imc.org Subject: !43 bar BOF Message-ID: <20010801200711.D8979@zed.admin.cto.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD60B843D@vsvapostal3.prod.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60B843D@vsvapostal3.prod.netsol.com>; from shollenbeck@verisign.com on Wed, Aug 01, 2001 at 03:52:05PM -0400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 01, 2001 at 03:52:05PM -0400, Hollenbeck, Scott wrote: > > Agreed. I didn't suggest that we should try to have both discussions in the > same room, and Randy makes a valid point in noting that we can talk about > this forever. I also agree that we should try to define a narrow scope and > move forward. To reduce the noise in the Whoisfix BOF about non-port 43 alternatives and ideas, how many people would be interested in a !43 bar BOF? -- Andrew Newton VeriSign Applied Research anewton@research.netsol.com From owner-ietf-whois Wed Aug 1 21:12:10 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f724CAN27728 for ietf-whois-bks; Wed, 1 Aug 2001 21:12:10 -0700 (PDT) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f724C8s27724 for ; Wed, 1 Aug 2001 21:12:08 -0700 (PDT) Received: from ix.netcom.com (user-33qsdn5.dialup.mindspring.com [199.174.54.229]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id AAA19995; Thu, 2 Aug 2001 00:12:06 -0400 (EDT) Message-ID: <3B68F108.B219615D@ix.netcom.com> Date: Wed, 01 Aug 2001 23:19:52 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Jaap Akkerhuis CC: ietf-provreg@cafax.se, ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement References: <200108010917.f719HJH41923@bartok.sidn.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jaap and all, Right. ANd this survey has been extended until Augest 11th Jaap Akkerhuis wrote: > > I wonder, would it make sense to consider putting together a survey of > Whois (and similar) servers and clients, to get a feel for what Whois > really means these days? It would be nice to know how it is actually > used, so we don't spend too much time scratching our heads. > > If people consider this a good idea, I can go ahead and present a brief > summary of what I think should be in such a document. > > The DNSO is already running such a survey. See > http://www.icann.org/dnso/whois-survey-en-10jun01.htm for details. > > This seems totally on-topic to me! At least, for the Whois BOF. Should > we take the ProvReg WG off of the recipient list? > > Probably, allthough I didn't yet. > > jaap -- Jeffrey A. Williams Spokesman for INEGroup - (Over 118k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1800 x1894 or 214-244-4827 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 From owner-ietf-whois Wed Aug 1 22:10:15 2001 Received: by above.proper.com (8.11.3/8.11.3) id f725AFK28773 for ietf-whois-bks; Wed, 1 Aug 2001 22:10:15 -0700 (PDT) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f725ACs28769 for ; Wed, 1 Aug 2001 22:10:12 -0700 (PDT) Received: from ix.netcom.com (user-33qsdn5.dialup.mindspring.com [199.174.54.229]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id BAA29020; Thu, 2 Aug 2001 01:10:05 -0400 (EDT) Message-ID: <3B68FEA0.59287051@ix.netcom.com> Date: Thu, 02 Aug 2001 00:17:52 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Mark Kosters CC: Jaap Akkerhuis , ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement References: <003801c11a8f$dd5b2cb0$040a000a@RRADER2K> <200108011435.f71EZeH42797@bartok.sidn.nl> <20010801143019.I3354@slam.admin.cto.netsol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark and all, Mark Kosters wrote: > On Wed, Aug 01, 2001 at 04:35:40PM +0200, Jaap Akkerhuis wrote: > > I remember that, eons ago, we used it in-house as a source to look > > up digitized pictures of colleges and in the institute next door > > they used it to find empty conference rooms. We have things as > > ldap and friends to do these. > > LDAP is something that we have been playing with for a while. An example > of an ldap service that accesses domain registration data is at: > http://www.ldap.research.netsol.com I get the following message when trying to access your URL ref.: Oops! An unexpected system error has occured. Please accept our apologies. This is only a temporary condition and will be fixed as soon as possible. If you are subscriber to a our mailing list, please feel free to notify us via e-mail. If you wish to subscribe to the list, please fill out the subscription form. We are sorry for this inconvience. > > > An internet draft that describes this is at: > http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-00.txt > > We have done some thinking on how to handle RIR data and think it may > be possible to make it work. RIR data is a bit more complex in dealing with > allocation and allocations within an allocation types of searches. > > Regards, > Mark > > -- > > Mark Kosters markk@netsol.com Verisign Applied Research Regards, -- Jeffrey A. Williams Spokesman for INEGroup - (Over 118k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1800 x1894 or 214-244-4827 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 From owner-ietf-whois Thu Aug 2 06:36:19 2001 Received: by above.proper.com (8.11.3/8.11.3) id f72DaJQ10410 for ietf-whois-bks; Thu, 2 Aug 2001 06:36:19 -0700 (PDT) Received: from newman.cto.netsol.com (h44.s231.netsol.com [216.168.231.44]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72DaIs10406 for ; Thu, 2 Aug 2001 06:36:18 -0700 (PDT) Received: from zed.admin.cto.netsol.com (zed.admin.cto.netsol.com [216.168.231.216]) by newman.cto.netsol.com (Postfix) with ESMTP id 86A0A43835; Thu, 2 Aug 2001 09:34:05 -0400 (EDT) Received: (from anewton@localhost) by zed.admin.cto.netsol.com (8.9.3+Sun/8.9.1) id JAA09665; Thu, 2 Aug 2001 09:31:35 -0400 (EDT) Date: Thu, 2 Aug 2001 09:31:35 -0400 From: Andrew Newton To: Jeff Williams Cc: Mark Kosters , ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement Message-ID: <20010802093135.D9618@zed.admin.cto.netsol.com> References: <003801c11a8f$dd5b2cb0$040a000a@RRADER2K> <200108011435.f71EZeH42797@bartok.sidn.nl> <20010801143019.I3354@slam.admin.cto.netsol.com> <3B68FEA0.59287051@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3B68FEA0.59287051@ix.netcom.com>; from jwkckid1@ix.netcom.com on Thu, Aug 02, 2001 at 12:17:52AM -0700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Aug 02, 2001 at 12:17:52AM -0700, Jeff Williams wrote: > > Mark and all, > > Mark Kosters wrote: > > > On Wed, Aug 01, 2001 at 04:35:40PM +0200, Jaap Akkerhuis wrote: > > > I remember that, eons ago, we used it in-house as a source to look > > > up digitized pictures of colleges and in the institute next door > > > they used it to find empty conference rooms. We have things as > > > ldap and friends to do these. > > > > LDAP is something that we have been playing with for a while. An example > > of an ldap service that accesses domain registration data is at: > > http://www.ldap.research.netsol.com > > I get the following message when trying to access your URL ref.: > Oops! > An unexpected system error has occured. Please accept our apologies. This is > only a temporary condition and will be fixed as soon as possible. If you are > subscriber to a our mailing list, please feel free to notify us via e-mail. If > you wish to subscribe to the list, please fill out the subscription form. > > We are sorry for this inconvience. Ah, there's nothing like a hardware failure just hours after your boss sends out the URL. It's back up. Even though our LDAP servers are in a fail-over configuration, our web server is not (if the web site demand is there, we'll make it so however). -- Andrew Newton VeriSign Applied Research anewton@research.netsol.com From owner-ietf-whois Thu Aug 2 07:15:25 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72EFPv11627 for ietf-whois-bks; Thu, 2 Aug 2001 07:15:25 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72EFNs11621 for ; Thu, 2 Aug 2001 07:15:23 -0700 (PDT) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.11.4/8.11.4) with ESMTP id f72EDLr26664 for ; Thu, 2 Aug 2001 16:13:21 +0200 Received: (from shane@localhost) by x17.ripe.net (8.10.2/8.10.2) id f72EDIW09053 for ietf-whois@imc.org; Thu, 2 Aug 2001 16:13:18 +0200 Date: Thu, 2 Aug 2001 16:13:18 +0200 From: Shane Kerr To: ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement Message-ID: <20010802161318.B8991@x17.ripe.net> References: <3CD14E451751BD42BA48AAA50B07BAD60B843D@vsvapostal3.prod.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com at 2001-08-01 14:04:13 -0700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2001-08-01 14:04:13 -0700, Randy Bush wrote: > > conjecture: the dominant *legitimate* use of whois today has not been > mentioned. > > nerd logic: > o spam scrapers are not counted, as they are not legitimate in my book > o other uses of domain and addres whois lookup are not automated > o the one big automated use is router config builds using the routing > registries I'm not sure how legitimate it is, but a *lot* of anti-spam and firewall software use the RIR Whois servers to find information about the operators of networks trafficing abusive data. We get tons of mail from badly written programs that do this, so I conjecture (and hope) that there are some well-written programs that do this. Another automated use is the misguided attempt to map IP addresses to country (or other region) of origin. This happens in every concievable way, from folks downloading the list of networks from FTP, to executing a Whois query for each HTTP request, to searching through the entire Internet by /24. While I don't think this is legitimate, some people have built entire businesses on this idea. And of course there is research into things like how efficiently various portions of the IPv4 Internet are assigned. -- Shane From owner-ietf-whois Thu Aug 2 09:19:06 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72GJ6f20194 for ietf-whois-bks; Thu, 2 Aug 2001 09:19:06 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72GJ4s20189 for ; Thu, 2 Aug 2001 09:19:04 -0700 (PDT) Received: from [193.0.1.177] (dhcp177.ripe.net [193.0.1.177]) by birch.ripe.net (8.11.4/8.11.4) with ESMTP id f72GGKr17822 for ; Thu, 2 Aug 2001 18:16:20 +0200 Mime-Version: 1.0 X-Sender: joao@birch.ripe.net Message-Id: In-Reply-To: References: <3CD14E451751BD42BA48AAA50B07BAD60B843D@vsvapostal3.prod.netsol.com> Date: Thu, 2 Aug 2001 18:16:18 +0200 To: ietf-whois@imc.org From: Joao Luis Silva Damas Subject: RE: IETF-51 WhoisFix BoF Announcement Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >In the Whois BoF at IETF 49, three major uses of Whois were identified: > > o Registries, registrars, etc. for domain names > o RIRs for IP allocations, ASNs, etc. > o RRs for routing policy data > >(Other people can probably categorize these more eloquently, but >hopefully the idea is clear.) There are certainly other >applications, but this list feels right in terms of common uses on >the public Internet. > >It seems reasonable that the WhoisFix effort should attempt to >address all three of these uses, so certainly we should be thinking >about the RRs. > >I'll venture another legitimate use, but won't speculate about its >dominance relative to router config builds: transfers of domain >names between ICANN-accredited registrars. Wouldn't this last item be dealing with how to register at the database? At least for me, whois is a query protocol. How you get the data into the database is not directly connected to whois. Some people use web forms, others provide e-mail interaction, ... The handle uniqueness issue is also not whois proper, even though databases that store nichandles today are mostly accesible via whois. However, even if some of them where to be moved to LDAP or other system, I would still like to see a common agreed format for a NIC handle such that I, or a program, would be able to tell where to look for the authoritative info for that handle. I look forward to the IETF standardising that in some way. Other wishes I have seen going around lately are: - dealing with non US-ASCII char sets (hints or clues to clients) - referrals or other kind of help for proxy writers If it turns out we can easily agree on a small set of simple extensions that fit (even if not perfectly) a big number of people then fine. Otherwise, please leave the poor thing alone. Joao -- From owner-ietf-whois Thu Aug 2 09:31:53 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72GVrr20550 for ietf-whois-bks; Thu, 2 Aug 2001 09:31:53 -0700 (PDT) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72GVps20546 for ; Thu, 2 Aug 2001 09:31:51 -0700 (PDT) Received: from rrader2k.pc.internal.tucows.com ([10.0.10.4] helo=RRADER2K) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 15SLM9-0004Ux-00 for ietf-whois@imc.org; Thu, 02 Aug 2001 12:29:53 -0400 Message-ID: <018a01c11b70$5fe980b0$040a000a@RRADER2K> Reply-To: "Ross Wm. Rader" From: "Ross Wm. Rader" To: References: <3CD14E451751BD42BA48AAA50B07BAD60B843D@vsvapostal3.prod.netsol.com> Subject: Re: IETF-51 WhoisFix BoF Announcement Date: Thu, 2 Aug 2001 12:30:00 -0400 Organization: Tucows Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Wouldn't this last item be dealing with how to register at the database? > > At least for me, whois is a query protocol. How you get the data into > the database is not directly connected to whois. Some people use web > forms, others provide e-mail interaction, ... Not really actually. While the actual transfer is a back-end registry function, gaining registrars will query the whois of the losing registrar to capture the identity elements associated with the domain name in order to ensure that the transfer is being requested by an individual or entity with the apparent authority to undertake such a request. This is very much a standard whois query but also a unique application of whois. We do thousands per day... -rwr From owner-ietf-whois Thu Aug 2 09:37:34 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72GbYa20733 for ietf-whois-bks; Thu, 2 Aug 2001 09:37:34 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72GbWs20728 for ; Thu, 2 Aug 2001 09:37:32 -0700 (PDT) Received: from [193.0.1.177] (dhcp177.ripe.net [193.0.1.177]) by birch.ripe.net (8.11.4/8.11.4) with ESMTP id f72GbDr20746; Thu, 2 Aug 2001 18:37:13 +0200 Mime-Version: 1.0 X-Sender: joao@birch.ripe.net Message-Id: In-Reply-To: <018a01c11b70$5fe980b0$040a000a@RRADER2K> References: <3CD14E451751BD42BA48AAA50B07BAD60B843D@vsvapostal3.prod.netsol.com> <018a01c11b70$5fe980b0$040a000a@RRADER2K> Date: Thu, 2 Aug 2001 18:36:57 +0200 To: "Ross Wm. Rader" , From: Joao Luis Silva Damas Subject: Re: IETF-51 WhoisFix BoF Announcement Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:30 -0400 2/8/01, Ross Wm. Rader wrote: > > Wouldn't this last item be dealing with how to register at the database? >> >> At least for me, whois is a query protocol. How you get the data into >> the database is not directly connected to whois. Some people use web >> forms, others provide e-mail interaction, ... > >Not really actually. While the actual transfer is a back-end registry >function, gaining registrars will query the whois of the losing registrar to >capture the identity elements associated with the domain name in order to >ensure that the transfer is being requested by an individual or entity with >the apparent authority to undertake such a request. This is very much a >standard whois query but also a unique application of whois. We do thousands >per day... Ok, but then you just have a multiple step process which includes a whois query as part of it. Maybe i am missing more understanding of the whole process as you use it. Joao >-rwr -- From owner-ietf-whois Thu Aug 2 09:49:39 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72GndU21194 for ietf-whois-bks; Thu, 2 Aug 2001 09:49:39 -0700 (PDT) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72Gnbs21189 for ; Thu, 2 Aug 2001 09:49:37 -0700 (PDT) Received: from rrader2k.pc.internal.tucows.com ([10.0.10.4] helo=RRADER2K) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 15SLeV-000664-00 for ietf-whois@imc.org; Thu, 02 Aug 2001 12:48:51 -0400 Message-ID: <01a801c11b73$0683e260$040a000a@RRADER2K> Reply-To: "Ross Wm. Rader" From: "Ross Wm. Rader" To: References: <3CD14E451751BD42BA48AAA50B07BAD60B843D@vsvapostal3.prod.netsol.com> <018a01c11b70$5fe980b0$040a000a@RRADER2K> Subject: Re: IETF-51 WhoisFix BoF Announcement Date: Thu, 2 Aug 2001 12:48:58 -0400 Organization: Tucows Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Ok, but then you just have a multiple step process which includes a > whois query as part of it. Maybe i am missing more understanding of > the whole process as you use it. Nope - that's precisely it. -rwr From owner-ietf-whois Thu Aug 2 11:07:12 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72I7CI23966 for ietf-whois-bks; Thu, 2 Aug 2001 11:07:12 -0700 (PDT) Received: from newman.cto.netsol.com (h44.s231.netsol.com [216.168.231.44]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72I7Cs23962 for ; Thu, 2 Aug 2001 11:07:12 -0700 (PDT) Received: from zed.admin.cto.netsol.com (zed.admin.cto.netsol.com [216.168.231.216]) by newman.cto.netsol.com (Postfix) with ESMTP id B4F3243835 for ; Thu, 2 Aug 2001 14:06:49 -0400 (EDT) Received: (from anewton@localhost) by zed.admin.cto.netsol.com (8.9.3+Sun/8.9.1) id OAA10181 for ietf-whois@imc.org; Thu, 2 Aug 2001 14:04:19 -0400 (EDT) Date: Thu, 2 Aug 2001 14:04:19 -0400 From: Andrew Newton To: ietf-whois@imc.org Subject: Re: !43 bar BOF Message-ID: <20010802140419.O9802@zed.admin.cto.netsol.com> References: <3CD14E451751BD42BA48AAA50B07BAD60B843D@vsvapostal3.prod.netsol.com> <20010801200711.D8979@zed.admin.cto.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010801200711.D8979@zed.admin.cto.netsol.com>; from anewton@research.netsol.com on Wed, Aug 01, 2001 at 08:07:11PM -0400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 01, 2001 at 08:07:11PM -0400, Andrew Newton wrote: > > To reduce the noise in the Whoisfix BOF about non-port 43 alternatives > and ideas, how many people would be interested in a !43 bar BOF? For anyone interested, we plan to assemble on Wednesday at 5:30 after the last session. Meeting place is the entrance to the terminal room and then on to a pub of concensus choice. -- Andrew Newton VeriSign Applied Research anewton@research.netsol.com From owner-ietf-whois Thu Aug 2 11:19:57 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72IJvo24357 for ietf-whois-bks; Thu, 2 Aug 2001 11:19:57 -0700 (PDT) Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72IJts24353 for ; Thu, 2 Aug 2001 11:19:56 -0700 (PDT) Received: from ix.netcom.com (user-33qsdud.dialup.mindspring.com [199.174.55.205]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id OAA04199; Thu, 2 Aug 2001 14:17:12 -0400 (EDT) Message-ID: <3B69B719.E9F86FB@ix.netcom.com> Date: Thu, 02 Aug 2001 13:24:57 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Andrew Newton CC: Mark Kosters , ietf-whois@imc.org Subject: Re: IETF-51 WhoisFix BoF Announcement References: <003801c11a8f$dd5b2cb0$040a000a@RRADER2K> <200108011435.f71EZeH42797@bartok.sidn.nl> <20010801143019.I3354@slam.admin.cto.netsol.com> <3B68FEA0.59287051@ix.netcom.com> <20010802093135.D9618@zed.admin.cto.netsol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrew and all, Ok thank you for this info. >;) Andrew Newton wrote: > On Thu, Aug 02, 2001 at 12:17:52AM -0700, Jeff Williams wrote: > > > > Mark and all, > > > > Mark Kosters wrote: > > > > > On Wed, Aug 01, 2001 at 04:35:40PM +0200, Jaap Akkerhuis wrote: > > > > I remember that, eons ago, we used it in-house as a source to look > > > > up digitized pictures of colleges and in the institute next door > > > > they used it to find empty conference rooms. We have things as > > > > ldap and friends to do these. > > > > > > LDAP is something that we have been playing with for a while. An example > > > of an ldap service that accesses domain registration data is at: > > > http://www.ldap.research.netsol.com > > > > I get the following message when trying to access your URL ref.: > > Oops! > > An unexpected system error has occured. Please accept our apologies. This is > > only a temporary condition and will be fixed as soon as possible. If you are > > subscriber to a our mailing list, please feel free to notify us via e-mail. If > > you wish to subscribe to the list, please fill out the subscription form. > > > > We are sorry for this inconvience. > > Ah, there's nothing like a hardware failure just hours after your boss > sends out the URL. > > It's back up. Even though our LDAP servers are in a fail-over configuration, > our web server is not (if the web site demand is there, we'll make it so however). > > -- > Andrew Newton > VeriSign Applied Research > anewton@research.netsol.com -- Jeffrey A. Williams Spokesman for INEGroup - (Over 118k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1800 x1894 or 214-244-4827 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 From owner-ietf-whois Thu Aug 2 11:20:18 2001 Received: by above.proper.com (8.11.3/8.11.3) id f72IKI424372 for ietf-whois-bks; Thu, 2 Aug 2001 11:20:18 -0700 (PDT) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72IKGs24368 for ; Thu, 2 Aug 2001 11:20:17 -0700 (PDT) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.4/8.11.4) with ESMTP id f72IHVH47648; Thu, 2 Aug 2001 20:17:31 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200108021817.f72IHVH47648@bartok.sidn.nl> To: Andrew Newton cc: ietf-whois@imc.org Subject: Re: !43 bar BOF In-reply-to: Your message of Thu, 02 Aug 2001 14:04:19 -0400. <20010802140419.O9802@zed.admin.cto.netsol.com> Date: Thu, 02 Aug 2001 20:17:31 +0200 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: For anyone interested, we plan to assemble on Wednesday at 5:30 after the last session. Meeting place is the entrance to the terminal room and then on to a pub of concensus choice. Can you state who is ``we''? jaap From owner-ietf-whois Thu Aug 2 13:46:55 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f72Kkti28389 for ietf-whois-bks; Thu, 2 Aug 2001 13:46:55 -0700 (PDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f72Kkrs28385 for ; Thu, 2 Aug 2001 13:46:53 -0700 (PDT) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id QAA14509; Thu, 2 Aug 2001 16:46:39 -0400 (EDT) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 16:46:44 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60B8442@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: "'Jaap Akkerhuis'" Cc: ietf-whois@imc.org Subject: RE: !43 bar BOF Date: Thu, 2 Aug 2001 16:41:19 -0400 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: > -----Original Message----- > From: Jaap Akkerhuis [mailto:jaap@sidn.nl] > Sent: Thursday, August 02, 2001 2:18 PM > To: Andrew Newton > Cc: ietf-whois@imc.org > Subject: Re: !43 bar BOF > > > > > > For anyone interested, we plan to assemble on Wednesday at 5:30 after > the last session. Meeting place is the entrance to the terminal room > and then on to a pub of concensus choice. > > > Can you state who is ``we''? Anyone who cares to show up. From owner-ietf-whois Fri Aug 3 01:42:45 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738gjx02804 for ietf-whois-bks; Fri, 3 Aug 2001 01:42:45 -0700 (PDT) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738gis02793 for ; Fri, 3 Aug 2001 01:42:44 -0700 (PDT) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.11.4/8.11.4) with ESMTP id f738g5H49850; Fri, 3 Aug 2001 10:42:06 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200108030842.f738g5H49850@bartok.sidn.nl> To: "Hollenbeck, Scott" cc: ietf-whois@imc.org Subject: Re: !43 bar BOF In-reply-to: Your message of Thu, 02 Aug 2001 16:41:19 -0400. <3CD14E451751BD42BA48AAA50B07BAD60B8442@vsvapostal3.prod.netsol.com> Date: Fri, 03 Aug 2001 10:42:05 +0200 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Can you state who is ``we''? Anyone who cares to show up. So anybody who is :-). I'm sorry I should stop make bad puns. jaap From owner-ietf-whois Sat Aug 4 06:31:46 2001 Received: by above.proper.com (8.11.3/8.11.3) id f74DVkv16058 for ietf-whois-bks; Sat, 4 Aug 2001 06:31:46 -0700 (PDT) Received: from www.io.io (www.io.io [194.205.62.108]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74DVjs16054 for ; Sat, 4 Aug 2001 06:31:45 -0700 (PDT) Received: from REACTO.com ([195.248.98.186]) by www.io.io (8.9.3/8.8.7) with ESMTP id OAA16725 for ; Sat, 4 Aug 2001 14:31:36 +0100 Message-ID: <3B6BF9BE.751432D4@REACTO.com> Date: Sat, 04 Aug 2001 14:33:50 +0100 From: "Paul M. Kane" Organization: REACTO.com X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-whois@imc.org Subject: Re: DNSO Announcement about WHOIS survey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >To: Eric Brunner-Williams in Portland Maine >CC: ietf-whois@imc.org >Subject: Re: DNSO Announcement about WHOIS survey >References: <200108011414.f71EE5N32211@nic-naa.net> >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Thanks Eric.... I can confirm we have your comments .. much appreciated. > >As Chair of the WHOIS Committee, I am confident we would welcome all comments >(even technical input) as to potential work areas for the >advancement of WHOIS. >We have focused on Domain Names, but a number of respondents have given >suggestions for a domain name "availability" protocol (and reduce >the (ab)use of >WHOIS) - such as "is a name available" Yes/No; standardised formats for Domain >and IP address results. > >At the last NC meeting a resolution was passed where the WHOIS Committee is >empowered to invite ASO and PSO members to participate in the consultation >process. > >At this stage we are on a "fact-find" to identify how WHOIS is used, >where it is >deficient and where improvements could potentially be made. We >intend to submit >our report to the ASO and PSO for their consideration once finished. >I am based in the UK and have been invited to the provreg meeting, I'm willing >to stay over to meet with you on Thursday if that would be welcomed. > >Best regards > >Paul > >Eric Brunner-Williams in Portland Maine wrote: > >> The survey solicits a response via form. I submitted my response via email. >> The person I suggest sending email responses to is Paul Kane, who can be >> reached at: paul.kane@io.io. I know my response was forwarded to him. >> >> In my response I took pains to distinguish between operational requirements >> which are met on port 43, and other requirements which need not be met on >> port 43, and may be better met by another protocol on another port. >> >> Knowing that the author of the survey is the DNSO, I did not address the >> aspects of a survey intended to inform an ASO-interested, as well as a >> DNSO-interested reader. Ross is correct in pointing out this limitation >> of the DNSO's survey. There are other limitations as well. Those known to >> me I mentioned in my response, which I'll post to this list if there is >> interest. >> >> NOTE WELL: the IETF-51 WHOISFix BOF announcement, agenda, proposed charter, >> proposed timeline and deliverables, are self-contained and will be available >> at the IETF-51 Agenda URL [1] shortly, having been sent to the secretariate >> on 07/30. >> >> Eric >> >> [1] http://www.ietf.org/meetings/wg_agenda_51.html --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-whois Sat Aug 4 08:38:32 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f74FcWW20673 for ietf-whois-bks; Sat, 4 Aug 2001 08:38:32 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74FcVs20667 for ; Sat, 4 Aug 2001 08:38:31 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.4/8.9.3) with ESMTP id f74FaqN47212; Sat, 4 Aug 2001 11:36:52 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200108041536.f74FaqN47212@nic-naa.net> To: "Paul M. Kane" cc: ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: DNSO Announcement about WHOIS survey In-Reply-To: Your message of "Sat, 04 Aug 2001 14:33:50 BST." <3B6BF9BE.751432D4@REACTO.com> Date: Sat, 04 Aug 2001 11:36:52 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ... but a number of respondents have given suggestions for a domain name "availability" [mechanism] Please see also the EPP check command. Note that unlike the whois:43 model, which provides unmediated service to 3rd parties, the epp:xx model provides unmediated service to registrars. Note that in the epp:xx model, and the current whois:43 models, queries are specific to operator namespaces, and do not span multiple operator namespaces. This is a design limitation in the case of epp:xx, consequent to its being a client-server model. This limitation is not necessarily present in xrp:xx, which is not intentionally constrained to an client-server event model. >At the last NC meeting a resolution was passed where the WHOIS Committee is >empowered to invite ASO and PSO members to participate in the consultation >process. This is not yet reflected in the survey. >I am based in the UK and have been invited to the provreg meeting, I'm willing >to stay over to meet with you on Thursday if that would be welcomed. You need only register with the Secretariate, or make some arraingements with them. I suggest you talk to Steve Coya. Eric From owner-ietf-whois Sat Aug 4 10:28:57 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f74HSv324536 for ietf-whois-bks; Sat, 4 Aug 2001 10:28:57 -0700 (PDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74HSts24526 for ; Sat, 4 Aug 2001 10:28:55 -0700 (PDT) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA18552 for ; Sat, 4 Aug 2001 13:28:52 -0400 (EDT) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Sat, 4 Aug 2001 13:28:54 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60B844A@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: ietf-whois@imc.org Subject: RE: DNSO Announcement about WHOIS survey Date: Sat, 4 Aug 2001 13:23:27 -0400 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: > -----Original Message----- > From: Eric Brunner-Williams in Portland Maine > [mailto:brunner@nic-naa.net] > Sent: Saturday, August 04, 2001 11:37 AM > To: Paul M. Kane > Cc: ietf-whois@imc.org; brunner@nic-naa.net > Subject: Re: DNSO Announcement about WHOIS survey > > > > ... but a number of respondents have given suggestions for a > domain name "availability" [mechanism] > > Please see also the EPP check command. Note that unlike the whois:43 model, > which provides unmediated service to 3rd parties, the epp:xx model provides > unmediated service to registrars. > > > Note that in the epp:xx model, and the current whois:43 models, queries are > specific to operator namespaces, and do not span multiple operator namespaces. > This is a design limitation in the case of epp:xx, consequent to its being a > client-server model. This limitation is not necessarily present in xrp:xx, > which is not intentionally constrained to an client-server event model. > A client-server operational model does _not_ constrain queries to any particular operator namespace. If you really think it does, please explain how the client-server DNS or rwhois protocols fail to span operator namespaces. From owner-ietf-whois Sat Aug 4 10:46:32 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f74HkW824699 for ietf-whois-bks; Sat, 4 Aug 2001 10:46:32 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74HkVs24695 for ; Sat, 4 Aug 2001 10:46:31 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.4/8.9.3) with ESMTP id f74Hj6N47557; Sat, 4 Aug 2001 13:45:06 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200108041745.f74Hj6N47557@nic-naa.net> To: "Hollenbeck, Scott" cc: ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: DNSO Announcement about WHOIS survey In-Reply-To: Your message of "Sat, 04 Aug 2001 13:23:27 EDT." <3CD14E451751BD42BA48AAA50B07BAD60B844A@vsvapostal3.prod.netsol.com> Date: Sat, 04 Aug 2001 13:45:06 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Perhaps I mispoke Scott, so feel free to explain how registries using epp can initiate instances of communication with any party. Having done that, with other registries using epp. That done, effecting a server-to-server query using epp should be quite trivial. From owner-ietf-whois Sat Aug 4 12:51:11 2001 Received: by above.proper.com (8.11.3/8.11.3) id f74JpBk25956 for ietf-whois-bks; Sat, 4 Aug 2001 12:51:11 -0700 (PDT) Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74Jp9s25952 for ; Sat, 4 Aug 2001 12:51:09 -0700 (PDT) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA19091 for ; Sat, 4 Aug 2001 15:51:06 -0400 (EDT) Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id ; Sat, 4 Aug 2001 15:51:08 -0400 Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60B844B@vsvapostal3.prod.netsol.com> From: "Hollenbeck, Scott" To: ietf-whois@imc.org Subject: RE: DNSO Announcement about WHOIS survey Date: Sat, 4 Aug 2001 15:45:35 -0400 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: > -----Original Message----- > From: Eric Brunner-Williams in Portland Maine > [mailto:brunner@nic-naa.net] > Sent: Saturday, August 04, 2001 1:45 PM > To: Hollenbeck, Scott > Cc: ietf-whois@imc.org; brunner@nic-naa.net > Subject: Re: DNSO Announcement about WHOIS survey > > > Perhaps I mispoke Scott, so feel free to explain how registries using epp > can initiate instances of communication with any party. Having done that, > with other registries using epp. That done, effecting a server-to-server > query using epp should be quite trivial. That's an interesting leap from a general claim of client-server ineptitude WRT name space query constraints (countered with two specific examples that happen to manage quite nicely) to suggesting a debate based on an assumption that a provisioning protocol is supposed to be able to "initiate instances of communication with any party". I'll save the debate for the provreg mailing list and WG session. From owner-ietf-whois Sat Aug 4 13:53:45 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f74Krjf26416 for ietf-whois-bks; Sat, 4 Aug 2001 13:53:45 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f74Kris26412 for ; Sat, 4 Aug 2001 13:53:44 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.4/8.9.3) with ESMTP id f74KqEN47998; Sat, 4 Aug 2001 16:52:14 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200108042052.f74KqEN47998@nic-naa.net> To: "Hollenbeck, Scott" cc: ietf-whois@imc.org, brunner@nic-naa.net Subject: Re: DNSO Announcement about WHOIS survey In-Reply-To: Your message of "Sat, 04 Aug 2001 15:45:35 EDT." <3CD14E451751BD42BA48AAA50B07BAD60B844B@vsvapostal3.prod.netsol.com> Date: Sat, 04 Aug 2001 16:52:14 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It was the point I was addressing. We've talked about peer-to-peer vs client-server in the preregproto list, in the specific context of "push" vs "poll". Making a registry to registry check-like operation is possible with xrp, as the server may initiate instances of communication, "push" being the only one specified in the "merits of poll only" context. From owner-ietf-whois Thu Aug 9 02:13:59 2001 Received: by above.proper.com (8.11.3/8.11.3) id f799DxC28766 for ietf-whois-bks; Thu, 9 Aug 2001 02:13:59 -0700 (PDT) Received: from newman.cto.netsol.com (h44.s231.netsol.com [216.168.231.44]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f799DwN28762 for ; Thu, 9 Aug 2001 02:13:58 -0700 (PDT) Received: from zed.admin.cto.netsol.com (zed.admin.cto.netsol.com [216.168.231.216]) by newman.cto.netsol.com (Postfix) with ESMTP id AD8E943835 for ; Thu, 9 Aug 2001 05:13:52 -0400 (EDT) Received: (from anewton@localhost) by zed.admin.cto.netsol.com (8.9.3+Sun/8.9.1) id FAA14235 for ietf-whois@imc.org; Thu, 9 Aug 2001 05:11:09 -0400 (EDT) Date: Thu, 9 Aug 2001 05:11:09 -0400 From: Andrew Newton To: ietf-whois@imc.org Subject: not 43 mailing list Message-ID: <20010809051109.H14124@zed.admin.cto.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Based on the discussions from last night's !43 "bar" BOF (I use "bar" loosely), an email list has been setup for discussions on proposals and protocols that relate to use cases of whois but that are not whois. The list is ietf-not43@lists.research.netsol.com To subscribe: http://lists.research.netsol.com/mailman/listinfo/ietf-not43 Our rough consensus was to first talk about requirements of such a protocol, be it a new one or the adoption of existing technology, before determining the types of technology to use. -andy -- Andrew Newton VeriSign Applied Research anewton@research.netsol.com From owner-ietf-whois Thu Aug 9 05:13:01 2001 Received: by above.proper.com (8.11.3/8.11.3) id f79CD1v13290 for ietf-whois-bks; Thu, 9 Aug 2001 05:13:01 -0700 (PDT) Received: from newman.cto.netsol.com (h44.s231.netsol.com [216.168.231.44]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79CD0N13286 for ; Thu, 9 Aug 2001 05:13:00 -0700 (PDT) Received: from zed.admin.cto.netsol.com (zed.admin.cto.netsol.com [216.168.231.216]) by newman.cto.netsol.com (Postfix) with ESMTP id 249E043835 for ; Thu, 9 Aug 2001 08:12:56 -0400 (EDT) Received: (from anewton@localhost) by zed.admin.cto.netsol.com (8.9.3+Sun/8.9.1) id IAA14378 for ietf-whois@imc.org; Thu, 9 Aug 2001 08:10:15 -0400 (EDT) Date: Thu, 9 Aug 2001 08:10:15 -0400 From: Andrew Newton To: ietf-whois@imc.org Subject: Re: not 43 mailing list Message-ID: <20010809081015.C14355@zed.admin.cto.netsol.com> References: <20010809051109.H14124@zed.admin.cto.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010809051109.H14124@zed.admin.cto.netsol.com>; from anewton@research.netsol.com on Thu, Aug 09, 2001 at 05:11:09AM -0400 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Several people have informed me that the confirmation e-mail for this list is ending up in a mail loop. Until I get the problem resolved, just e-mail me if you want added to the list and I will do it manually. The actual list itself is working. -andy -- Andrew Newton VeriSign Applied Research anewton@research.netsol.com From owner-ietf-whois Mon Aug 13 15:14:22 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DMEMM09723 for ietf-whois-bks; Mon, 13 Aug 2001 15:14:22 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DMEMN09719 for ; Mon, 13 Aug 2001 15:14:22 -0700 (PDT) Received: from bbthead.brandenburg.com (ndu-3-113.inweb.net.uk [213.210.23.113]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA18090 for ; Mon, 13 Aug 2001 15:14:17 -0700 Message-Id: <5.1.0.14.2.20010813182713.02906860@brandenburg.com> X-Sender: dcrocker@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 X-Priority: 2 (High) Date: Mon, 13 Aug 2001 18:34:06 +0100 To: ietf-whois@imc.org From: Dave Crocker Subject: Whoisfix BOF 51st IETF / Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, Here are the excellent notes that Ted took, unchanged. The polling cited at the end of the notes includes the list of possible task items suggested by attendees. If there are no objections to these notes by this Friday, I'll post them to the IETF secretariat. d/ Whoisfix BOF 51st IETF Chaired by Eric Brunner-Williams and Dave Crocker August 9, 2001 Reported by Ted Hardie Actions taken: Mailing list for further work set as ietf-whois@imc.org Agreed that charter needed revision. A set of initial candidate problems established and ranked Agreement reached that if those problems could not be solved on port 43 while maintaining backward compatibility, the group would cease as a whois group, potentially reusing the work to create a new protocol Meeting Review: The meeting began with agenda bashing; there were no changes to the published agenda as a result of the discussion Dave started general discussion by noting that the scope of the effort is to "fix" whois, not ehance or extend it to be a replacement for LDAP or other mechanisms. The key requirements that chairs see lie in satisfying the needs of Regional registries, Domain name registries (ccTLD and gTLD), and network operators. Out of scope are trademark issues, law enforcement, and similar political fodder. The charter given by the chairs when requesting the BOF further limits the scope to enabling technical changes to whois queries and does not and will not discuss policy related to keeping certain records or populating the data used to respond to whois queries. The basic goals identified by the chairs are: 1) Standardize structured query format 2) Produce mechanisms to allow for query redirection and server-server queries 3)Maintain interoperability among old clients, old servers, new clients and new servers Initial timetable: Sep 01: Initial spec Revisions Jan 2002 Spring: Done With that background Marjann presented how they use whois and noted that APNIC uses a version of the RIPE NCC code for similar purposes, to whit: track IP and ASN allocation, maintain contact info, and maintain both reverse and forward domain name data. Data are populated both by the RIPE NCC and the domain holders. In addition, RIPE uses whois as part of its routing registry (RIPEDB), which registers some forms of routing info; this is based on RPSL a syntactically rich form which allows users to produce router configurations and which contains route object maintainer contact information. The query language is structured (RPSL for the routing registry, attribute/value pairs for the IP data), but this is transparent to the user; the data are kept in databases and whois is an access method rather than a data description language. The RIPE NCC server can act like a client, but the interaction is pure referral and provides no state for the interaction. The domain data maintained by RIPE was initially on reverse domains for in-addr.arpa, but it can and has been used for forward data on behalf of cctlds. More and more ccTLDs are moving out of the RIPE database; now only the top level domains are in RIPE, but referrals can be made to whois servers maintained by the individual ccTLDs. Cathy Murphy then presented the ARIN whois use, which is similar to that of RIPE. Notes that the principal issue facing them is scaling; the service runs at the saturation point of the servers involved. Ran at 20 million a month at the beginning of 2000, moved up to 35 million by the end of the year, and then jumped when new servers were added. Before the addition the query rate 14.54 queries/sec; post-addition it ran up to July 20q/sec. Cathy also noted that her users have requested referral whois. Users want referral whois. Randy Bush then discussed use, noting that many ccTLDs run RIPE; and that ISPs commonly use the RADB and IRR. There is a large community using a traditional "dumb" port 43 (i.e. no RPSL structure) for contact data. He is aware of four software families: RIPE, ARIN (Forked from NSI), NSI, and RADB. Andy Linton noted some ccTLDs (e.g. New Zealand) have rolled their own. Jaap then gave a brief report on the whois service for the Dutch ccTLD, noting that it limited each host to 500 queries a day queries . It is often used simply to test whether a name exists, so they have developed a light-weight response which notes only the state: exists, doesn't exist, is blocked. George Michaelson noted that the APNIC has a confederation structure, which is reflected in the whois data; different members use different formats, which may be in country-specific character sets. Nakayama-san noted as part of this that the Japanese data is in shift-JIS, with a note on how to obtain English versions. As with other whois services, a clear concern in the APNIC reason is "grazing", the use of whois to obtain data on members, but a distinction is clear to the APNIC members that some forms (e.g. Geoff Houston's data association grazing) are valid. Randy then gave a presentation of NIC handle info in the whois data at ARIN and RIPE, which notes that different registries have different identities attached to the same identifier, despite a hack that tries to use REGISTRY-handle method for associating data to the original handle. This is partly because of RIPE's method of doing referential integrity (dumping the other database into their own). Eric then noted that discussions within PROVREG have produced a document, draft-rader-dnwhois-defn-00.txt, which may be useful but likely will need to be split into a provreg area and a whois area. Dave presented issues/desiderata for queries: a standardized query format, possibly expressed as a regularized query "template", so that independent of the content a common query format can be used; constrained XML mentioned as a format (later rejected; see below). Dave then went through the related issues for responses: a structured output with standard labels, registered response codes, and the ability to redirect or refer. Randy questioned the need for redirect/referral as a method of raising the question of how to develop the requirements; Patrik followed up by pointing out the transition issues and noting that we need strong indications of why individual fixes are needed so we can do the cost/benefit analysis of which changes and fixes get applied. The first justification put forward was for structured output, as an aid to parsing; John Klensin replied that the current limits of the protocol are such that expecting to be able to process output from a whois query raises risks, and that it might be better to use a new port. After discussion among John, Randy, and the room, it was agreed that it would be safe if the queries were not posed to arbitrary whois servers, but to an enumerated set which adhered to a published standard (such as the RFC2622 RPSL syntax). This is one way around the transition issue as well. Mark Kosters noted that this is a well known slope, and that the next thing will be a request for client capabilities; further steps and ultimate destination are also well known. John and Randy agreed that a strict management of further feature creep is necessary, as is the avoidance of generics in the enumerated list (as in, all ccTLD whois servers). Authentication and a well known format round out this update; Greg Block notes that once you have rounded it out it sounds a lot less like whois. Mark Kosters further added that the original whois' function was as a public service with general availability. The service this restricted set describes is not parallel, as it creates closed islands. Randy disagreed, asserting that well-specified formats and enumerated serves gave a pretty broad scope, though any to any functionality is lost; consider a grocery format with an enumerated list of grocery servers-it can be used by anyone with the ability to parse the grocery format and access to the named servers as one example. Dave then proposed a process approach to the rest of the BOF: Part one: what problem do you want fixed? Part two: what minimal approach would solve part one? Part three: rank these problems Part four: partition the ranking statements and list the ones that we think we can do on port 43. If there are requirements that we cannot do on port 43, we go to another port for all of the work this group may do. Patrik noted that he does not like "or" or "if" in charters. Dave agrees that this is appropriate and that if cannot happen on port 43, the group will report that it cannot complete and a new group *might* be chartered for a different port, but this group would shut down. The group discussed this approach; there was discussion among Jordan, Bruce, Neil and others on whether we are "updating whois" or meeting the need for a protocol that solves a specific set of problems; while it was agreed that backwards compatibility does constrain possible solutions consensus seemed to be that if it is not restricted to port 43, there will be no progress. Dave then stated his belief that we had ripped the current charter apart, and that it will need revision, but he hopes that we try to stay in this kind of time frame to encourage progress. Some challenge on the practicality of this approach by Randy, but this would be cleaned up before resubmission to area directors. Eric and Dave then reviewed other working groups salient to this work: provreg, idn, *ng, security? Bill Manning noted that there are also people still revising and enhancing rwhois protocols and that it would be useful to coordinate with them. Patrik rose to make the point that whois might not be the right tool for retrieving data and performing data calculation; he believe that because those clients try to machine parsing they have risks. He suggests that those reports would be better produced by the people who have the data, rather than via whois. Eric agreed that good stewardship is an alternate to good grazing, but it outside the scope of a working group to do more than encourage good stewardship A discussion of candidates for the problem list was then held, with the following results: Andy Newton: Privacy and access control. This was seen as mainly the work of the applications suing whois, but agreed that error codes for things like "Use exceeded" might be useful Randy Bush: nic handle identity Moderate interest by the group, with the synchronization element seen as probably out of scope. Jordon: need for referrals. Strong interest by the group. Bruce: standardized format for specified query Agreement by the group George: backwards and forwards compatibility Agreed to survey existing implementations; attempt not to create incompatibilities. Werner: whois query in URL format. Some exist, and this is a current APPs area requirement Max: don't make it comment or use XML, as it won't be human readable Agreed with some objections. Andy Newton: should be transcribable query format. Agreed Hans: Coordination with ICANN policy requirements proposed and then withdrawn. ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-ietf-whois Tue Aug 14 00:50:06 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7E7o6D18907 for ietf-whois-bks; Tue, 14 Aug 2001 00:50:06 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E7o5N18894 for ; Tue, 14 Aug 2001 00:50:05 -0700 (PDT) Received: from x47.ripe.net (x47.ripe.net [193.0.1.47]) by birch.ripe.net (8.11.4/8.11.4) with ESMTP id f7E7nxH24367; Tue, 14 Aug 2001 09:49:59 +0200 Received: from localhost (engin@localhost) by x47.ripe.net (8.10.2/8.10.2) with ESMTP id f7E7nwL13230; Tue, 14 Aug 2001 09:49:58 +0200 X-Authentication-Warning: x47.ripe.net: engin owned process doing -bs Date: Tue, 14 Aug 2001 09:49:58 +0200 (CEST) From: Engin Gunduz To: Dave Crocker cc: Subject: Re: Whoisfix BOF 51st IETF / Minutes In-Reply-To: <5.1.0.14.2.20010813182713.02906860@brandenburg.com> 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: Hi, On Mon, 13 Aug 2001, Dave Crocker wrote: > > Folks, > > Here are the excellent notes that Ted took, unchanged. The polling cited > at the end of the notes includes the list of possible task items suggested > by attendees. > > If there are no objections to these notes by this Friday, I'll post them to > the IETF secretariat. > > d/ > [....] > With that background Marjann presented how they use whois and noted that ^^^^^^^ Mirjam Kuehne > APNIC uses a version of the RIPE NCC code for similar purposes, to whit: > track IP and ASN allocation, maintain contact info, and maintain both > reverse and forward domain name data. Data are populated both by the RIPE > NCC and the domain holders. In addition, RIPE uses whois as part of its [....] > > Randy then gave a presentation of NIC handle info in the whois data at ARIN > and RIPE, which notes that different registries have different identities > attached to the same identifier, despite a hack that tries to use > REGISTRY-handle method for associating data to the original handle. This > is partly because of RIPE's method of doing referential integrity (dumping > the other database into their own). This is not the case: the other DBs are not dumped into our own. We just allow users to create person objects with non-RIPE NIC handles. Thanks for the minutes, -engin Engin Gunduz RIPE NCC Database Group From owner-ietf-whois Tue Aug 14 02:16:23 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7E9GNq26946 for ietf-whois-bks; Tue, 14 Aug 2001 02:16:23 -0700 (PDT) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E9GLN26942 for ; Tue, 14 Aug 2001 02:16:21 -0700 (PDT) Received: from ix.netcom.com (user-33qsdch.dialup.mindspring.com [199.174.53.145]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id FAA10706; Tue, 14 Aug 2001 05:16:16 -0400 (EDT) Message-ID: <3B790A3C.A7B506F2@ix.netcom.com> Date: Tue, 14 Aug 2001 04:23:40 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Engin Gunduz CC: Dave Crocker , ietf-whois@imc.org Subject: Re: Whoisfix BOF 51st IETF / Minutes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Engin and all, Not to worry, Dave often makes these types of mistakes. Engin Gunduz wrote: > Hi, > > On Mon, 13 Aug 2001, Dave Crocker wrote: > > > > Folks, > > > > Here are the excellent notes that Ted took, unchanged. The polling cited > > at the end of the notes includes the list of possible task items suggested > > by attendees. > > > > If there are no objections to these notes by this Friday, I'll post them to > > the IETF secretariat. > > > > d/ > > > [....] > > With that background Marjann presented how they use whois and noted that > ^^^^^^^ > Mirjam Kuehne > > > APNIC uses a version of the RIPE NCC code for similar purposes, to whit: > > track IP and ASN allocation, maintain contact info, and maintain both > > reverse and forward domain name data. Data are populated both by the RIPE > > NCC and the domain holders. In addition, RIPE uses whois as part of its > [....] > > > > Randy then gave a presentation of NIC handle info in the whois data at ARIN > > and RIPE, which notes that different registries have different identities > > attached to the same identifier, despite a hack that tries to use > > REGISTRY-handle method for associating data to the original handle. This > > is partly because of RIPE's method of doing referential integrity (dumping > > the other database into their own). > > This is not the case: the other DBs are not dumped into our own. We just > allow users to create person objects with non-RIPE NIC handles. > > Thanks for the minutes, > -engin > > Engin Gunduz > RIPE NCC Database Group Regards, -- Jeffrey A. Williams Spokesman for INEGroup - (Over 118k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1800 x1894 or 214-244-4827 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 From owner-ietf-whois Tue Aug 14 02:34:45 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7E9Yjc29469 for ietf-whois-bks; Tue, 14 Aug 2001 02:34:45 -0700 (PDT) Received: from isvw-mail.nc.u-tokyo.ac.jp (vwsm.nc.u-tokyo.ac.jp [133.11.127.86]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E9YhN29460 for ; Tue, 14 Aug 2001 02:34:44 -0700 (PDT) X-Filtered-By: InterScan Virus Wall(isvw-mail.nc.u-tokyo.ac.jp) at UT NOC Received: from localhost (localhost [127.0.0.1]) by nashi.nc.u-tokyo.ac.jp (8.11.3/8.10.2) with ESMTP id f7E9YfH02579; Tue, 14 Aug 2001 18:34:41 +0900 (JST) To: dcrocker@brandenburg.com Cc: ietf-whois@imc.org Subject: Re: Whoisfix BOF 51st IETF / Minutes From: nakayama@nc.u-tokyo.ac.jp In-Reply-To: <5.1.0.14.2.20010813182713.02906860@brandenburg.com> References: <5.1.0.14.2.20010813182713.02906860@brandenburg.com> X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010814183441G.nakayama@nashi.nc.u-tokyo.ac.jp> Date: Tue, 14 Aug 2001 18:34:41 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 89 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Nakayama-san noted as part of this that the Japanese data is in shift-JIS, > with a note on how to obtain English versions. ^^^^^^^^^ JIS The following lists are brief summary of answers when I asked to ccTLD administrative contacts at 1997 for RIDE BoF. ccTLD : whois server port Responce Format and other info. --------------------------------------------------------------------------- .fr : whois.nic.fr 43 RIPE Format, 7bits .is : whois.isnet.is 43 Original Format, .jp : whois.nic.ad.jp 43 Original Format, 7bits .kr : whois.nic.or.kr 43 RIPE Format, 8bits .mx : whois.nic.mx 43 Original Format, 7bits .ru : whois.ripn.net 43 RIPE Format, 7bits .se : whois.nic-se.se 43 RIPE Format, (Changed?) .th : whois.thnic.net 43 RIPE Format, 7bits .za : whois.za 43 Original Format, 7bits .ch : whois.nic.ch 43 Original Format, 8bits .li : whois.nic.li 43 Original Format, 8bits .gf : whois.nplus.gf 43 (This server is not available now) .hk : whois.hknic.net.hk 43 (This server is not listed in DNS now) .us : nii.isi.edu 43 (This server is not available now) .pe : rwhois.rcp.net.pe 4321 InterNIC Format .ve : rwhois.reacciun.ve 4321 InterNIC format .am : whois.amnic.net 43 Original Format, Not Available yet. .pk : unclear Not Available yet. .pt : unclear Not Available yet. .at : unclear .gb : unclear .lc : unclear .tr : unclear .ad : NO .al : NO .aq : NO .bb : NO .be : NO .ci : NO .cr : NO .dk : NO .eg : NO .er : NO .gh : NO .gp : NO .gr : NO .gt : NO .gu : NO .hr : NO .hu : NO .ie : NO .il : NO .jm : NO .kh : NO .kz : NO .lb : NO .lk : NO .lt : NO .lv : NO .mc : NO .mg : NO .mh : NO .mk : NO .mp : NO .mu : NO .mw : NO .my : NO .na : NO .ng : NO .no : NO .pa : NO .pg : NO .ph : NO .pl : NO .sg : NO .sk : NO .sv : NO .sz : NO .to : NO .ug : NO .vu : NO .ye : NO .yu : NO --------------------------------------------------------------------------- From owner-ietf-whois Tue Aug 14 05:38:03 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7ECc3w09260 for ietf-whois-bks; Tue, 14 Aug 2001 05:38:03 -0700 (PDT) Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7ECc1N09255 for ; Tue, 14 Aug 2001 05:38:02 -0700 (PDT) Received: from dmanley.pc.internal.tucows.com ([10.0.10.19] helo=tucows.com) by toronto.mail.tucows.com with esmtp (Exim 3.20 #2) id 15WdRy-0001M6-00 for ietf-whois@imc.org; Tue, 14 Aug 2001 08:37:38 -0400 Message-ID: <3B791CB1.3080402@tucows.com> Date: Tue, 14 Aug 2001 08:42:25 -0400 From: Daniel Manley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 X-Accept-Language: en, fr MIME-Version: 1.0 To: ietf-whois@imc.org Subject: Re: Whoisfix BOF 51st IETF / Minutes References: <5.1.0.14.2.20010813182713.02906860@brandenburg.com> <20010814183441G.nakayama@nashi.nc.u-tokyo.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: .ca is available at whois.cira.ca:43 -- I'm not familiar with the RIPE/original formats, but I believe that the text is in 8bits because of the inclusion of French characters. Dan nakayama@nc.u-tokyo.ac.jp wrote: >>Nakayama-san noted as part of this that the Japanese data is in shift-JIS, >>with a note on how to obtain English versions. ^^^^^^^^^ >> > JIS > >The following lists are brief summary of answers when I asked to >ccTLD administrative contacts at 1997 for RIDE BoF. > > >ccTLD : whois server port Responce Format and other info. >--------------------------------------------------------------------------- > .fr : whois.nic.fr 43 RIPE Format, 7bits > .is : whois.isnet.is 43 Original Format, > .jp : whois.nic.ad.jp 43 Original Format, 7bits > .kr : whois.nic.or.kr 43 RIPE Format, 8bits > .mx : whois.nic.mx 43 Original Format, 7bits > .ru : whois.ripn.net 43 RIPE Format, 7bits > .se : whois.nic-se.se 43 RIPE Format, (Changed?) > .th : whois.thnic.net 43 RIPE Format, 7bits > .za : whois.za 43 Original Format, 7bits > .ch : whois.nic.ch 43 Original Format, 8bits > .li : whois.nic.li 43 Original Format, 8bits > > .gf : whois.nplus.gf 43 (This server is not available now) > .hk : whois.hknic.net.hk 43 (This server is not listed in DNS now) > .us : nii.isi.edu 43 (This server is not available now) > > .pe : rwhois.rcp.net.pe 4321 InterNIC Format > .ve : rwhois.reacciun.ve 4321 InterNIC format > > .am : whois.amnic.net 43 Original Format, Not Available yet. > .pk : unclear Not Available yet. > .pt : unclear Not Available yet. > > .at : unclear > .gb : unclear > .lc : unclear > .tr : unclear > > .ad : NO > .al : NO > .aq : NO > .bb : NO > .be : NO > .ci : NO > .cr : NO > .dk : NO > .eg : NO > .er : NO > .gh : NO > .gp : NO > .gr : NO > .gt : NO > .gu : NO > .hr : NO > .hu : NO > .ie : NO > .il : NO > .jm : NO > .kh : NO > .kz : NO > .lb : NO > .lk : NO > .lt : NO > .lv : NO > .mc : NO > .mg : NO > .mh : NO > .mk : NO > .mp : NO > .mu : NO > .mw : NO > .my : NO > .na : NO > .ng : NO > .no : NO > .pa : NO > .pg : NO > .ph : NO > .pl : NO > .sg : NO > .sk : NO > .sv : NO > .sz : NO > .to : NO > .ug : NO > .vu : NO > .ye : NO > .yu : NO >--------------------------------------------------------------------------- > From owner-ietf-whois Tue Aug 14 08:08:11 2001 Received: by above.proper.com (8.11.3/8.11.3) id f7EF8BL14529 for ietf-whois-bks; Tue, 14 Aug 2001 08:08:11 -0700 (PDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EF89N14522 for ; Tue, 14 Aug 2001 08:08:09 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Wfna-000In0-00 for ietf-whois@imc.org; Tue, 14 Aug 2001 08:08:06 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-whois@imc.org Subject: Re: Whoisfix BOF 51st IETF / Minutes References: <5.1.0.14.2.20010813182713.02906860@brandenburg.com> <20010814183441G.nakayama@nashi.nc.u-tokyo.ac.jp> <3B791CB1.3080402@tucows.com> Message-Id: Date: Tue, 14 Aug 2001 08:08:06 -0700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: NG is at whois.rg.net using irrd randy From owner-ietf-whois Tue Aug 14 08:54:14 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7EFsE218992 for ietf-whois-bks; Tue, 14 Aug 2001 08:54:14 -0700 (PDT) Received: from nix.net.ua (IDENT:sveta@nix.net.ua [62.149.2.12]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EFsBN18983 for ; Tue, 14 Aug 2001 08:54:12 -0700 (PDT) Received: (from sveta@localhost) by nix.net.ua id f7EFrlb20372; Tue, 14 Aug 2001 18:53:47 +0300 (EEST) (envelope-from sveta) Date: Tue, 14 Aug 2001 18:53:47 +0300 From: Svetlana Tkachenko To: nakayama@nc.u-tokyo.ac.jp Cc: ietf-whois@imc.org Subject: Re: Whoisfix BOF 51st IETF / Minutes Message-ID: <20010814185347.B31960@net.ua> References: <5.1.0.14.2.20010813182713.02906860@brandenburg.com> <20010814183441G.nakayama@nashi.nc.u-tokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010814183441G.nakayama@nashi.nc.u-tokyo.ac.jp>; from nakayama@nc.u-tokyo.ac.jp on Tue, Aug 14, 2001 at 06:34:41PM +0900 X-Chocolate-To: sveta@net.ua Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > ccTLD : whois server port Responce Format and other info. > --------------------------------------------------------------------------- .ua whois.com.ua 43 RIPE format, 8 bits From owner-ietf-whois Wed Aug 15 02:43:49 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7F9hns09238 for ietf-whois-bks; Wed, 15 Aug 2001 02:43:49 -0700 (PDT) Received: from lenny.harvard.edu (lenny.harvard.edu [128.103.60.67]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F9hmN09232 for ; Wed, 15 Aug 2001 02:43:48 -0700 (PDT) Received: from camailp.harvard.edu (camailp.harvard.edu [128.103.26.26]) by lenny.harvard.edu (Postfix) with ESMTP id 9B1746DF for ; Wed, 15 Aug 2001 05:43:38 -0400 (EDT) Received: from [146.227.118.86] by camailp.harvard.edu (Post.Office MTA v3.5.3 release 223 ID# 0-62422U7000L700S0V35) with ESMTP id edu for ; Wed, 15 Aug 2001 05:43:38 -0400 Mime-Version: 1.0 X-Sender: jcamp@camail1.harvard.edu Message-Id: Date: Wed, 15 Aug 2001 11:43:39 +0100 To: ietf-whois@imc.org From: Jean Camp Subject: clarification Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: My Understanding of the Goals of WhoIs from the meeting I attended until my battery ran out. The design function of the WhoIs database is to provide network contact information for technical admin purposes. The WhoIs database is failing in its critical functions. This working group proposes to implement an updated WhoIs in order to solve the following problems: Referrals Query controls/number of queries Data accuracy Standardized query and query responses. The proposal is for an extension of WhoIs with a tight focus on the core requirements. This may result in a decrease in the availability of WhoIs technical contacts to users at large. The concern of this working group is only the technical information, distinct from any information which may be desirable for any other social or economic purposes. The following must be true of the final protocol: - it must allow graceful evolution so that upgrades need not be simultaneous - it must provide information to those who provide network services, including network administrators and incident response teams - it must increase data accuracy - it may implement authentication - backwards compatibility The design of such a system must clearly define the protocols and data formats for a WhoIs database which will provide reliable authenticated technical contact information for users authenticated to have a technical need to know. -- From owner-ietf-whois Sat Aug 18 16:37:08 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7INb8F04195 for ietf-whois-bks; Sat, 18 Aug 2001 16:37:08 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7INb5N04191 for ; Sat, 18 Aug 2001 16:37:06 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.5/8.9.3) with ESMTP id f7INYGF07189; Sat, 18 Aug 2001 19:34:16 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200108182334.f7INYGF07189@nic-naa.net> To: minutes@ietf.org cc: ietf-whois@imc.org Subject: Minutes: Whoisfix BOF Date: Sat, 18 Aug 2001 19:34:16 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: IETF Secretariate, Please find attached the minutes from the WhoisFix BOF meeting in London last week. Eric ------- Forwarded Message Many thanks to Ted Hardie for scribing! (Reported by Ted Hardie, to be formal) Congratulations/thanks to the meeting's participants! I think we covered a lot of ground smoothly & pragmatically, and I attribute that wholly to the very constructive vibe in the air and peoples' concerted efforts to get things done. Just a reminder, Andrew followed up on his Bar Bof of the 8th with a list for "!43" discussion. That list is ietf-not43@lists.research.netsol.com. ============================================================ WHOISfix BOF IETF-51 August 9, 2001 ============================================================ Chairs: Eric Brunner-Williams (EBW) and Dave Crocker (CD) Minutes: Ted Hardie Meeting plan: o requirements overview o charter discussion o RIR state-of-whois overview o TLD state-of-whois overview o design discussion: queries and formats o transitions o interactions with other work groups -- o it isn't whois:43, trademark, law enforcement, LDAP Summary of Actions taken: - ------------------------- Mailing list for further work set as ietf-whois@imc.org Agreed that charter needed revision. A set of initial candidate problems established and ranked. Agreement reached that if those problems could not be solved on port 43 while maintaining backward compatibility, the group would cease as a whois group, potentially reusing the work to create a new protocol. Meeting Review: - --------------- DC started general discussion by noting that the scope of the effort is to "fix" whois, not enhance or extend it to be a replacement for LDAP or other mechanisms. The key requirements that chairs see lie in satisfying the needs of address registries, domain name registries (ccTLD and gTLD), and network operators. The proposed charter limits the scope to enabling technical changes to queries, responses, and redirection mechanisms. Out of scope are non-operational issues, e.g., civil and criminal legal generalized theories of content, access and capabilities. The basic goals identified by the chairs are: 1) standardize structured query format, 2) produce mechanisms to allow for query redirection and server-server queries, and 3) maintain interoperability among old clients, old servers, new clients and new servers. Initial timetable: Sep 01: Initial spec Jan 02: Revisions Mar 02: Done RIR - RIPE NCC: - --------------- Mirjam presented the RIPE NCC whois uses: track IP and ASN allocation, maintain contact info, and maintain both reverse and forward domain name data. Data are populated both by the RIPE NCC and the domain holders. In addition, RIPE uses whois as part of its routing registry (RIPEDB), which registers some forms of routing info; this is based on RPSL a syntactically rich form which allows users to produce router configurations and which contains route object maintainer contact information. She noted that APNIC uses a version of the RIPE NCC code for similar purposes. The query language is structured: o RPSL for the routing registry, o attribute/value pairs for the IP data, This struc