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 structure is transparent to the user. Data is 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. RIR - ARIN: - ----------- Cathy presented the ARIN whois use, similar to that of RIPE (above). She noted 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. Discussion: - ----------- Randy discussed use, noting that many ccTLDs run RIPE code, 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. Randy noted the four software families: RIPE, NSI, ARIN (Forked from NSI), and RADB. Andy noted some ccTLDs (e.g. New Zealand) have rolled their own. Jaap reported on the whois service for the Dutch ccTLD, which limits hosts to 500 queries a day. The .nl whois 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, and is blocked. George commented that 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 commented that the Japanese data is in encoded in JIS, and that a trailing "/e" yeilds ASCII encoded data, whois -h whois.nic.ad.jp u-tokyo.ac.jp whois -h whois.nic.ad.jp u-tokyo.ac.jp/e and whois -h whois.nic.ad.jp help/e The following lists are brief summary of answers when he 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. [all others unclear or no response] .ca : whois.cira.ca 43 8bits [per Dan] .ng : whois.rg.net -- IRRD [per Randy] .ua : whois.com.ua 43 RIPE format, 8 bits [ EBW: Someone should html-ize this and put it on the web, to be delta'd until (most) all 267 TLDs and all 3 (or 5) RIRs are documented. Volunteers? ] As with other whois services, a clear concern in the APNIC reason is the use of whois to obtain data on members, "grazing". A distinction is clear to the APNIC members that some forms (e.g. Geoff Houston's data association grazing) are desirable. NIC-HANDLES: - ------------ Randy presented on NIC handle info in the whois data at ARIN and RIPE. Different registries have different identities attached to the same HANDLE 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).*** [Engin Gunduz (RIPE NCC) comments on the scribe's original that the other DBs are not dumped into their own. The just allow users to create person objects with non-RIPE NIC handles.] Nomenclature: - ------------- EBW 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. DC presented issues/desiderata for queries: o a standardized query format, o possibly expressed as a regularized query "template", so that independent of the content a common query format can be used, o constrained XML mentioned as a format (later rejected; see below). for responses: o a structured output with standard labels, o registered response codes, o 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 the WG needs strong indications why individual fixes are needed so the WG can do the cost/benefit analysis. The first justification put forward was for structured output, as an aid to parsing. John 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 there was some agreement that it if the queries were not posed to arbitrary whois servers, but to an enumerated set which adhered to a published standard (such as the RPSL [rfc2622] syntax), that this concern would be mitigated. This approach applies to the transition issue as well. Mark commented 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). Greg commented that with authentication and a well known format, the set of requirements sounds a lot less like whois. Mark added the original whois' function was as a public service with general availability, and someone observed that 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. DC 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. DC 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. DC 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. EBW and DC reviewed other working groups salient to this work: provreg, idn, *ng, security? Bill noted that there are also people still revising and enhancing rwhois protocols and that it would be useful to coordinate with them. Patrik made 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. EBW agreed that good stewardship is an alternate to good grazing, but it outside the scope of a working group to do more than encourage (provide a mechanism for) good stewardship. A listing and prioritizing of candidates for the problem list was then held, the results are summarized below item (shown by contributor) each: Andy: Privacy and access control. Strong interest. Discussion on several aspects, e.g., applications and throttling. Randy: 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: should be transcribable (short) query format. Agreed. Hans: Meet ICANN contract requirements. Disagreed. Bill: motivate accuracy, etc. Disagreed. (?) Meeting adjourned. The last agenda item, "it isn't whois:43", was not covered in this meeting. End of minutes and chairs' corrections/amendations/fixes. ------- End of Forwarded Message From owner-ietf-whois Sun Sep 2 09:26:42 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f82GQgE14436 for ietf-whois-bks; Sun, 2 Sep 2001 09:26:42 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f82GQaD14432 for ; Sun, 2 Sep 2001 09:26:37 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.8.8/8.8.8) with ESMTP id MAA17379; Sun, 2 Sep 2001 12:29:57 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200109021629.MAA17379@nic-naa.net> To: ietf-whois@imc.org cc: brunner@nic-naa.net, dcrocker@brandenburg.com Subject: Notice to Mariners: loss of navigational aids ("whois consultations") Date: Sun, 02 Sep 2001 12:29:57 -0400 From: Eric Brunner Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, I attended a "whois" related industry event in Washington earlier this month, directly after the London IETF meeting. I don't want to go into detail, as oddly, there wasn't much, or name names. I attended as a NeuStar MTS, along with the Director for Law and Policy of NeuLevel (.biz registry operator). What I do want to mention is that there was the assertion that a universal, consistent, and correct "whois" was desireable, and therefore technically feasible, and feasible within the confines of a free service. The terms "universal", "consistent" and "correct" were not defined, but "universal" clearly included all gTLDs, and given the goals [1] advanced by the advocates of this cliam, national as well. There may be more such events, possibly with different focii and invitees. The relevancy, if any, for the nacent IETF whois:43 (whoisfix) and/or !43 working groups, is that the technical complexity of a data base with 270+ physically disjoint authoritative views and schemas supporting a useful single access mechanism, having consistency semantics, and being correct, appears to me to be under-appreciated, particularly in the venue mentioned above. Back to process, in my next mailings I'll offer yet-another-charter Dave and I've cooked up based upon London and subsequent list traffic. [1] Trademark, and law enforcement spokespersons. Eric P.S. Notices to Mariners are the CERT Advisories of the maritime industry, and lost bouys are a fact of life, in Maine waters and elsewhere. From owner-ietf-whois Sun Sep 2 09:50:37 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f82Gobo14659 for ietf-whois-bks; Sun, 2 Sep 2001 09:50:37 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f82GoaD14655 for ; Sun, 2 Sep 2001 09:50:36 -0700 (PDT) Received: from bbprime.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA09139; Sun, 2 Sep 2001 09:50:36 -0700 Message-Id: <5.1.0.14.2.20010902095019.032e7110@dcrocker.net> X-Sender: dhc@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 02 Sep 2001 09:50:37 -0700 To: Eric Brunner From: Dave Crocker Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") Cc: ietf-whois@imc.org, brunner@nic-naa.net, dcrocker@brandenburg.com In-Reply-To: <200109021629.MAA17379@nic-naa.net> 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 09:29 AM 9/2/2001, Eric Brunner wrote: >P.S. Notices to Mariners are the CERT Advisories of the maritime industry, > and lost bouys are a fact of life, in Maine waters and elsewhere. Eric, your biases are showing. there is also a problem with lost gulls. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-ietf-whois Sun Sep 2 09:57:32 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f82GvWf14710 for ietf-whois-bks; Sun, 2 Sep 2001 09:57:32 -0700 (PDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f82GvUD14705 for ; Sun, 2 Sep 2001 09:57:30 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15daYi-000H3G-00; Sun, 02 Sep 2001 09:57:20 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Brunner Cc: ietf-whois@imc.org Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") References: <200109021629.MAA17379@nic-naa.net> Message-Id: Date: Sun, 02 Sep 2001 09:57:20 -0700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > the technical complexity of a data base with 270+ physically disjoint > authoritative views and schemas supporting a useful single access > mechanism, having consistency semantics, and being correct, appears to > me to be under-appreciated, particularly in the venue mentioned above. convincing folk of the difficulty and inadvisability of their political ambitions is usually futile and extremely frustrating. sometimes, it is best to let them learn what they can from experience. this could be one of those times. randy From owner-ietf-whois Sun Sep 2 10:20:40 2001 Received: by above.proper.com (8.11.6/8.11.3) id f82HKeK15006 for ietf-whois-bks; Sun, 2 Sep 2001 10:20:40 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f82HKdD15002 for ; Sun, 2 Sep 2001 10:20:39 -0700 (PDT) Received: from bbprime.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA09996; Sun, 2 Sep 2001 10:20:40 -0700 Message-Id: <5.1.0.14.2.20010902100741.03376690@dcrocker.net> X-Sender: dhc@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 02 Sep 2001 10:10:02 -0700 To: Randy Bush From: Dave Crocker Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") Cc: ietf-whois@imc.org In-Reply-To: References: <200109021629.MAA17379@nic-naa.net> 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: Eric did not suggest trying to educate those folks. He noted that we have a ready market for our work and that that market is clearly not going to satisfy their requirement on their own. It's OUR opportunity. d/ At 09:57 AM 9/2/2001, Randy Bush wrote: > > the technical complexity of a data base with 270+ physically disjoint > > authoritative views and schemas supporting a useful single access > > mechanism, having consistency semantics, and being correct, appears to > > me to be under-appreciated, particularly in the venue mentioned above. > >convincing folk of the difficulty and inadvisability of their political >ambitions is usually futile and extremely frustrating. sometimes, it is >best to let them learn what they can from experience. this could be one >of those times. ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-ietf-whois Wed Sep 5 08:16:32 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85FGWc24471 for ietf-whois-bks; Wed, 5 Sep 2001 08:16:32 -0700 (PDT) Received: from lenny.harvard.edu (lenny.harvard.edu [128.103.60.67]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85FGUD24467 for ; Wed, 5 Sep 2001 08:16:30 -0700 (PDT) Received: from camailp.harvard.edu (camailp.harvard.edu [128.103.26.26]) by lenny.harvard.edu (Postfix) with ESMTP id F11B35A2 for ; Wed, 5 Sep 2001 11:16:18 -0400 (EDT) Received: from [128.103.192.74] by camailp.harvard.edu (Post.Office MTA v3.5.3 release 223 ID# 0-62422U7000L700S0V35) with ESMTP id edu for ; Wed, 5 Sep 2001 11:16:18 -0400 Mime-Version: 1.0 X-Sender: jcamp@camail1.harvard.edu (Unverified) Message-Id: In-Reply-To: <200109021629.MAA17379@nic-naa.net> References: <200109021629.MAA17379@nic-naa.net> Date: Wed, 5 Sep 2001 16:16:37 +0100 To: ietf-whois@imc.org From: Jean Camp Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") 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:29 pm -0400 9/2/01, Eric Brunner wrote: >All, > >I attended a "whois" related industry event in Washington earlier this month, >directly after the London IETF meeting. I don't want to go into detail, as >oddly, there wasn't much, or name names. I attended as a NeuStar MTS, along >with the Director for Law and Policy of NeuLevel (.biz registry operator). > >What I do want to mention is that there was the assertion that a universal, >consistent, and correct "whois" was desireable, and therefore technically >feasible, and feasible within the confines of a free service. The terms >"universal", "consistent" and "correct" were not defined, but "universal" >clearly included all gTLDs, and given the goals [1] advanced by the advocates >of this cliam, national as well. whois was considered under IETF for the purpose of maintaining correct technical contact information. Notice this is entirely distinct from billing information, and distinct from providing information for law enforcement. The two later issues are beyond the interest of IETF. Notice also the observation that whois is currently failing in its core and critical function: providing uniform technical contact information. This is most noteworthy for those who would overload it with additional functions. regards, Jean > >There may be more such events, possibly with different focii and invitees. > >The relevancy, if any, for the nacent IETF whois:43 (whoisfix) and/or !43 >working groups, is that the technical complexity of a data base with 270+ >physically disjoint authoritative views and schemas supporting a useful >single access mechanism, having consistency semantics, and being correct, >appears to me to be under-appreciated, particularly in the venue mentioned >above. > >Back to process, in my next mailings I'll offer yet-another-charter Dave and >I've cooked up based upon London and subsequent list traffic. > >[1] Trademark, and law enforcement spokespersons. > >Eric > >P.S. Notices to Mariners are the CERT Advisories of the maritime industry, > and lost bouys are a fact of life, in Maine waters and elsewhere. -- From owner-ietf-whois Wed Sep 5 08:24:24 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85FOOO24736 for ietf-whois-bks; Wed, 5 Sep 2001 08:24:24 -0700 (PDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85FOND24732 for ; Wed, 5 Sep 2001 08:24:23 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15eeXK-000DlJ-00; Wed, 05 Sep 2001 08:24:18 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jean Camp Cc: ietf-whois@imc.org Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") References: <200109021629.MAA17379@nic-naa.net> Message-Id: Date: Wed, 05 Sep 2001 08:24:18 -0700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hi jean, > whois was considered under IETF for the purpose of maintaining > correct technical contact information. Notice this is entirely > distinct from billing information, and distinct from providing > information for law enforcement. The two later issues are beyond the > interest of IETF. > > Notice also the observation that whois is currently failing in its > core and critical function: providing uniform technical contact > information. This is most noteworthy for those who would overload it > with additional functions. i suspect we are confusing whois, the protocol on port 43 with which the ietf is concerned, and one of many applications of that protocol. if there are problems, perhaps the protocol needs work. but, as it is old, used for many applications, some of which are not even publicly known, we are not likely to get a lot of change without breaking something. and our culture is somewhat disinclined to breakage. then one may need to ask if the applications having problems fitting into the whois protocol should consider a different protocol more suitable to their needs. randy From owner-ietf-whois Wed Sep 5 08:52:48 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85Fqmk27891 for ietf-whois-bks; Wed, 5 Sep 2001 08:52:48 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85FqlD27883 for ; Wed, 5 Sep 2001 08:52:47 -0700 (PDT) Received: from bbprime.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA00607; Wed, 5 Sep 2001 08:52:48 -0700 Message-Id: <5.1.0.14.2.20010905084207.03515630@dcrocker.net> X-Sender: dhc@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Sep 2001 08:44:22 -0700 To: Randy Bush From: Dave Crocker Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") Cc: ietf-whois@imc.org In-Reply-To: References: <200109021629.MAA17379@nic-naa.net> 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 08:24 AM 9/5/2001, Randy Bush wrote: >if there are problems, perhaps the protocol needs work. but, as it is >old, used for many applications, some of which are not even publicly >known, we are not likely to get a lot of change without breaking >something. and our culture is somewhat disinclined to breakage. > >then one may need to ask if the applications having problems fitting >into the whois protocol should consider a different protocol more >suitable to their needs. You did an excellent job, at the last IETF meeting, of showing that Whois is already broken, FOR ITS INTENDED OPERATIONAL FUNCTIONS. Standardizing such things as formats, response codes, and label registration, are also common to the IETF culture, including for established activities. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-ietf-whois Wed Sep 5 09:13:00 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85GD0Z29861 for ietf-whois-bks; Wed, 5 Sep 2001 09:13:00 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85GCwD29857 for ; Wed, 5 Sep 2001 09:12:58 -0700 (PDT) Received: from [193.0.1.177] (dhcp177.ripe.net [193.0.1.177]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id f85GCHG29345; Wed, 5 Sep 2001 18:12:17 +0200 Mime-Version: 1.0 X-Sender: joao@birch.ripe.net Message-Id: In-Reply-To: <5.1.0.14.2.20010905084207.03515630@dcrocker.net> References: <200109021629.MAA17379@nic-naa.net> <5.1.0.14.2.20010905084207.03515630@dcrocker.net> Date: Wed, 5 Sep 2001 18:12:18 +0200 To: Dave Crocker , Randy Bush From: Joao Luis Silva Damas Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") 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 08:44 -0700 5/9/01, Dave Crocker wrote: > >You did an excellent job, at the last IETF meeting, of showing that >Whois is already broken, FOR ITS INTENDED OPERATIONAL FUNCTIONS. Sorry to differ but... whois.ripe.net, whois.apnic.net and whois.arin.net seem to be doing quite well for their intended purposes. Joao -- From owner-ietf-whois Wed Sep 5 10:38:35 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85HcZT01890 for ietf-whois-bks; Wed, 5 Sep 2001 10:38:35 -0700 (PDT) Received: from attila.bofh.it (postfix@attila.bofh.it [213.92.8.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85HcXD01886 for ; Wed, 5 Sep 2001 10:38:33 -0700 (PDT) Received: by attila.bofh.it (Postfix, from userid 10) id 89DC9604E6; Wed, 5 Sep 2001 19:38:32 +0200 (CEST) Received: by wonderland.linux.it (Postfix/Md, from userid 1001) id B460817E18; Wed, 5 Sep 2001 19:37:41 +0200 (CEST) Date: Wed, 5 Sep 2001 19:37:41 +0200 From: "Marco d'Itri" Cc: ietf-whois@imc.org Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") Message-ID: <20010905193741.B5101@wonderland.linux.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sep 05, Randy Bush wrote: >if there are problems, perhaps the protocol needs work. but, as it is >old, used for many applications, some of which are not even publicly >known, we are not likely to get a lot of change without breaking >something. and our culture is somewhat disinclined to breakage. Netsol broke whois a lot of times in the past years by changing the output format and the world has not ended yet. OTOH, many people would scream if the RIPE software would change its behaviour. -- ciao, Marco From owner-ietf-whois Wed Sep 5 10:57:19 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85HvJE02388 for ietf-whois-bks; Wed, 5 Sep 2001 10:57:19 -0700 (PDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85HvID02384 for ; Wed, 5 Sep 2001 10:57:18 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15egvH-0000DT-00; Wed, 05 Sep 2001 10:57:11 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Marco d'Itri" Cc: ietf-whois@imc.org Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") References: <20010905193741.B5101@wonderland.linux.it> Message-Id: Date: Wed, 05 Sep 2001 10:57:11 -0700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Netsol broke whois a lot of times in the past years by changing the > output format and the world has not ended yet. they did not break whois, they broke (or changed) their application's use of the protocol. naturally, this affected the users of the netsol application. > OTOH, many people would scream if the RIPE software would change its > behaviour. but it has! 181+ to rpsl. the interesting difference is that the format of the data (which the ripe application uses the whois protocol to transfer) is DOCUMENTED! randy From owner-ietf-whois Wed Sep 5 11:23:56 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85INuD02957 for ietf-whois-bks; Wed, 5 Sep 2001 11:23:56 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85INsD02953 for ; Wed, 5 Sep 2001 11:23:55 -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 f85IMqx04537; Wed, 5 Sep 2001 14:22:52 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200109051822.f85IMqx04537@nic-naa.net> To: ietf-whois@imc.org cc: brunner@nic-naa.net, dhc@dcrocker.net, randy@psg.com, paf@cisco.com Subject: Proposal for two of three parts of the whoisfix charter Date: Wed, 05 Sep 2001 14:22:52 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, This is familiar ground. Joan Gargano chaired the Whois and Network Information Lookup Service (wnils) Working Group, concluding in February, 1996, and producing rfc1834/5, 1923/4, and 2957/8, the Whois++ set of memos. David Conrad chaired the Internet Registry Evolution (ire) Working Group, closer in spirit to the current Provisioning Registry Protocol (provreg) Working Group than this one, but still a kindred spirit, concluding in January 1997. Linda Millington and Sri Sataluri chaired the Integrated Directory Services (ids) Working Group, and Patric Faltstrom and Roland Hedberg chaired the Common Indexing Protocol (find), concluding in October 1998 and February 1999, respectively. Mark Kosters and Scott Williamson RWhois Operational Development (rwhois) Working Group, concluding in September 1998. This list is not exhaustive. What is required next is three parts: - the boiler-plate -- people, roles, lists - the charter: a tractible, useful in-scope problem statement, and possibly also an out-of-scope statement and (optionally) one or more initial documents - goals and milestones Here is what we propose for the first and last items, the boiler-plate and the goals and milestones. > WHOISfix > -------- > > Chair(s): > Eric Brunner-Williams > Dave Crocker > > Area Director(s): > Patrik Fältström (Applications) > Randy Bush (Operations and Management) > > Area Advisor(s): > Patrick and Randy > > Mailing lists: > General Discussion: ietf-whois@imc.org > To Subscribe: ietf-whois-request@imc.org > In Body: subscribe > Archive: www.imc.org/whois > > Description of Working Group: > > > > > Goals and Milestones: > > Sep 01 Working group agreement on the list of changes to pursue > Nov 01 Initial specification of these changes > Feb 02 Initial specification of these changes > Mar 02 Drafts submitted for consideration as Proposed Standard I'm already sure that this schedule is too tight, but I do want to see this activity conclude in '02, and with non-lamentable work-product. Lets get in agreement with these two parts, the process bits, or an alternative, then solve for substance. I'm off on business (Montevideo ICANN) for a week, and then off to RatLand (Disny World according to my spouse and 5 year old) until the 18th. I hope to hear from the APNIC attendees as we fill in the blanks post-London, and if there is anything relevant from the Montevideo ICANN meeting, I'll post notes. Cheers, Eric From owner-ietf-whois Wed Sep 5 14:48:17 2001 Received: by above.proper.com (8.11.6/8.11.3) id f85LmHO08051 for ietf-whois-bks; Wed, 5 Sep 2001 14:48:17 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85LmHD08047 for ; Wed, 5 Sep 2001 14:48:17 -0700 (PDT) Received: from bbprime.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA12515; Wed, 5 Sep 2001 14:48:17 -0700 Message-Id: <5.1.0.14.2.20010905144546.033ac008@dcrocker.net> X-Sender: dhc@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Sep 2001 14:46:52 -0700 To: Joao Luis Silva Damas From: Dave Crocker Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") Cc: Randy Bush , ietf-whois@imc.org In-Reply-To: References: <5.1.0.14.2.20010905084207.03515630@dcrocker.net> <200109021629.MAA17379@nic-naa.net> <5.1.0.14.2.20010905084207.03515630@dcrocker.net> 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: Oh? You are disagreeing with the examples that Randy provided at the IETF meeting? d/ ps. hint: the IETF is about standards for global interoperability, not isolated utility. At 09:12 AM 9/5/2001, Joao Luis Silva Damas wrote: >At 08:44 -0700 5/9/01, Dave Crocker wrote: >>You did an excellent job, at the last IETF meeting, of showing that Whois >>is already broken, FOR ITS INTENDED OPERATIONAL FUNCTIONS. > >Sorry to differ but... > >whois.ripe.net, whois.apnic.net and whois.arin.net seem to be doing quite >well for their intended purposes. ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-ietf-whois Wed Sep 5 15:02:05 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85M25Y08342 for ietf-whois-bks; Wed, 5 Sep 2001 15:02:05 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85M25D08338 for ; Wed, 5 Sep 2001 15:02:05 -0700 (PDT) Received: from bbprime.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA12915 for ; Wed, 5 Sep 2001 15:02:08 -0700 Message-Id: <5.1.0.14.2.20010905144713.03137008@dcrocker.net> X-Sender: dhc@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Sep 2001 14:56:22 -0700 To: ietf-whois@imc.org From: Dave Crocker Subject: The meaning of "whois" In-Reply-To: References: <20010905193741.B5101@wonderland.linux.it> 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 10:57 AM 9/5/2001, Randy Bush wrote: > > Netsol broke whois a lot of times in the past years by changing the > > output format and the world has not ended yet. > >they did not break whois, they broke (or changed) their application's >use of the protocol. naturally, this affected the users of the netsol >application. A serious source of confusion appears to be the multivariate use of the term "whois". Within the IETF, I believe we are consistent to mean use of the current, IETF standards-track Whois protocol. Outside the IETF it tends to mean use of that protocol AND use of some unspecified set of enhancements (or additional protocols). Both within the IETF and outside of it, we are *IN*consistent in referencing the database that is used. And there are lots of DBs to choose from, all in substantial use. Subsets of the DBs have consistent formats, but different content. Some have consistent semantics, but different content. So a technical discussion probably needs to be explicit about 1) protocol 2) port 3) syntax 4) semantics 5) data source / author / owner (eg, RIPE vs. NetSol.) Use of the term Whois:43 covers requirements 1 & 2. I suggest we get into the habit of using that notation within this group, since it is what the BOF had as its focus and agreed to limit itself to. Choice of item 5 will, of course, tend to specify 3 & 4, so the useful consideration of item 5 is probably in terms of "categories of use" such as RIR vs. DNS registry. We need to work on clarifying items 3-5, in terms of available choices and specific selections. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-ietf-whois Wed Sep 5 15:09:51 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85M9pF08462 for ietf-whois-bks; Wed, 5 Sep 2001 15:09:51 -0700 (PDT) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85M9oD08458 for ; Wed, 5 Sep 2001 15:09:50 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ekri-00079Y-00; Wed, 05 Sep 2001 15:09:46 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Crocker Cc: Joao Luis Silva Damas , ietf-whois@imc.org Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") References: <5.1.0.14.2.20010905084207.03515630@dcrocker.net> <200109021629.MAA17379@nic-naa.net> <5.1.0.14.2.20010905144546.033ac008@dcrocker.net> Message-Id: Date: Wed, 05 Sep 2001 15:09:46 -0700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > ps. hint: the IETF is about standards for global interoperability, not > isolated utility. whois port 43 is interoperable globally. applications which use it may not be. similarly, just because two applications both use tcp does not mean that you can connect an ssh client to an ftp server stick an msword document in one end and get tex out the other. at least the format of the data ripe produces in response to a whois query is that of an ietf (proposed) standard. randy From owner-ietf-whois Wed Sep 5 15:17:42 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85MHg208646 for ietf-whois-bks; Wed, 5 Sep 2001 15:17:42 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85MHeD08642 for ; Wed, 5 Sep 2001 15:17:40 -0700 (PDT) Received: from bbprime.dcrocker.net (c1193160-a.snvl1.sfba.home.com [65.0.152.112]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA13532; Wed, 5 Sep 2001 15:17:43 -0700 Message-Id: <5.1.0.14.2.20010905151650.03077008@dcrocker.net> X-Sender: dhc@brandenburg.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Sep 2001 15:17:45 -0700 To: Randy Bush From: Dave Crocker Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") Cc: ietf-whois@imc.org In-Reply-To: References: <5.1.0.14.2.20010905084207.03515630@dcrocker.net> <200109021629.MAA17379@nic-naa.net> <5.1.0.14.2.20010905144546.033ac008@dcrocker.net> 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 03:09 PM 9/5/2001, Randy Bush wrote: > > ps. hint: the IETF is about standards for global interoperability, not > > isolated utility. > >whois port 43 is interoperable globally. as long as one ignores the data, yes it is. however, ignoring the data is not something that the IETF typically does. d/ ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 From owner-ietf-whois Thu Sep 6 01:10:23 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f868ANF06050 for ietf-whois-bks; Thu, 6 Sep 2001 01:10:23 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f868AKD06043 for ; Thu, 6 Sep 2001 01:10:21 -0700 (PDT) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id f868AFG03479 for ; Thu, 6 Sep 2001 10:10:15 +0200 Received: (from shane@localhost) by x17.ripe.net (8.11.6/8.11.6) id f868AFF13097 for ietf-whois@imc.org; Thu, 6 Sep 2001 10:10:15 +0200 Date: Thu, 6 Sep 2001 10:10:14 +0200 From: Shane Kerr To: ietf-whois@imc.org Subject: Re: Notice to Mariners: loss of navigational aids ("whois consultations") Message-ID: <20010906101011.A13093@x17.ripe.net> References: <20010905193741.B5101@wonderland.linux.it> 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-09-05 10:57:11 -0700 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2001-09-05 10:57:11 -0700, Randy Bush wrote: > > > OTOH, many people would scream if the RIPE software would change its > > behaviour. > > but it has! 181+ to rpsl. the interesting difference is that the > format of the data (which the ripe application uses the whois protocol > to transfer) is DOCUMENTED! I'd like to add not only is it documented, but RPSL is documented in standards-track RFC's. As mentioned in the London IETF meeting, the RIPE Whois server does almost everything requested in terms of features desired from the group at the BOF (excepting of course things RIPE NCC can't do by itself, such as standardization and sharing NIC handle data). Perhaps the easiest tact might be to formalize RPSL extensions to cover non-routing data. RIPE already uses such extensions to cover our registration data. -- Shane Carpe Diem p.s. I'm not a big fan of RPSL, but it is already an IETF RFC, is used by a fairly large community, and it does work. ;) From owner-ietf-whois Tue Sep 18 08:08:36 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8IF8aM07655 for ietf-whois-bks; Tue, 18 Sep 2001 08:08:36 -0700 (PDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8IF8YD07645 for ; Tue, 18 Sep 2001 08:08:35 -0700 (PDT) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id LAA23139; Tue, 18 Sep 2001 11:08:34 -0400 (EDT) Received: from localhost (cathym@localhost) by ops.arin.net (8.9.0/8.9.0) with SMTP id LAA22064; Tue, 18 Sep 2001 11:08:24 -0400 (EDT) Date: Tue, 18 Sep 2001 11:08:24 -0400 (EDT) From: Cathy Murphy Reply-To: Cathy Murphy To: ietf-not43@lists.research.netsol.com, ietf-whois@imc.org Subject: New Whois-like maillist 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 just found out about another Whois-related project and thought folks subscribed to these lists might be interested in this latest development. It appears that Yet Another Maillist discussing a future whois-type implementation (UWho = Universal Whois) has been created: http://www.uwho.verisignlabs.com/ --- Cathy Murphy American Registry for Internet Numbers (ARIN) From owner-ietf-whois Tue Sep 18 08:10:50 2001 Received: by above.proper.com (8.11.6/8.11.3) id f8IFAoP07945 for ietf-whois-bks; Tue, 18 Sep 2001 08:10:50 -0700 (PDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8IFAmD07939 for ; Tue, 18 Sep 2001 08:10:48 -0700 (PDT) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id LAA25158; Tue, 18 Sep 2001 11:10:51 -0400 (EDT) Received: from localhost (cathym@localhost) by ops.arin.net (8.9.0/8.9.0) with SMTP id LAA22602; Tue, 18 Sep 2001 11:10:49 -0400 (EDT) Date: Tue, 18 Sep 2001 11:10:49 -0400 (EDT) From: Cathy Murphy To: ietf-not43@lists.research.netsol.com, ietf-whois@imc.org cc: dbwg@arin.net Subject: RWhois update 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: While I'm at it, a plug for the home team: ARIN released a beta version of an updated RWhois server software with working referrals. Interested parties can find further details at: http://www.arin.net/mailinglists/dbwg/0153.html Please direct further discussion of this topic to ARIN's Database Working Group mailing list. --- Cathy Murphy American Registry for Internet Numbers (ARIN) From owner-ietf-whois Tue Sep 25 14:34:25 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8PLYPE24602 for ietf-whois-bks; Tue, 25 Sep 2001 14:34:25 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8PLYDD23280 for ; Tue, 25 Sep 2001 14:34:14 -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 f8PLXYu05628; Tue, 25 Sep 2001 17:33:34 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200109252133.f8PLXYu05628@nic-naa.net> To: ietf-whois@imc.org cc: brunner@nic-naa.net, dhc@dcrocker.net, randy@psg.com, paf@cisco.com Subject: Montevideo note Date: Tue, 25 Sep 2001 17:33:33 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, As promissed, my notes from the Montevideo meeting of ICANN earlier this month. Paul Kane presented an analysis [1] of the DNSO Whois survey. Paul was also running against Amadeu Abril i Abril for a seat on the ICANN Board [2], which may have detracted from our communication. He mentioned an interim report will come out in April 2002 and there will be an updated report in Marina del Rey, whether that is MdR-03 in Nov '01 or MdR-04 in '02 I don't know. In sum, no change. Eric [1] http://cyber.law.harvard.edu/icann/montevideo/archive/pres/whois.html [2] Amadeu Abril i Abril was elected for a 3 year term to the ICANN Board, 9 September 2001, Montevideo. From owner-ietf-whois Fri Sep 28 12:38:56 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8SJcuZ25743 for ietf-whois-bks; Fri, 28 Sep 2001 12:38:56 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8SJcrD25739 for ; Fri, 28 Sep 2001 12:38:53 -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 f8SJcLc22996; Fri, 28 Sep 2001 15:38:21 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200109281938.f8SJcLc22996@nic-naa.net> To: ietf-provreg@cafax.se, ietf-whois@imc.org, ietf-idrm@lists.elistx.com cc: brunner@nic-naa.net Subject: FYI: P3P Latest republished (editing glitch) Date: Fri, 28 Sep 2001 15:38:21 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, I'm sending this to the lists where I've mentioned using the P3P vocabulary as a starting point for discussing policy (privacy and/or data collection) metadata in some XML marked up transaction stream. This is just so those who do bother to read some of the spec know that we delta'd the external version just a few days ago, and to show how facile and adept we are, did it again three days later (today). Eric ------- Forwarded Message Subject: 24 September Last Call Draft republished Dear all, we missed to include a change into the 24 September Last Call Working Draft. The Draft was therefor republished on 28 September 2001 with the missing changes included. It contains also some explanatory words in the status-section. The missing change was: The P3P Working Group decided a time ago, that an embedded DATASCHEMA is a child of POLICIES. We had to change the date of the document, in case after 3 days, someone was already relying on it. Nevertheless, the Last Call period and the namespace etc... remain the same. The document can be found as usual under http://www.w3.org/TR/P3P or direct under http://www.w3.org/TR/2001/WD-P3P-20010928/ ------- End of Forwarded Message From owner-ietf-whois Fri Sep 28 12:42:24 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8SJgOW25846 for ietf-whois-bks; Fri, 28 Sep 2001 12:42:24 -0700 (PDT) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8SJgMD25841 for ; Fri, 28 Sep 2001 12:42:23 -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 f8SJg5c23023 for ; Fri, 28 Sep 2001 15:42:05 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200109281942.f8SJg5c23023@nic-naa.net> To: ietf-whois@imc.org Subject: FWD: ARIN/RIPE/APNIC WHOIS:43 bulk copy policy Date: Fri, 28 Sep 2001 15:42:04 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, Of interest is the policy of exclusion of contact data from the data that is available via bulk (non-WHOIS:43) transfer. Also of interest is the imposition of an AUP. See dbwg@arin.net for proposal discussion. Eric ------- Forwarded Message From: Member Services Message-Id: <200109281716.NAA20688@ops.arin.net> Subject: Policy Proposal 2001-7 To: arin-announce@arin.net, dbwg@arin.net Date: Fri, 28 Sep 2001 13:16:32 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: dbwg-request@arin.net Precedence: bulk ARIN welcomes feedback and discussion about the following policy proposal in the weeks leading to the ARIN Public Policy and Members meetings in Miami, scheduled for October 28 - 31, 2001. All feedback received on the mailing lists about this policy proposal will be included in the discussions that will take place in Miami. ARIN currently provides a bulk copy of WHOIS output only to organizations that will use the data for technical research purposes and sign an acceptable use policy. Point of contact information is excluded from these bulk copies. APNIC and RIPE NCC provide bulk copies of their WHOIS output on their FTP sites for any organization that wishes to obtain the data providing they agree to the acceptable use policy that accompanies the data. Proposal: It is proposed ARIN provide a bulk copy of WHOIS output, minus point of contact information, on the ARIN FTP site for download by any organization that wishes to obtain the data providing they agree to ARIN's acceptable use policy that would accompany the data. This policy proposal discussion will take place on the database working group mailing list (dbwg@arin.net). Subscription information is available at http://www.arin.net/members/mailing.htm Richard Jimmerson Director of Operations American Registry for Internet Numbers ------- End of Forwarded Message From owner-ietf-whois Wed Oct 31 08:20:45 2001 Received: by above.proper.com (8.11.6/8.11.3) id f9VGKjM01898 for ietf-whois-bks; Wed, 31 Oct 2001 08:20:45 -0800 (PST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VGKh801894 for ; Wed, 31 Oct 2001 08:20:43 -0800 (PST) Received: from libero.it (193.70.192.41) by smtp2.libero.it (6.0.032) id 3BD43C15002CC3E4 for ietf-whois@imc.org; Wed, 31 Oct 2001 17:20:38 +0100 Date: Wed, 31 Oct 2001 17:20:38 +0100 Message-Id: Subject: whois and dns... MIME-Version: 1.0 Content-Type: text/plain From: "sal" To: ietf-whois@imc.org X-XaM3-API-Version: 1.1.9.1.39.1.2 X-SenderIP: 212.177.57.193 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9VGKi801895 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: i'm searching any document about an overview on Whois database, how is work, the record's format ... etc. i don't understand the difference the whois with DNS... can you help me? sending document or link about this issues thanks in advance Salvatore loreto From owner-ietf-whois Wed Oct 31 08:41:42 2001 Received: by above.proper.com (8.11.6/8.11.3) id f9VGfgI02667 for ietf-whois-bks; Wed, 31 Oct 2001 08:41:42 -0800 (PST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VGfe802663 for ; Wed, 31 Oct 2001 08:41:40 -0800 (PST) Received: from ripe.net (dhcp180.ripe.net [193.0.1.180]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id f9VGfYq31188; Wed, 31 Oct 2001 17:41:34 +0100 Message-ID: <3BE02A58.7E4F3E98@ripe.net> Date: Wed, 31 Oct 2001 17:44:08 +0100 From: Andrei Robachevsky Organization: RIPE NCC X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sal CC: ietf-whois@imc.org Subject: Re: whois and dns... 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: sal wrote: > > i'm searching any document about an overview on Whois database, > how is work, the record's format ... etc. > There are so many flavours of whois databases, not sure which one you are interested in. Regarding the RIPE Whois database I may suggest RIPE Database Reference Manual at http://www.ripe.net/ripe/docs/databaseref-manual.html. > i don't understand the difference the whois with DNS... > > can you help me? sending document or link about this issues > > thanks in advance > Salvatore loreto Regards, Andrei Robachevsky RIPE NCC From owner-ietf-whois Wed Oct 31 08:41:25 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VGfPA02655 for ietf-whois-bks; Wed, 31 Oct 2001 08:41:25 -0800 (PST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VGfN802651 for ; Wed, 31 Oct 2001 08:41:23 -0800 (PST) Received: from libero.it (193.70.192.41) by smtp2.libero.it (6.0.032) id 3BD43C15002CE422; Wed, 31 Oct 2001 17:41:14 +0100 Date: Wed, 31 Oct 2001 17:41:13 +0100 Message-Id: Subject: RE: whois and dns... MIME-Version: 1.0 Content-Type: text/plain From: "sal" To: dliu@verisign.com Cc: ietf-whois@imc.org X-XaM3-API-Version: 1.1.9.1.39.1.2 X-SenderIP: 212.177.57.193 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9VGfO802652 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: where i find it? please send me a link ... > Get a copy of "DNS and BIND" and read it. > > -----Original Message----- > From: sal [mailto:salvatore.loreto@libero.it] > Sent: Wednesday, October 31, 2001 11:21 AM > To: ietf-whois@imc.org > Subject: whois and dns... > > > > > i'm searching any document about an overview on Whois database, > how is work, the record's format ... etc. > > i don't understand the difference the whois with DNS... > > can you help me? sending document or link about this issues > > thanks in advance > Salvatore loreto > From owner-ietf-whois Wed Oct 31 08:46:05 2001 Received: by above.proper.com (8.11.6/8.11.3) id f9VGk5o03164 for ietf-whois-bks; Wed, 31 Oct 2001 08:46:05 -0800 (PST) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VGk3803156 for ; Wed, 31 Oct 2001 08:46:04 -0800 (PST) Received: from libero.it (193.70.192.41) by smtp1.libero.it (6.0.032) id 3BD437D5002D0B7F; Wed, 31 Oct 2001 17:45:58 +0100 Date: Wed, 31 Oct 2001 17:45:58 +0100 Message-Id: Subject: Re: whois and dns... MIME-Version: 1.0 Content-Type: text/plain From: "sal" To: andrei@ripe.net Cc: ietf-whois@imc.org X-XaM3-API-Version: 1.1.9.1.39.1.2 X-SenderIP: 212.177.57.193 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9VGk4803159 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: thank but about the difference between DNS and WHOIS ? what do you say? > sal wrote: > > > > i'm searching any document about an overview on Whois database, > > how is work, the record's format ... etc. > > > > There are so many flavours of whois databases, not sure which one you > are interested in. Regarding the RIPE Whois database I may suggest RIPE > Database Reference Manual at > http://www.ripe.net/ripe/docs/databaseref-manual.html. > > > i don't understand the difference the whois with DNS... > > > > can you help me? sending document or link about this issues > > > > thanks in advance > > Salvatore loreto > > Regards, > > > Andrei Robachevsky > RIPE NCC > From owner-ietf-whois Wed Oct 31 08:51:10 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VGpAv04006 for ietf-whois-bks; Wed, 31 Oct 2001 08:51:10 -0800 (PST) Received: from mail.ultradns.com (mail.ultradns.net [204.74.100.34]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9VGp9804000 for ; Wed, 31 Oct 2001 08:51:09 -0800 (PST) Received: (qmail 9718 invoked from network); 31 Oct 2001 16:51:10 -0000 Received: from nat-external.ultradns.net (HELO jcdill-latitude.vo.cnchost.com) (204.74.100.10) by mail.ultradns.net with SMTP; 31 Oct 2001 16:51:10 -0000 Message-Id: <5.1.0.14.2.20011031084705.023b4ea0@127.0.0.1> X-Sender: inet-list@vo.cnchost.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 31 Oct 2001 08:48:13 -0800 To: "sal", dliu@verisign.com From: JC Dill Subject: RE: whois and dns... Cc: ietf-whois@imc.org In-Reply-To: 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: On 05:41 PM 10/31/2001 +0100, sal wrote: > >where i find it? >please send me a link ... > > > >> Get a copy of "DNS and BIND" and read it. google on "dns bind" and it takes about 30 seconds to find: http://www.dns.net/dnsrd/books.html#book-cricket From owner-ietf-whois Wed Oct 31 08:48:17 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VGmHn03513 for ietf-whois-bks; Wed, 31 Oct 2001 08:48:17 -0800 (PST) Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VGmF803506 for ; Wed, 31 Oct 2001 08:48:15 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15yyXG-000OtL-00; Wed, 31 Oct 2001 08:48:14 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "sal" Cc: andrei@ripe.net, ietf-whois@imc.org Subject: Re: whois and dns... References: Message-Id: Date: Wed, 31 Oct 2001 08:48:14 -0800 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > thank but about the difference between > DNS and WHOIS ? > > what do you say? you probably want to start with some survey texts such as "TCP/IP Network Administration" by Craig Hunt. randy From owner-ietf-whois Wed Oct 31 09:06:35 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VH6Zf04862 for ietf-whois-bks; Wed, 31 Oct 2001 09:06:35 -0800 (PST) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VH6X804858 for ; Wed, 31 Oct 2001 09:06:33 -0800 (PST) Received: from libero.it (193.70.192.41) by smtp1.libero.it (6.0.032) id 3BD437D5002D290B; Wed, 31 Oct 2001 18:06:03 +0100 Date: Wed, 31 Oct 2001 18:06:03 +0100 Message-Id: Subject: RE: whois and dns... MIME-Version: 1.0 Content-Type: text/plain From: "sal" To: inet-list@vo.cnchost.com Cc: dliu@verisign.com Cc: ietf-whois@imc.org X-XaM3-API-Version: 1.1.9.1.39.1.2 X-SenderIP: 212.177.57.193 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9VH6X804859 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: thanks, but i'm searching some free/downloadable book or articles, whitepapers or tutorials about the argument... > On 05:41 PM 10/31/2001 +0100, sal wrote: > > > >where i find it? > >please send me a link ... > > > > > > > >> Get a copy of "DNS and BIND" and read it. > > google on "dns bind" and it takes about 30 seconds to find: > > http://www.dns.net/dnsrd/books.html#book-cricket > > From owner-ietf-whois Wed Oct 31 10:28:50 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VISoN08013 for ietf-whois-bks; Wed, 31 Oct 2001 10:28:50 -0800 (PST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VISm808008 for ; Wed, 31 Oct 2001 10:28:48 -0800 (PST) Received: from libero.it (193.70.192.41) by smtp2.libero.it (6.0.032) id 3BD43C15002D881A for ietf-whois@imc.org; Wed, 31 Oct 2001 19:28:45 +0100 Date: Wed, 31 Oct 2001 19:28:45 +0100 Message-Id: Subject: whois in the host location MIME-Version: 1.0 Content-Type: text/plain From: "sal" To: ietf-whois@imc.org X-XaM3-API-Version: 1.1.9.1.39.1.2 X-SenderIP: 212.177.57.193 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f9VISn808009 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: but there isn't a whitepaper or tutorial on the whois? i'm studying the host location on a ip network, and i have read that a possible solution is the interrogation of a whois database. For me is clear the use of a geographical DNS for the position, but i don't understand the use of whois database for this issue. please can you help me in this issue Salvatore Loreto From owner-ietf-whois Wed Oct 31 12:17:28 2001 Received: by above.proper.com (8.11.6/8.11.3) id f9VKHS612779 for ietf-whois-bks; Wed, 31 Oct 2001 12:17:28 -0800 (PST) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VKHQ812774 for ; Wed, 31 Oct 2001 12:17:27 -0800 (PST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.9.3) with ESMTP id f9VKJ4m18888; Wed, 31 Oct 2001 15:19:05 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200110312019.f9VKJ4m18888@nic-naa.net> X-Mailer: exmh version 1.6.9 8/22/96 To: "sal" cc: ietf-whois@imc.org Subject: Re: whois in the host location In-Reply-To: Your message of "Wed, 31 Oct 2001 19:28:45 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Oct 2001 15:19:04 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Salvatore, This list is for the discussion of the whois protocol, defined in rfc954, and related protocols such as rwhois, defined in rfc2167, for "Birds of a Feather" sessions held at IETF-51, and IETF-49. There is another whois list as well, with a slightly different focus. Because the actual whois protocol can be written as (thanks to Rick Wesson) C: [::printable::]\r\n S: .*\r\n it is unlikely that any "whitepaper or tutorial" exist, though the subject is mentioned in survey texts. When I worked for Nokia Research I proposed to a co-worker that locality data could be used, both for network analysis (work along this line has been done at CAIDA), and for "local" services. There was a BoF on the subject at IETF-48, some overlap with the mobile ad-hoc working group (manet), and a deep connection with ntp. If your interests are along the lines of this, then this mailing list isn't what you are looking for. Simply adding geo-data to a whois-like database was done in the uucp mapping project. Eric co-chair, WhoisFix BoF, IETF-51 From owner-ietf-whois Wed Oct 31 16:15:05 2001 Received: by above.proper.com (8.11.6/8.11.3) id fA10F5x18808 for ietf-whois-bks; Wed, 31 Oct 2001 16:15:05 -0800 (PST) Received: from mail.verisignlabs.com (lists.verisignlabs.com [65.201.175.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id fA10F3818804 for ; Wed, 31 Oct 2001 16:15:04 -0800 (PST) Received: (qmail 6969 invoked from network); 1 Nov 2001 00:15:01 -0000 Received: from unknown (HELO newman.cto.netsol.com) (172.25.170.9) by 172.25.28.8 with SMTP; 1 Nov 2001 00:15:01 -0000 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 BB0EA43835 for ; Wed, 31 Oct 2001 19:15:00 -0500 (EST) Received: (from anewton@localhost) by zed.admin.cto.netsol.com (8.9.3+Sun/8.9.1) id TAA04769 for ietf-whois@imc.org; Wed, 31 Oct 2001 19:10:08 -0500 (EST) Date: Wed, 31 Oct 2001 19:10:08 -0500 From: Andrew Newton To: ietf-whois@imc.org Subject: Re: whois in the host location Message-ID: <20011031191008.A4754@zed.admin.cto.netsol.com> References: <200110312019.f9VKJ4m18888@nic-naa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200110312019.f9VKJ4m18888@nic-naa.net>; from brunner@nic-naa.net on Wed, Oct 31, 2001 at 03:19:04PM -0500 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 31, 2001 at 03:19:04PM -0500, Eric Brunner-Williams in Portland Maine wrote: > > This list is for the discussion of the whois protocol, defined in rfc954, > and related protocols such as rwhois, defined in rfc2167, for "Birds of Does whois++ count as "related"? -andy -- Andrew Newton VeriSign Applied Research anewton@research.netsol.com From owner-ietf-whois Fri Nov 9 16:46:41 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAA0kfw20688 for ietf-whois-bks; Fri, 9 Nov 2001 16:46:41 -0800 (PST) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAA0ke820684 for ; Fri, 9 Nov 2001 16:46:40 -0800 (PST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.9.3) with ESMTP id fAA0mYm12826 for ; Fri, 9 Nov 2001 19:48:34 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200111100048.fAA0mYm12826@nic-naa.net> To: ietf-whois@imc.org Subject: Planning for Salt Lake Date: Fri, 09 Nov 2001 19:48:34 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, If this BoF progresses to a WG, its would be best if its chairs did not both have a beneficiary relationship with the same company, incidently a whois:43 operator (NeuStar, .us; and NeuLevel, .biz). Dave brings all of the experience and good humor of a former Area Director, and an ability to attend IETF meetings. For family reasons I'm cutting back on non-essential travel, and may not travel from Maine to Salt Lake. There is still a charter to complete, and time-line drift to correct for, assuming that the dates and deliverables were approximately correct. The registry for .vn (Viet Nam) contacted me off-list a few days ago, looking for a whois server implementation. If anyone would like to contact them, drop me a note. I'll also take updates to the chart we started at London, the per-ccTLD details. Thanks, Eric From owner-ietf-whois Wed Nov 14 11:00:58 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAEJ0wP14145 for ietf-whois-bks; Wed, 14 Nov 2001 11:00:58 -0800 (PST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEJ0u814136 for ; Wed, 14 Nov 2001 11:00:56 -0800 (PST) Received: from x22.ripe.net.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id fAEJ0rq06735 for ; Wed, 14 Nov 2001 20:00:53 +0100 Date: Wed, 14 Nov 2001 20:00:45 +0100 (CET) From: Bruce Campbell X-X-Sender: To: IETF WHOIS BOF Subject: Draft on 'WHOIS' Protocol, without implications inherent in RFC954 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="12654081-1759836202-1005764310=:30058" Content-ID: Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --12654081-1759836202-1005764310=:30058 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The attached document is a semi-formal write up of some notes I've been scratching around for a few years now. The intent of the draft is as follows: Codify the behaviour of all observed operational WHOIS Servers. Remove the implications in RFC954 that there is a 'Root' WHOIS Server. ( The protocol definition should not have political considerations ) Remove the implications in RFC954 that there is solely one true query and output format. The following issues are expressly *not* covered beyond laying the responsibility for such on the Registry responsible for the given database: Privacy of Data. Requirements for Data to be Registered in a given Database. Query and Output format. What needs doing: Further define what a 'Registry' is (as an entity that is responsible for delegation/assignment/allocating a given resource) Do a proper diagram of the general Query structure. Removing those annoying 'TODO's from the document ;) Please send any comments to myself at bruce_campbell@ripe.net, or to the ietf-whois@imc.org list. Kind regards, - -- Bruce Campbell RIPE NCC I do not speak for my employer Operations -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE78r9l5GBMOVYsixsRAoGoAJ45QzNwqSZdbaxBBfa5aQUJBKSTXQCfVU0C +jHAq4lwDhaMUp8EE47HTXc= =In7t -----END PGP SIGNATURE----- --12654081-1759836202-1005764310=:30058 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="draft-campbell-whois-00.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="draft-campbell-whois-00.txt" TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQnJ1Y2UgQ2FtcGJlbGwNCkludGVybmV0IERyYWZ0ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFJJUEUgTkNDDQpFeHBpcmVzOiBNYXkgMjAwMiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwMQ0KVXBkYXRl czogUkZDOTU0DQoNCg0KICAgICAgICAgICAgICAgVGhlIGJhc2ljIE5JQ05B TUUvV0hPSVMgcHJvdG9jb2wNCiAgICAgICAgICAgICAgICAgZHJhZnQtY2Ft cGJlbGwtd2hvaXMtMDAudHh0DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0K ICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMg aW4gZnVsbA0KICAgY29uZm9ybWFuY2Ugd2l0aCBhbGwgcHJvdmlzaW9ucyBv ZiBTZWN0aW9uIDEwIG9mIFJGQyAyMDI2DQogICBbUkZDMjAyNl0uDQoNCiAg IEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhl IEludGVybmV0DQogICBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwg aXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcNCiAgIGdyb3Vwcy4gIE5vdGUg dGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0KICAgd29y a2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLg0KDQogICBJbnRl cm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtDQogICBvZiBzaXggbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwg cmVwbGFjZWQsIG9yIG9ic29sZXRlZA0KICAgYnkgb3RoZXIgZG9jdW1lbnRz IGF0IGFueSB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0bw0KICAgdXNl IEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8g Y2l0ZQ0KICAgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMg Y2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2ll dGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0IG9mIEludGVy bmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUNCiAgIGFjY2Vz c2VkIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAg IFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQi LCAiU0hBTEwiLCAiU0hBTEwNCiAgIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxE IE5PVCIsICJSRUNPTU1FTkRFRCIsICAiTUFZIiwgYW5kDQogICAiT1BUSU9O QUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkDQog ICBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkuDQoNCkFic3RyYWN0DQoNCiAg IFRoaXMgbWVtbyBkZWZpbmVzIHRoZSBiYXNpYyBXSE9JUyBwcm90b2NvbCBh cyB1c2VkIG9uIA0KICAgdGhlIEludGVybmV0IHRvZGF5LiANCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQ2FtcGJlbGwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSAxIF0NCgwNCmRyYWZ0LWNhbXBiZWxsLXdob2lzLTAwLnR4dCAgICAgV0hP SVMgICAgICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDAxDQoNClRhYmxl IG9mIENvbnRlbnRzDQogICAxLiBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQogICAg ICAxLjEgSGlzdG9yeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAzDQogICAgICAxLjIgQWltcyBvZiB0aGlz IERvY3VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAzDQogICAyLiBSZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQogICAgICAyLjEgQ2xp ZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAzDQogICAgICAyLjIgU2VydmVyIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0DQogICAg ICAgICAyLjIuMSBTZXJ2ZXIgT3BlcmF0b3IgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA0DQogICAgICAyLjMgUmVnaXN0cnkgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA0DQogICAgICAgICAyLjMuMSBEYXRhYmFzZSAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1DQogICAgICAgICAyLjMu MiBVcGRhdGluZyB0aGUgRGF0YWJhc2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA1DQogICAgICAgICAyLjMuMyBOb3JtYWwgVXNhZ2Ugb2Yg RGF0YSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1DQogICAz LiBQcm90b2NvbCBEZWZpbml0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA1DQogICAgICAzLjEgQ29ubmVjdGlvbiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA1DQogICAgICAgICAzLjEuMSBQb3J0ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1DQogICAgICAzLjIgUXVl c3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA2DQogICAgICAgICAzLjIuMSBMYW5ndWFnZSBhbmQgQ2hh cmFjdGVyIFNldC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2DQogICAg ICAgICAzLjIuMiBGbGFncyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA2DQogICAgICAgICAzLjIuMyBRdWVzdGlv biAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA3DQogICAgICAgICAzLjIuNCBRdWFsaWZpZXJzLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3DQogICAgICAgICAzLjIu NSBRdWVzdGlvbiBUZXJtaW5hdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA3DQogICAgICAgICAzLjIuNiBIZWxwICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3DQogICAg ICAzLjMgQW5zd2VyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA4DQogICAgICAgICAzLjMuMSBMYW5ndWFn ZSBhbmQgQ2hhcmFjdGVyIFNldCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA4DQogICAgICAgICAzLjMuMiBPdXRwdXQgRm9ybWF0IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA4DQogICAgICAgICAzLjMu MyBCYW5uZXIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA4DQogICAgICAgICAzLjMuNCBTZWFyY2ggUmVzdWx0IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA4DQogICAg ICAgICAzLjMuNSBXYXJuaW5nIE1lc3NhZ2VzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA5DQogICAgICAgICAzLjMuNiBFcnJvciBN ZXNzYWdlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA5DQogICAgICAgICAzLjMuNyBSZWplY3Rpb24gTWVzc2FnZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA5DQogICAgICAzLjQgVGVy bWluYXRpb24gb2YgQ29ubmVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA5DQogICAgICAgICAzLjQuMSBOb3JtYWwgVGVybWluYXRp b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwDQogICAg ICAgICAzLjQuMiBJbmFjdGl2aXR5IFRpbWVvdXQgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDEwDQogICAgICAgICAzLjQuMyBDb25uZWN0 aW9uIFRpbWVvdXQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDEwDQogICAgICAgICAzLjQuNCBBYnVzZSBvZiBTZXJ2aWNlICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwDQogICAgICAgICAzLjQu NSBPdGhlciBkaXNjb25uZWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDEwDQogICA0LiBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwDQogICAg ICA0LjEgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDEwDQogICAgICAgICA0LjEuMSBJbXBsZW1l bnRvcnMgTm90ZSBvbiBBc3NpZ25lZCBQb3J0ICAuIC4gLiAuIC4gLiAuIC4g IDEwDQogICAgICA0LjIgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExDQogICA1LiBSZWZlcmVu Y2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDExDQogICA2LiBBdXRob3IncyBBZGRyZXNzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExDQogICA3 LiBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDEyDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KQ2FtcGJlbGwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyIF0NCgwNCmRyYWZ0LWNh bXBiZWxsLXdob2lzLTAwLnR4dCAgICAgV0hPSVMgICAgICAgICAgICAgICAg ICAgICBOb3ZlbWJlciAyMDAxDQoNCjEuIEludHJvZHVjdGlvbg0KDQoNCjEu MSBIaXN0b3J5DQoNCiAgIFRoZSBvcmlnaW5hbCByZWZlcmVuY2UgZG9jdW1l bnQgZm9yIFdIT0lTW1JGQzk1NF1dIHNwZWNpZmllcyB0d28gaXRlbXMuDQoN CiAgIFRoZSBmaXJzdCBiZWluZyBhIHNpbXBsZSBzZXJ2ZXI8LT5jbGllbnQg cXVlc3Rpb24gYW5kIGFuc3dlciBwcm90b2NvbA0KICAga25vd24gYXMgJ1dI T0lTJywgcnVubmluZyBvbiBwb3J0IDQzIG9mIGEgZ2l2ZW4gbWFjaGluZS4g IFRoZSBzZWNvbmQNCiAgIGl0ZW0gc3BlY2lmaWVzIGEgbnVtYmVyIG9mIHJl cXVpcmVtZW50cyBmb3IgcGxhY2VtZW50IG9mIGRhdGEgd2l0aGluDQogICB0 aGUgJ1NSSS1OSUMnIGRhdGFiYXNlLiAgDQogICANCiAgIFRoZSBzZWNvbmQg aXRlbSBoYXMgY2F1c2VkIG11Y2ggY29uZnVzaW9uIGFuZCBxdWFzaS1yZWxp Z2lvdXMgZGViYXRlcw0KICAgb3ZlciB0aGUgeWVhcnMsIGVzcGVjaWFsbHkg Z2l2ZW4gdGhhdCB0aGUgJ1NSSS1OSUMnIGRhdGFiYXNlIGhhcyBiZWVuDQog ICBzdXBlcmNlZGVkIHNldmVyYWwgdGltZXMuDQogICANCjEuMiBBaW1zIG9m IHRoaXMgRG9jdW1lbnQNCg0KICAgVGhpcyBkb2N1bWVudCBhaW1zIHRvIHBy b3ZpZGUgYW4gYWNjdXJhdGUgZGVmaW5pdGlvbiBvZiB0aGUgYmFzaWMgV0hP SVMNCiAgIHByb3RvY29sIHVzZWQgb24gdGhlIEludGVybmV0IHRvZGF5LiAg SXQgaW5jbHVkZXMgb2JzZXJ2ZWQgdmFyaWF0aW9ucw0KICAgb24gcG9zc2li bGUgcXVlcmllcyBhbmQgYW5zd2Vycy4NCg0KICAgVGhpcyBkb2N1bWVudCBk b2VzIE5PVCBwcm92aWRlIGRlZmluaXRpb25zIG9mIHRoZSBwb3NzaWJseSBz ZW5zaXRpdmUNCiAgIHN1YmplY3RzIGFzIGZvbGxvd3M6DQoNCiAgICAgICAg IERhdGEgdGhhdCBtdXN0IGJlIHJlZ2lzdGVyZWQgaW4gYW55IERhdGFiYXNl DQogICAgICAgICBEYXRhIHRoYXQgbXVzdCBiZSBwcm90ZWN0ZWQgYnkgUHJp dmFjeSBDb25jZXJucw0KICAgICAgICAgT3V0cHV0IEZvcm1hdCBvZiBEYXRh DQogICAgICAgICBRdWVzdGlvbiBGb3JtYXQgKGJleW9uZCBhIHJlcXVpcmVt ZW50IGZvciAnaGVscCcpDQoNCiAgIFRoZSBhYm92ZSBkZWZpbml0aW9ucyBh cmUgZGVmaW5lZCBieSB0aGUgUmVnaXN0cnkgb3BlcmF0aW5nIGENCiAgIHBh cnRpY3VsYXIgRGF0YWJhc2UsIGFuZCB0aGUgTGF3cyBvZiB0aGF0IFJlZ2lz dHJ5J3MgQ291bnRyeS4NCg0KMi4gUmVxdWlyZW1lbnRzDQoNCjIuMSBDbGll bnQNCg0KICAgVGhlICdXSE9JUycgQ2xpZW50IE1VU1QgYmUgYWJsZSB0byBo YW5kbGUgdGhlICdXSE9JUycgU2VydmVyIGJlaW5nDQogICB1bmF2YWlsYWJs ZSwgb3IgZm9yIHRoZSBjb25uZWN0aW9uIHRvIGJlIGNsb3NlZCBhdCBhbnkg dGltZSBkdXJpbmcNCiAgIHRoZSB0cmFuc2FjdGlvbi4gIFRoZSB1c2VyIG9m IHRoZSBjbGllbnQgTVVTVCBiZSBhYmxlIHRvIHNwZWNpZnkNCiAgIGFsdGVy bmF0aXZlICdXSE9JUycgU2VydmVycyBhbmQgYWx0ZXJuYXRpdmUgcG9ydHMs IGFuZCBzdXBwb3J0IG9mIA0KICAgdGhlc2UgY2FwYWJpbGl0aWVzIFNIT1VM RCBiZSBtYWRlIGNsZWFybHkga25vd24gdG8gdGhlIHVzZXIuDQoNCiAgIFRo ZSAnV0hPSVMnIENsaWVudCBTSE9VTEQgdXNlIHRoZSBkZWZhdWx0ICdXSE9J UycgZGVzdGluYXRpb24gcG9ydCANCiAgIG9mICc0MycgW1NURDJdIHdoZW4g Y29ubmVjdGluZyB0byBhIGdpdmVuICdXSE9JUycgc2VydmVyLCB1bmxlc3Mg YW4NCiAgIGFsdGVybmF0aXZlIHBvcnQgaGFzIGJlZW4gc3BlY2lmaWVkIGJ5 IHRoZSBVc2VyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpDYW1wYmVsbCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFtQYWdlIDMgXQ0KDA0KZHJhZnQtY2FtcGJlbGwtd2hvaXMtMDAudHh0 ICAgICBXSE9JUyAgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDEN Cg0KMi4yIFNlcnZlcg0KDQogICBUaGUgJ1dIT0lTJyBTZXJ2ZXIgTVVTVCBi ZSBhYmxlIHRvIGhhbmRsZSBhICdyZWFzb25hYmxlJyBudW1iZXIgb2YNCiAg IHNpbXVsdGFuZW91cyAnV0hPSVMnIENsaWVudHMgY29ubmVjdGluZyB0byBp dC4gIEl0IE1VU1QgYmUgYWJsZSB0bw0KICAgaGFuZGxlIGFueSBvZiB0aGVz ZSBjb25uZWN0aW9ucyBiZWluZyBjbG9zZWQgYXQgYW55IHRpbWUgZHVyaW5n IHRoZQ0KICAgdHJhbnNhY3Rpb24uICBJdCBTSE9VTEQgYmUgYWJsZSB0byBp c3N1ZSBhbiBhcHByb3ByaWF0ZSBtZXNzYWdlIHRvDQogICBlYWNoIGNvbm5l Y3RpbmcgY2xpZW50IGlmIHRoZSBudW1iZXIgc2ltdWx0YW5lb3VzIGNsaWVu dHMgZXhjZWVkcyANCiAgIGl0J3MgJ3JlYXNvbmFibGUnIGxpbWl0cy4NCg0K ICAgQXQgdGhlIHRpbWUgb2Ygd3JpdGluZywgdGhlIFJJUEUgTkNDICdXSE9J Uycgc2VydmVyIHdhcyBzZWVpbmcNCiAgIHJlZ3VsYXIgc3Bpa2VzIG9mIDMz IHF1ZXJpZXMgcGVyIHNlY29uZCBbTkNDLURCLU9QXS4NCg0KICAgQSBwdWJs aWMgJ1dIT0lTJyBTZXJ2ZXIgU0hPVUxEIGhhdmUgYXMgb25lIG9mIGl0cyBh bGlhc2VzLCBhIGhvc3RuYW1lDQogICBvZiAnd2hvaXMnLCBlZyAnd2hvaXMu ZXhhbXBsZS5jb20nLiAgU3VjaCBhIFNlcnZlciBNVVNUIHJlc3BvbmQgb24g dGhlIA0KICAgY29tbW9uICdXSE9JUycgcG9ydCBvZiAnNDMnLiBbU1REMl0N Cg0KDQoyLjIuMSBTZXJ2ZXIgT3BlcmF0b3INCg0KICAgVGhlIEVudGl0eSBv ciBFbnRpdGllcyBpbiBjaGFyZ2Ugb2YgYSBnaXZlbiAnV0hPSVMnIFNlcnZl ciB3aG8gaXMvYXJlDQogICByZXNwb25zaWJsZSBmb3IgdGhlIGJlaGF2aW91 ciBhbmQgb3BlcmF0aW9uIG9mIGEgZ2l2ZW4gU2VydmVyLiAgVGhlIA0KICAg U2VydmVyIE9wZXJhdG9yIE1VU1QgcmVwb3J0IHVzYWdlLCBwcm9ibGVtcyAo ZXRjKSB3aXRoIHRoZSAnV0hPSVMnIA0KICAgU2VydmVyIHRvIHRoZSBSZWdp c3RyeSByZXNwb25zaWJsZSBmb3IgdGhlIERhdGFiYXNlLiAgVGhpcyBpbXBs aWVzDQogICB0aGF0IHRoZSBTZXJ2ZXIgTVVTVCBsb2cgdXNhZ2Ugb2YgdGhl IFNlcnZlciBpbiBzb21lIGZhc2hpb24uDQoNCiAgIFRoZSBTZXJ2ZXIgT3Bl cmF0b3IsIGluIGFkZGl0aW9uIHRvIGFiaWRpbmcgYnkgYW55IHJlc3RyaWN0 aW9ucyBzZXQNCiAgIGJ5IHRoZSBSZWdpc3RyeSwgbWF5IGFkZCBleHRyYSBy ZXN0cmljdGlvbnMgdG8gdGhlIHVzZSBvZiB0aGUgU2VydmVyLA0KICAgcG9z c2libHkgZHluYW1pY2FsbHkgaW4gcmVzcG9uc2UgdG8gQ2xpZW50IGJlaGF2 aW91ci4NCg0KMi4zIFJlZ2lzdHJ5DQoNCiAgIFRoZSBFbnRpdHkgb3IgRW50 aXRpZXMgaW4gY2hhcmdlIG9mIGEgZ2l2ZW4gRGF0YWJhc2Ugd2hpY2ggaXMN CiAgIGFjY2Vzc2libGUgdmlhIGEgZ2l2ZW4gJ1dIT0lTJyBEYXRhYmFzZS4g IE5vcm1hbGx5LCB0aGUgU2VydmVyIA0KICAgT3BlcmF0b3IocykgYW5kIHRo ZSBSZWdpc3RyeSBhcmUgdGhlIHNhbWUgRW50aXRpZXMsIGhvd2V2ZXIgYQ0K ICAgZGlzdGluY3Rpb24gbXVzdCBiZSBtYWRlIGJldHdlZW4gdGhlIHR3byB0 byByZWZsZWN0IG9wZXJhdGlvbmFsDQogICBwcmFjdGljZS4NCg0KICAgV2hl cmUgdGhlIFJlZ2lzdHJ5IGlzIHRoZSBjdXN0b2RpYW4gb2YgRGF0YSBjb3Zl cmVkIGJ5IFByaXZhY3kNCiAgIFJlc3RyaWN0aW9ucywgdGhlIFJlZ2lzdHJ5 IE1VU1QgZW5mb3JjZSB0aGVzZSByZXN0cmljdGlvbnMuDQoNCiAgIFRoZSBS ZWdpc3RyeSBNQVkgYWxzbyBhZGQgZXh0cmEgcmVzdHJpY3Rpb25zIHRvIHRo ZSB1c2Ugb2YgaXQncw0KICAgRGF0YS9EYXRhYmFzZS4NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpDYW1wYmVsbCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDQgXQ0K DA0KZHJhZnQtY2FtcGJlbGwtd2hvaXMtMDAudHh0ICAgICBXSE9JUyAgICAg ICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDENCg0KMi4zLjEgRGF0YWJh c2UNCg0KICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBzcGVjaWZ5IHRoZSBi YWNrLWVuZCBkYXRhYmFzZSB0aGF0IGlzIHRvIGJlDQogICB1c2VkIGJ5IHRo ZSBSZWdpc3RyeSwgb3IgdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBTZXJ2 ZXIgYW5kDQogICBEYXRhYmFzZSAod2hpY2ggbWF5IGFsc28gYnkgdmlhICdX SE9JUycpLg0KICAgDQogICBWYXJpb3VzIGRhdGFiYXNlcyBoYXZlIGJlZW4g dXNlZCBvdmVyIHRpbWUsIHJhbmdpbmcgZnJvbSBmbGF0DQogICBmaWxlLCB0 byBoaWdoIHBlcmZvcm1hbmNlIFNRTCBzZXJ2ZXJzLiAgSXQgaXMgbGVmdCB1 cCB0byB0aGUNCiAgIGltcGxlbWVudG9yIHRvIGNob29zZSBhbiBhcHByb3By aWF0ZSBiYWNrLWVuZCBkYXRhYmFzZSwgYW5kIHRoZQ0KICAgcmVwbGljYXRp b24gb2YgdGhlIERhdGFiYXNlIHRvIHRoZSBXSE9JUyBTZXJ2ZXIocykgc2Vy dmluZyB0aGF0DQogICBEYXRhYmFzZS4NCg0KICAgVGhlIERhdGFiYXNlIG1h eSBiZSBhY2Nlc3NlZCBieSBtZXRob2RzIG90aGVyIG9yIGluIGFkZGl0aW9u IHRvDQogICBXSE9JUy4NCg0KMi4zLjIgVXBkYXRpbmcgdGhlIERhdGFiYXNl DQoNCiAgIFRoZSBwcm9jZWR1cmUgZm9yIHVwZGF0aW5nIHRoZSBEYXRhYmFz ZSBpcyBkZWZpbmVkIGJ5IHRoZSBSZWdpc3RyeS4NCg0KICAgVGhlIFJlZ2lz dHJ5IG1heSByZXF1aXJlIGNlcnRhaW4gaW5mb3JtYXRpb24gcmVxdWlyZWQg Zm9yIHRoZQ0KICAgUmVnaXN0cnkncyBPcGVyYXRpb24gdG8gYmUgcmVnaXN0 ZXJlZCB3aXRoaW4gaXQncyBEYXRhYmFzZS4NCg0KICAgVGhlIFJlZ2lzdHJ5 IFNIT1VMRCBOT1QgaW1wb3NlIGEgZmVlIGZvciByZXF1aXJlZCBpbmZvcm1h dGlvbiB0byBiZQ0KICAgcmVnaXN0ZXJlZCB3aXRoaW4gaXQncyBkYXRhYmFz ZSwgYnV0IE1BWSBpbXBvc2UgYSBmZWUgZm9yIG90aGVyDQogICBzZXJ2aWNl cyBvZmZlcmVkIGJ5IHRoZSBSZWdpc3RyeS4NCg0KMi4zLjMgTm9ybWFsIFVz YWdlIG9mIERhdGENCg0KICAgVGhlIGV4YWN0IHVzYWdlIG9mIHRoZSBEYXRh IHdpdGhpbiBhIERhdGFiYXNlIGlzIGxlZnQgZm9yIHRoZQ0KICAgUmVnaXN0 cnkgdG8gZGVmaW5lLCBob3dldmVyIERhdGEgb2J0YWluZWQgdmlhIFdIT0lT IGhhcyBoaXN0b3JpY2FsbHkNCiAgIGJlZW4gZm9yIEludGVybmV0IE9wZXJh dGlvbmFsIFB1cnBvc2VzLiAgVXNlcnMgc2hvdWxkIHJlZmVyIHRvIHRoZQ0K ICAgdXNhZ2UgY29uZGl0aW9ucyBpbXBvc2VkIGJ5IGEgZ2l2ZW4gUmVnaXN0 cnkuDQoNCjMuIFByb3RvY29sIERlZmluaXRpb25zDQoNCiAgIEF0IGl0J3Mg aGVhcnQsICdXSE9JUycgaXMgYSB2ZXJ5IHNpbXBsZSBmb3JtYXQuICBIb3dl dmVyLCBtYW55DQogICBleHBlY3RhdGlvbnMgaGF2ZSBiZWVuIHBsYWNlZCBv biAnV0hPSVMnIHNpbmNlIGl0IHdhcyBmaXJzdA0KICAgaW50cm9kdWNlZC4g IFRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbnMgY292ZXIgYWxsIGtub3duIGlu c3RhbGxlZA0KICAgdmFyaWVudHMuDQoNCjMuMSBDb25uZWN0aW9uDQoNCiAg IFRoZSBjb25uZWN0aW9uIGlzIGFsd2F5cyBpbml0aWF0ZWQgZnJvbSB0aGUg Q2xpZW50IGVuZCwgdG8gdGhlDQogICBub21pbmF0ZWQgJ1dIT0lTJyBTZXJ2 ZXIuDQoNCjMuMS4xICAgUG9ydA0KDQogICBQb3J0IDQzIGhhcyBiZWVuIHNl dCBhc2lkZSBmb3IgJ1dIT0lTJy4gIFBsZWFzZSByZWZlciB0byA0LjEsIElB TkENCiAgIENvbnNpZGVyYXRpb25zIGFuZCA0LjEuMSwgSW1wbGVtZW50b3Jz IE5vdGUgb24gQXNzaWduZWQgUG9ydHMuICBUQ1ANCiAgIGlzIGFzc3VtZWQu DQoNCg0KDQoNCg0KDQpDYW1wYmVsbCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDUgXQ0KDA0K ZHJhZnQtY2FtcGJlbGwtd2hvaXMtMDAudHh0ICAgICBXSE9JUyAgICAgICAg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDENCg0KMy4yIFF1ZXN0aW9uDQoN CiAgIE9uIGNvbm5lY3RpbmcgdG8gYSAnV0hPSVMnIFNlcnZlciwgdGhlIENs aWVudCBNVVNUIGFzayBhICdRdWVzdGlvbicuDQogICBUaGUgQ2xpZW50IE1V U1QgYmUgYWJsZSB0byBoYW5kbGUgdGV4dCBiZWluZyBzZW50IHRvIHRoZSBD bGllbnQgZnJvbQ0KICAgdGhlIFNlcnZlciBiZWZvcmUgdGhlIFF1ZXN0aW9u IGlzIHN0YXJ0ZWQgb3IgY29tcGxldGVkLCBvciB0aGUNCiAgIGNvbm5lY3Rp b24gYmVpbmcgY2xvc2VkIGZvciBhbnkgcmVhc29uLg0KDQogICBBIFF1ZXN0 aW9uIGlzIGRlZmluZWQgYXMgaGF2aW5nIHRoZSBmb2xsb3dpbmcgY29tcG9u ZW50czoNCg0KICAgICAgPHdoaXRlc3BhY2U+IDxmbGFncz4gPHdoaXRlc3Bh Y2U+IDxxdWVzdGlvbj4gPHdoaXRlc3BhY2U+DQogICAgICA8cXVhbGlmaWVy cz4gPHdoaXRlc3BhY2U+IDxDUi9MRj4NCg0KICAgV2hlcmUgPHdoaXRlc3Bh Y2U+IGlzIG9wdGlvbmFsLCA8ZmxhZ3M+IGlzIG9wdGlvbmFsLCA8cXVlc3Rp b24+IGlzDQogICByZXF1aXJlZCwgYW5kIDxxdWFsaWZpZXJzPiBpcyBvcHRp b25hbC4NCg0KMy4yLjEgTGFuZ3VhZ2UgYW5kIENoYXJhY3RlciBTZXQNCg0K ICAgVGhlICdXSE9JUycgU2VydmVyIG9wZXJhdG9yIE1BWSBub21pbmF0ZSBh IExhbmd1YWdlIGFuZCBDaGFyYWN0ZXIgU2V0DQogICB0byBiZSB1c2VkIGZv ciBhbnkgcGFydCBvZiB0aGUgJ1F1ZXN0aW9uJy4gIElmIGEgTGFuZ3VhZ2Ug b3INCiAgIENoYXJhY3RlciBTZXQgb3RoZXIgdGhhbiAnRW5nbGlzaCcgYW5k ICdVUy1BU0NJSScgaXMgZXhwZWN0ZWQgZnJvbQ0KICAgdGhlIENsaWVudCwg dGhlIFNlcnZlciBNQVkgcHJvdmlkZSBhbiBpbml0aWFsIGJhbm5lciBtZXNz YWdlIGJlZm9yZQ0KICAgdGhlIFF1ZXN0aW9uIGlzIGFza2VkLCBzcGVjaWZ5 aW5nIHRoZSBMYW5ndWFnZSBhbmQgQ2hhcmFjdGVyIHNldCBpbg0KICAgdXNl LiBbQkNQMThdDQoNCjMuMi4yIEZsYWdzDQoNCiAgIFRoaXMgc2VjdGlvbiBv ZiB0aGUgJ1F1ZXN0aW9uJyBpcyBPUFRJT05BTC4NCg0KICAgVGhlICdXSE9J UycgU2VydmVyIE1VU1QgYWNjZXB0IGFueSBjaGFyYWN0ZXIgc2VxdWVuY2Vz IHRoYXQgdGhlDQogICBTZXJ2ZXIgT3BlcmF0b3IgaGFzIGRlZmluZWQgdG8g YmUgdmFsaWQgZmxhZ3MgZm9yIHRoZSBTZXJ2ZXIuICBUaGUNCiAgIFNlcnZl ciBNVVNUIHJlc3BvbmQgdG8gYW55IGludmFsaWQgZmxhZ3Mgd2l0aCBhbiBh cHByb3ByaWF0ZSBlcnJvcg0KICAgbWVzc2FnZSwgYW5kIGFuIGluZGljYXRv ciBvbiB3aGVyZSB0byBnZXQgYXV0b21hdGVkIGFzc2lzdGFuY2Ugb24gdGhl DQogICB2YWxpZCBmbGFncyBmb3IgdGhlIFNlcnZlci4gIA0KICAgDQogICBG bGFncywgaWYgcHJvdmlkZWQsIFNIT1VMRCBiZSBzZXBlcmF0ZWQgZnJvbSB0 aGUgcXVlc3Rpb24gc2VjdGlvbiBieSANCiAgIGF0IGxlYXN0IG9uZSAnd2hp dGVzcGFjZScgY2hhcmFjdGVyLCB1bmxlc3MgYSBnaXZlbiBmbGFnIG1ha2Vz IHRoaXMgDQogICBvcHRpb25hbC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KQ2FtcGJlbGwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA2IF0NCgwN CmRyYWZ0LWNhbXBiZWxsLXdob2lzLTAwLnR4dCAgICAgV0hPSVMgICAgICAg ICAgICAgICAgICAgICBOb3ZlbWJlciAyMDAxDQoNCjMuMi4zIFF1ZXN0aW9u DQoNCiAgIFRoaXMgc2VjdGlvbiBvZiB0aGUgJ1F1ZXN0aW9uJyBpcyBSRVFV SVJFRC4NCg0KICAgVGhlICdXSE9JUycgU2VydmVyIE1VU1QgYWNjZXB0IGFu eSBjaGFyYWN0ZXIgc2VxdWVuY2VzIHRoYXQgdGhlDQogICBTZXJ2ZXIgT3Bl cmF0b3IgaGFzIGRlZmluZWQgdG8gYmUgdmFsaWQgY2hhcmFjdGVycyBmb3Ig dGhlIFNlcnZlci4NCg0KICAgVGhlIHF1ZXN0aW9uIFNIT1VMRCBjb25zaXN0 IG9mIHByaW50YWJsZSBjaGFyYWN0ZXJzIGZvciB0aGUgQ2hhcmFjdGVyIA0K ICAgU2V0IHRoYXQgdGhlIFNlcnZlciBPcGVyYXRvciBoYXMgbm9taW5hdGVk IChkZWZhdWx0aW5nIHRvICdVUy1BU0NJSSkuICANCiAgIENoYXJhY3RlcnMg b3V0c2lkZSB0aGUgbm9taW5hdGVkIENoYXJhY3RlciBTZXQgTUFZIGJlIHRy ZWF0ZWQgYnkgdGhlDQogICBTZXJ2ZXIgYXMgYW4gZXJyb3IsIG9yIG90aGVy d2lzZSBpZ25vcmVkLiAgDQoNCiAgIFRoZSBxdWVzdGlvbiBTSE9VTEQgY29u c2lzdCBvZiBhIHN0cmluZyB3aGljaCB0aGUgU2VydmVyIFNIT1VMRCB0aGVu DQogICB1c2UgYXMgYSBrZXkgZm9yIHJldHJpZXZpbmcgdGhlIGFwcHJvcHJp YXRlIGRhdGEuDQoNCiAgIFF1ZXN0aW9ucyBtYXkgYmUgZG9tYWluIG5hbWVz LCBJUCBudW1iZXJzLCBQZXJzb24gUmVjb3JkcyBvciBvdGhlcg0KICAgaW5m b3JtYXRpb24gd2hpY2ggaXMga25vd24gdG8gYmUgd2l0aGluIHRoZSAnV0hP SVMnIERhdGFiYXNlLCBlZzoNCg0KICAgICAgZXhhbXBsZS5jb20NCiAgICAg IDE5My4wLjAuMTkzDQogICAgICBCQzk5OS1SSVBFDQoNCiAgIFRoZSBTZXJ2 ZXIgTVVTVCByZXR1cm4gYW4gYXBwcm9wcmlhdGUgbWVzc2FnZSBpZiB0aGUg aW5kaWNhdGVkIGtleSBpcyBub3QNCiAgIGZvdW5kLCBvciBpZiB0aGUgRGF0 YWJhc2UgaXMgb3RoZXJ3aXNlIHVuYXZhaWxhYmxlLg0KDQozLjIuNCBRdWFs aWZpZXJzDQoNCiAgIFRoaXMgc2VjdGlvbiBvZiB0aGUgJ1F1ZXN0aW9uJyBp cyBPUFRJT05BTC4NCg0KICAgVGhlICdXSE9JUycgU2VydmVyIE9wZXJhdG9y IE1BWSBkZWZpbmUgYWRkaXRpb25hbCBxdWFsaWZpZXJzIHRvDQogICBlbmFi bGUgdGhlIENsaWVudCB0byBjb250cm9sIHRoZSBvdXRwdXQgZnJvbSB0aGUg J1dIT0lTJyBTZXJ2ZXIuICBUaGUNCiAgIFNlcnZlciBNVVNUIGFjY2VwdCBh bnkgdmFsaWQgc2VxdWVuY2VzLCBhbmQgTUFZIHRyZWF0IGludmFsaWQNCiAg IHNlcXVlbmNlcyBhcyBhbiBlcnJvci4NCg0KICAgQSBzdWdnZXN0ZWQgdXNl IGZvciBhbiBhZGRpdGlvbmFsIHF1YWxpZmllciB0byBmb3IgdGhlIENsaWVu dCB0bw0KICAgc3BlY2lmeSB0aGUgb3V0cHV0IExhbmd1YWdlLiBbSlBOSUNd DQoNCjMuMi41IFF1ZXN0aW9uIFRlcm1pbmF0aW9uDQoNCiAgIEEgJ1F1ZXN0 aW9uJyBtdXN0IGJlIHRlcm1pbmF0ZWQgYnkgdGhlIENsaWVudCBieSB0aGUg J0NSL0xGJw0KICAgY2hhcmFjdGVyIGNvbWJpbmF0aW9uLg0KDQozLjIuNiBI ZWxwDQoNCiAgIFRoZSBDbGllbnQgTUFZIGFzayBmb3IgYXNzaXN0YW5jZSBv biB1c2luZyB0aGUgJ1dIT0lTJyBTZXJ2ZXIuICBUaGUNCiAgIFNlcnZlciBt dXN0IGlnbm9yZSBhbnkgb3RoZXIgcGFydHMgb2YgdGhlIFF1ZXN0aW9uIGFu ZCByZXNwb25kIHdpdGgNCiAgIGFuIGFwcHJvcHJpYXRlICdIZWxwJyBtZXNz YWdlLCBvciBhIFVSTCB0byB0aGUgVXNhZ2UgZ3VpZGUgb2YgdGhlDQogICAn V0hPSVMnIFNlcnZlci4NCg0KICAgVGhlIFNlcnZlciBNVVNUIGFjY2VwdCB0 aGUgbGl0ZXJhbCBzdHJpbmcgJ2hlbHAnIGluIHRoZSBVUy1BU0NJSQ0KICAg Q2hhcmFjdGVyIFNldCBhcyBhbiBpbmRpY2F0b3IgZm9yIHRoZSBhYm92ZSBi ZWhhdmlvdXIuICBUaGUgU2VydmVyDQogICBTSE9VTEQgYWxzbyBhY2NlcHQg dmFyaWF0aW9ucyBvbiAnaGVscCcgaW4gdGhlIExhbmd1YWdlIGFuZCBDaGFy YWN0ZXINCiAgIFNldCB1c2VkIGJ5IHRoZSAnV0hPSVMnIFNlcnZlci4NCg0K DQoNCkNhbXBiZWxsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNyBdDQoMDQpkcmFmdC1jYW1w YmVsbC13aG9pcy0wMC50eHQgICAgIFdIT0lTICAgICAgICAgICAgICAgICAg ICAgTm92ZW1iZXIgMjAwMQ0KDQozLjMgQW5zd2VyDQoNCiAgIEFmdGVyIHRo ZSBDbGllbnQgaGFzIGZpbmlzaGVkIGFza2luZyB0aGUgJ1F1ZXN0aW9uJyB3 aXRoIHRoZSBDUi9MRiwNCiAgIHRoZSBTZXJ2ZXIgTVVTVCBzdXBwbHkgYW4g QW5zd2VyLiAgV2hlcmUgdGhlIEFuc3dlciBjb250YWlucyBtb3JlDQogICB0 aGFuIG9uZSBvZiB0aGUgaXRlbXMgbGlzdGVkIGJlbG93LCBlYWNoIHNlY3Rp b24gU0hPVUxEIGJlIHNlcGVyYXRlZA0KICAgZnJvbSB0aGUgbmV4dCBieSBh IGJsYW5rIGxpbmUuDQoNCjMuMy4xIExhbmd1YWdlIGFuZCBDaGFyYWN0ZXIg U2V0DQoNCiAgIFRoZSBTZXJ2ZXIgTVVTVCByZXBseSBpbiB0aGUgTGFuZ3Vh Z2UgYW5kIENoYXJhY3RlciBTZXQgbm9taW5hdGVkIGJ5DQogICB0aGUgU2Vy dmVyIE9wZXJhdG9yLCBvciB0aGUgTGFuZ3VhZ2Ugb3IgQ2hhcmFjdGVyIFNl dCByZXF1ZXN0ZWQgYnkNCiAgIHRoZSBDbGllbnQgYnkgUXVlc3Rpb24gRmxh Z3Mgb3IgUXVhbGlmaWVycywgb3IgaW4gRW5nbGlzaC9VUy1BU0NJSSBpZg0K ICAgdGhlIGxpdGVyYWwgc3RyaW5nICdoZWxwJyBpbiBVUy1BU0NJSSB3YXMg c3VwcGxpZWQgYXMgdGhlIFF1ZXN0aW9uLg0KDQozLjMuMiBPdXRwdXQgRm9y bWF0DQoNCiAgIFRoZSBTZXJ2ZXIgTVVTVCByZXBseSBhY2NvcmRpbmcgdG8g dGhlIG91dHB1dCBmb3JtYXQgZGVmaW5lZCBieSB0aGUNCiAgIFNlcnZlciBP cGVyYXRvci4gIEEgbWV0aG9kIG9mIG9idGFpbmluZyB0aGUgc3BlY2lmaWNh dGlvbnMgb2YgdGhlDQogICBvdXRwdXQgZm9ybWF0IE1VU1QgYmUgb2J0YWlu YWJsZSB2aWEgdGhlIFNlcnZlcidzICdoZWxwJyBpbmZvcm1hdGlvbi4NCg0K My4zLjMgQmFubmVyDQoNCiAgIFRoZSBTZXJ2ZXIgTUFZIHN1cHBseSBhIEJh bm5lciBNZXNzYWdlIGF0IHRocmVlIHBvaW50cyBkdXJpbmcgdGhlDQogICBj b25uZWN0aW9uOg0KDQogICAgICBJbW1lZGlhdGVseSBhZnRlciBpbml0aWFs IGNvbm5lY3Rpb24sDQoNCiAgICAgIEltbWVkaWF0ZWx5IGFmdGVyIHRoZSB0 ZXJtaW5hdGlvbiBvZiB0aGUgUXVlc3Rpb24gYnkgdGhlIENsaWVudA0KICAg ICAgYW5kIGJlZm9yZSB0aGUgb3V0cHV0IG9mIHRoZSBBbnN3ZXIuDQoNCiAg ICAgIEltbWVkaWF0ZWx5IGFmdGVyIHRoZSBvdXRwdXQgb2YgdGhlIEFuc3dl ci4NCg0KICAgVG8gYXNzaXN0IHJlYWRhYmlsaXR5LCB0aGUgQmFubmVyIE1l c3NhZ2UgU0hPVUxEIE5PVCBleGNlZWQgYSBwb2xpdGUNCiAgIDQgbGluZXMu DQoNCiAgIFRoZSBDbGllbnQgTVVTVCBkaXNwbGF5IGFueSBCYW5uZXIgTWVz c2FnZSB0byB0aGUgVXNlciB3aXRob3V0DQogICBhbHRlcmF0aW9uLg0KDQog ICBUaGUgdXN1YWwgcHVycG9zZSBvZiBhIEJhbm5lciBNZXNzYWdlIGlzIHRv IHN1cHBseSB0byB0aGUgQ2xpZW50IGFueQ0KICAgQ29weXJpZ2h0cyB0aGF0 IG1heSBiZSBvbiB0aGUgZGF0YSBzdXBwbGllZCBieSB0aGUgU2VydmVyLCBv ciBhIFVSTA0KICAgdG8gdGhlIGZ1bGwgQ29weXJpZ2h0IGluZm9ybWF0aW9u Lg0KDQozLjMuNCBTZWFyY2ggUmVzdWx0DQoNCiAgIFRoZSBTZXJ2ZXIgTVVT VCBzdXBwbHkgdGhlIHJlc3VsdHMgb2YgYSB2YWxpZCBxdWVzdGlvbiwgd2hl cmUgdGhhdA0KICAgZGF0YSBpcyB3aXRoaW4gaXRzIGRhdGFiYXNlIGFuZCBy ZXN0cmljdGlvbnMgb24gcHVibGljYXRpb25zIG9mIHRoYXQgDQogICBkYXRh IGhhdmUgYmVlbiBvYnNlcnZlZC4gIFdoZXJlIG11bHRpcGxlIGRhdGEgcmVj b3JkcyBhcmUgbWF0Y2hlZCBieSANCiAgIHRoZSBxdWVzdGlvbiwgdGhlIFNl cnZlciBNQVkgc3VwcGx5IGEgc3VtbWFyeSwgT1IgYWxsIG9mIHRoZSBtYXRj aGVkIA0KICAgcmVjb3JkcyB3aGVyZSBhcHByb3ByaWF0ZSBvciByZXF1ZXN0 ZWQgYnkgb3B0aW9uYWwgZmxhZ3Mgb3INCiAgIHF1YWxpZmllcnMuDQoNCiAg IEEgZ2l2ZW4gcmVzdWx0IG1heSByZWZlciB0byBvdGhlciByZWNvcmRzLCB3 aGljaCB0aGUgU2VydmVyIE1BWSBhbHNvDQogICBzdXBwbHkgaW4gdGhlIEFu c3dlci4gIE11bHRpcGxlIFJlc3VsdHMgU0hPVUxEIGJlIHNlcGVyYXRlZCBm cm9tIG9uZQ0KICAgYW5vdGhlciBieSBhIGJsYW5rIGxpbmUuDQoNCg0KQ2Ft cGJlbGwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSA4IF0NCgwNCmRyYWZ0LWNhbXBiZWxsLXdo b2lzLTAwLnR4dCAgICAgV0hPSVMgICAgICAgICAgICAgICAgICAgICBOb3Zl bWJlciAyMDAxDQoNCjMuMy41IFdhcm5pbmcgTWVzc2FnZXMNCg0KICAgVGhl IFNlcnZlciBNQVkgc3VwcGx5IFdhcm5pbmcgTWVzc2FnZXMgd2hlcmUgcGFy dCBvciBhbGwgb2YgdGhlDQogICBRdWVzdGlvbiBpcyBpbmFwcHJvcHJpYXRl IGFzIGRlZmluZWQgYnkgdGhlIFNlcnZlciBPcGVyYXRvci4gIA0KICAgV2Fy bmluZyBNZXNzYWdlcyBzaG91bGQgc3VwcGx5IGFjY3VyYXRlIGFuZCB1cCB0 byBkYXRlIGluZm9ybWF0aW9uIA0KICAgYWJvdXQgdGhlIHBlcmNlaXZlZCBw cm9ibGVtIHdpdGggdGhlIFF1ZXN0aW9uLCBDb25uZWN0aW9uIG9yIENsaWVu dC4NCg0KICAgQSBXYXJuaW5nIE1lc3NhZ2UgU0hPVUxEIE5PVCBwcm9oaWJp dCB0aGUgb3V0cHV0IG9mIGFueSByZXN1bHRzIGZvcg0KICAgdGhlIFF1ZXN0 aW9uLg0KDQozLjMuNiBFcnJvciBNZXNzYWdlcw0KDQogICBUaGUgU2VydmVy IE1BWSBzdXBwbHkgRXJyb3IgTWVzc2FnZXMgd2hlcmUgcGFydCBvciBhbGwg b2YgdGhlIFF1ZXN0aW9uDQogICBpcyBpbmFwcHJvcHJpYXRlIGFzIGRlZmlu ZWQgYnkgdGhlIFNlcnZlciBPcGVyYXRvci4gIEVycm9yIE1lc3NhZ2VzDQog ICBzaG91bGQgc3VwcGx5IGFjY3VyYXRlIGFuZCB1cCB0byBkYXRlIGluZm9y bWF0aW9uIGFib3V0IHRoZSBwZXJjZWl2ZWQgDQogICBwcm9ibGVtIHdpdGgg dGhlIFF1ZXN0aW9uLCBDb25uZWN0aW9uIG9yIENsaWVudC4NCg0KICAgQW4g RXJyb3IgTWVzc2FnZSBTSE9VTEQgcHJvaGliaXQgdGhlIG91dHB1dCBvZiBh bnkgcmVzdWx0cyBmb3IgdGhlDQogICBRdWVzdGlvbi4NCg0KMy4zLjcgUmVq ZWN0aW9uIE1lc3NhZ2VzDQoNCiAgIFRoZXNlIGFyZSBhIHNwZWNpYWwgZm9y bSBvZiBFcnJvciBNZXNzYWdlIGZvciAncHJvYmxlbScgQ2xpZW50cy4NCiAg IFRoZXkgc2hvdWxkIGNsZWFybHkgc3RhdGUgd2h5IGEgZ2l2ZW4gUXVlc3Rp b24sIENvbm5lY3Rpb24gb3IgQ2xpZW50DQogICBoYXMgYmVlbiByZWplY3Rl ZC4NCg0KICAgVW5sZXNzIGEgZ2l2ZW4gQ2xpZW50IGlzIGNhdXNpbmcgcHJv YmxlbXMgd2l0aCB0aGUgb3BlcmF0aW9uIG9mIHRoZQ0KICAgU2VydmVyIGJ5 IGluYXBwcm9wcmlhdGUgdXNhZ2Ugb2YgdGhlIFNlcnZlciAoYXMgZGVmaW5l ZCBieSB0aGUgU2VydmVyDQogICBPcGVyYXRvciksIHRoZSBTZXJ2ZXIgTVVT VCBhbHdheXMgYWNjZXB0IGEgQ29ubmVjdGlvbiBhdHRlbXB0IGZyb20gdGhl DQogICBnaXZlbiBDbGllbnQuICANCg0KICAgUG9zc2libHkgaW5hcHByb3By aWF0ZSB1c2FnZSBvZiBhIFNlcnZlciBvciBEYXRhYmFzZSBieSBhIENsaWVu dCBtYXkgDQogICBjb25zaXN0IG9mIG9uZSBvciBtb3JlIG9mOg0KDQogICAg ICBUb28gaGlnaCBhIHF1ZXJ5IHJhdGUuDQogICAgICBVc2FnZSBvZiBkYXRh IG9idGFpbmVkIGluIHZpb2xhdGlvbiBvZiB0aGUgcHJvdmlkZWQgQ29weXJp Z2h0IG9yDQogICAgICAgICBVc2FnZSBndWlkZXMgZm9yIHRoZSBTZXJ2ZXIv RGF0YWJhc2UuDQogICAgICBBdXRvbWF0ZWQgb3IgUHJlZGljdGFibGUgUXVl cnkgUGF0dGVybnMuDQoNCjMuNCBUZXJtaW5hdGlvbiBvZiBDb25uZWN0aW9u DQoNCiAgIEJvdGggdGhlIENsaWVudCBhbmQgdGhlIFNlcnZlciBNVVNUIGhh bmRsZSB0aGUgQ29ubmVjdGlvbiBiZWluZw0KICAgY2xvc2VkIGF0IGFueSBw b2ludCB0aHJvdWdoIHRoZSB0cmFuc2FjdGlvbi4gIFRoZSBDb25uZWN0aW9u IG1heSBiZQ0KICAgY2xvc2VkIGR1ZSB0byBvbmUgb2YgdGhlIHJlYXNvbnMg YmVsb3csIG9yIHRocm91Z2ggZmFjdG9ycyBvdXRzaWRlDQogICB0aGUgc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgV2hlcmUgcG9zc2libGUsIHRo ZSBTZXJ2ZXIgTVVTVCBpc3N1ZSBhbiBFcnJvciBNZXNzYWdlIHRvIHRoZSBD bGllbnQNCiAgIGluZGljYXRpbmcgdGhlIHJlYXNvbiBmb3IgdGhlIGRpc2Nv bm5lY3Rpb24sIGJlZm9yZSB0aGUgY29ubmVjdGlvbiBpcw0KICAgY2xvc2Vk LiAgVGhlIENsaWVudCBNVVNUIGJlIHByb3ZpZGVkIHdpdGggYXBwcm9wcmlh dGUgY29udGFjdA0KICAgaW5mb3JtYXRpb24gc2hvdWxkIHRoZSBDbGllbnQg d2lzaCB0byBjaGFsbGVuZ2UgdGhlIGRpc2Nvbm5lY3Rpb24uDQoNCg0KDQoN Cg0KDQpDYW1wYmVsbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDkgXQ0KDA0KZHJhZnQtY2Ft cGJlbGwtd2hvaXMtMDAudHh0ICAgICBXSE9JUyAgICAgICAgICAgICAgICAg ICAgIE5vdmVtYmVyIDIwMDENCg0KMy40LjEgTm9ybWFsIFRlcm1pbmF0aW9u DQoNCiAgIFVubGVzcyBzcGVjaWZpZWQgb3RoZXJ3aXNlIGJ5IGZsYWdzIG9y IHF1YWxpZmllcnMgaW4gdGhlIFF1ZXN0aW9uLCANCiAgIHRoZSBTZXJ2ZXIg TVVTVCBjbG9zZSB0aGUgY29ubmVjdGlvbiBpbW1lZGlhdGVseSBhZnRlciBv dXRwdXR0aW5nIA0KICAgdGhlIGZ1bGwgQW5zd2VyLiAgVGhlIFNlcnZlciBk b2VzIE5PVCBuZWVkIHRvIHN1cHBseSBhIHJlYXNvbiBmb3INCiAgIHRoaXMg ZXhwZWN0ZWQgZGlzY29ubmVjdGlvbi4NCg0KMy40LjIgSW5hY3Rpdml0eSBU aW1lb3V0DQoNCiAgIFRoZSBTZXJ2ZXIgT3BlcmF0b3IgTUFZIGltcG9zZSBh IHRpbWUgbGltaXQgb24gaG93IGxvbmcgYSBnaXZlbiANCiAgIENvbm5lY3Rp b24gbWF5IGJlIGlkbGUgYmVmb3JlIGl0IGlzIGNsb3NlZCBkdWUgdG8gSW5h Y3Rpdml0eS4gIA0KDQozLjQuMyBDb25uZWN0aW9uIFRpbWVvdXQNCg0KICAg VGhlIFNlcnZlciBPcGVyYXRvciBNQVkgaW1wb3NlIGEgdGltZSBsaW1pdCBv biB0aGUgdG90YWwgdGltZSB1c2VkIA0KICAgYnkgYSBnaXZlbiBDb25uZWN0 aW9uLg0KDQozLjQuNCBBYnVzZSBvZiBTZXJ2aWNlDQoNCiAgIFRoZSBTZXJ2 ZXIgT3BlcmF0b3IgTUFZIGltcG9zZSBhICdibG9jaycgb24gYSBnaXZlbiBD bGllbnQgZHVlIHRvDQogICBiZWhhdmlvdXIgZGVtb25zdHJhdGVkIGJ5IHRo ZSBDbGllbnQgd2hpY2ggdHJhbnNncmVzc2VzIHRoZSBwdWJsaXNoZWQNCiAg IFVzYWdlIEd1aWRlbGluZXMuDQoNCjMuNC41IE90aGVyIGRpc2Nvbm5lY3Rp b24NCg0KICAgVGhlIFNlcnZlciBPcGVyYXRvciBNQVkgaGF2ZSBvdGhlciBy ZWFzb25zIHRvIGRpc2Nvbm5lY3QgYSBnaXZlbg0KICAgQ2xpZW50Lg0KDQo0 LiBDb25zaWRlcmF0aW9ucw0KDQo0LjEgSUFOQSBDb25zaWRlcmF0aW9ucw0K DQogICBJQU5BIGhhcyBhbHJlYWR5IGFzc2lnbmVkIFRDUCBhbmQgVURQIHBv cnQgNDMgdG8gTklDTkFNRS9XSE9JUy4gIFRoaXMNCiAgIGRvY3VtZW50IGRv ZXMgbm90IHNwZWNpZnkgYW55IGFkZGl0aW9uYWwgcG9ydHMuDQoNCjQuMS4x IEltcGxlbWVudG9ycyBOb3RlIG9uIEFzc2lnbmVkIFBvcnQNCg0KICAgSW1w bGVtZW50b3JzIE5vdGU6IElBTkEgaGFzIHNldCBhc2lkZSBwb3J0IDQzIFRD UCBhbmQgVURQIGZvciANCiAgIE5JQ05BTUUvV0hPSVMuICBUaGUgQXV0aG9y IG9mIHRoaXMgZG9jdW1lbnQgaGFzIG5vdCBzZWVuIGFueSANCiAgIHByb2R1 Y3Rpb24gQ2xpZW50cyBvciBTZXJ2ZXJzIHRoYXQgb3BlcmF0ZSB1c2luZyBV RFAuICBXaGVyZSBhIFNlcnZlciANCiAgIHJlc3BvbmRzIG9uIFVEUCwgdGhl IFNlcnZlciBNVVNUIGFsc28gcmVzcG9uZCBvbiBUQ1AsIGlmIG9ubHkgdG8g ZW1pdCANCiAgIGEgYmFubmVyIGluZGljYXRpbmcgdGhlIHVzZSBvZiBVRFAu DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQ2FtcGJlbGwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSAxMF0NCgwNCmRyYWZ0LWNhbXBiZWxsLXdob2lzLTAwLnR4dCAg ICAgV0hPSVMgICAgICAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDAxDQoN CjQuMiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBvZiB0aGUgV0hPSVMgUHJvdG9jb2wgYXJlIG5vdCBk aXNjdXNzZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQuICANCg0KICAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0byB0aGUgZXhwb3N1cmUgb2Yg RGF0YSB0aGF0IG1heSBiZQ0KICAgaW4gYSBnaXZlbiBEYXRhYmFzZSBhcmUg bGVmdCB0byB0aGUgUmVnaXN0cnkgcmVzcG9uc2libGUgZm9yIHRoYXQNCiAg IERhdGFiYXNlLg0KDQo1LiBSZWZlcmVuY2VzDQoNCiAgIFtCQ1AxOF0gICAg ICAgICBILiBBbHZlc3RyYW5kLCAiSUVURiBQb2xpY3kgb24gQ2hhcmFjdGVy IFNldHMgYW5kDQogICAgICAgICAgICAgICAgICBMYW5ndWFnZXMiLCBSRkMy Mjc3L0JDUDE4LCBKYW51YXJ5IDE5OTguDQoNCiAgIFtSRkM5NTRdICAgICAg ICAgSy4gSGFycmVuc3RpZW4sIE0uIFN0YWhsLCBhbmQgRS4gRmVpbmxlciwg DQogICAgICAgICAgICAgICAgICAiTklDTkFNRS9XSE9JUyIsIFJGQzk1NCwg T2N0b2JlciAxOTg1Lg0KDQogICBbUkZDMjAyNl0gICAgICBTLiBCcmFkbmVy ICJUaGUgSW50ZXJuZXQgU3RhbmRhcmRzIFByb2Nlc3MgLS0gUmV2aXNpb24N CiAgICAgICAgICAgICAgICAgIDMiLCBSRkMyMDI2L0JDUDksIE9jdG9iZXIg MTk5Ni4NCg0KICAgW1NURDJdICAgICAgICAgSi4gUmV5bm9sZHMgYW5kIEou IFBvc3RlbCwgIkFzc2lnbmVkIE51bWJlcnMiLA0KICAgICAgICAgICAgICAg ICAgUkZDMTcwMC9TVEQyLCBPY3RvYmVyIDE5OTQuDQoNCiAgIFtOQ0MtREIt T1BdICAgICAgUklQRSBOQ0MgV2hvaXMgU2VydmVyLCBPcGVyYXRpb25hbCBQ bG90cw0KICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5yaXBlLm5ldC9y aXBlbmNjL3B1Yi1zZXJ2aWNlcy9kYi8NCg0KICAgW0pQTklDXSAgICAgICAg IEpQTklDIFdob2lzIERhdGFiYXNlLCBTcGVjaWZ5aW5nICcvZScgZm9yIEVu Z2xpc2gNCiAgICAgICAgICAgICAgICAgIExhbmd1YWdlIE91dHB1dCwgaHR0 cDovL3d3dy5uaWMuYWQuanAvDQoNCjYuIEF1dGhvcidzIEFkZHJlc3MNCg0K ICAgQnJ1Y2UgQ2FtcGJlbGwNCiAgIFJJUEUgTkNDDQogICBTaW5nZWwgMjU4 DQogICBBbXN0ZXJkYW0gMTAxNkFCDQogICBUaGUgTmV0aGVybGFuZHMNCg0K ICAgUGhvbmU6ICszMSAyMCA1MzUgNDQ0NA0KICAgRmF4OiAgICszMSAyMCA1 MzUgNDQ0NQ0KICAgRU1haWw6IGJydWNlX2NhbXBiZWxsQHJpcGUubmV0DQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkNhbXBiZWxsICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgMTFdDQoMDQpkcmFmdC1jYW1wYmVsbC13aG9pcy0wMC50eHQg ICAgIFdIT0lTICAgICAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwMQ0K DQo3LiBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0 IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMSkuIEFsbCBSaWdodHMN CiAgIFJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xh dGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQNCiAgIGZ1cm5pc2hlZCB0 byBvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBv bg0KICAgb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQgb3IgYXNzaXN0IGluIGl0 cyBpbXBsZW1lbnRhdGlvbg0KICAgbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQs IHB1Ymxpc2hlZCBhbmQgZGlzdHJpYnV0ZWQsIGluDQogICB3aG9sZSBvciBp biBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueSBraW5kLA0KICAg cHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQg dGhpcw0KICAgcGFyYWdyYXBoIGFyZSBpbmNsdWRlZCBvbiBhbGwgc3VjaCBj b3BpZXMgYW5kIGRlcml2YXRpdmUNCiAgIHdvcmtzLiAgSG93ZXZlciwgdGhp cyBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZA0KICAgaW4g YW55IHdheSwgc3VjaCBhcyBieSByZW1vdmluZyB0aGUgY29weXJpZ2h0IG5v dGljZSBvcg0KICAgcmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgU29jaWV0 eSBvciBvdGhlciBJbnRlcm5ldA0KICAgb3JnYW5pemF0aW9ucywgZXhjZXB0 IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YNCiAgIGRldmVsb3Bpbmcg SW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlDQogICBwcm9j ZWR1cmVzIGZvciBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVybmV0 DQogICBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIGZvbGxvd2VkLCBvciBh cyByZXF1aXJlZCB0bw0KICAgdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2Vz IG90aGVyIHRoYW4gRW5nbGlzaC4NCg0KICAgVGhlIGxpbWl0ZWQgcGVybWlz c2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZA0KICAgd2ls bCBub3QgYmUgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBp dHMNCiAgIHN1Y2Nlc3NvcnMgb3IgYXNzaWducy4gVGhpcyBkb2N1bWVudCBh bmQgdGhlIGluZm9ybWF0aW9uDQogICBjb250YWluZWQgaGVyZWluIGlzIHBy b3ZpZGVkIG9uIGFuICJBUyBJUyIgYmFzaXMgYW5kIFRIRQ0KICAgSU5URVJO RVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sg Rk9SQ0UNCiAgIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBP UiBJTVBMSUVELCBJTkNMVURJTkcNCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBB TlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAgSU5GT1JNQVRJ T04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5Z DQogICBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9S IEZJVE5FU1MgRk9SIEENCiAgIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K Q2FtcGJlbGwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSAxMl0NCg== --12654081-1759836202-1005764310=:30058-- From owner-ietf-whois Wed Nov 14 17:41:19 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAF1fJS16192 for ietf-whois-bks; Wed, 14 Nov 2001 17:41:19 -0800 (PST) Received: from mta7.srv.hcvlny.cv.net (mta7.srv.hcvlny.cv.net [167.206.5.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAF1fI816186 for ; Wed, 14 Nov 2001 17:41:18 -0800 (PST) Received: from KB2BLX1 (ool-18bc7a56.dyn.optonline.net [24.188.122.86]) by mta7.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with SMTP id <0GMT007I7JCU7R@mta7.srv.hcvlny.cv.net> for ietf-whois@imc.org; Wed, 14 Nov 2001 20:41:22 -0500 (EST) Date: Wed, 14 Nov 2001 20:41:01 -0500 From: Ted Wolf Jr Subject: To: ietf-whois@imc.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: multipart/mixed; boundary="Boundary_(ID_SYi2iOQNEZZMW4MYkMUVjA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MS-TNEF-Correlator: Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --Boundary_(ID_SYi2iOQNEZZMW4MYkMUVjA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT --Boundary_(ID_SYi2iOQNEZZMW4MYkMUVjA) Content-type: application/ms-tnef; name=winmail.dat Content-transfer-encoding: base64 Content-disposition: attachment; filename=winmail.dat eJ8+IgEBAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCwAOABQAKQAAAAMAMQEB A5AGANQEAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAEAAAACATEAAQAAAPwAAABQ Q0RGRUIwOQABAAIAlgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABO SVRB+b+4AQCqADfZbgAAAGM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3Ncd29sZlxMb2NhbCBTZXR0 aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0ABgAAAAA AAAA6yMIfdNf0xG9LQCQAAU3DKKAAAAAAAAAGAAAAAAAAADrIwh901/TEb0tAJAABTcMwoAAABAA AABbWeqXJ/ZOTKq3BNpqk8laAQAAAAADADYAAAAAAAIBcQABAAAAFgAAAAHBbXaUl8NUm9XxEkQT uZ9jjpO5j1cAAAIBHQwBAAAAGAAAAFNNVFA6S0IyQkxYQFdFQlVTQTEuQ09NAAsAAQ4AAAAAQAAG DgDeBJR2bcEBAgEKDgEAAAAYAAAAAAAAAOsjCH3TX9MRvS0AkAAFNwzCgAAAAgEJEAEAAABoAAAA ZAAAAIAAAABMWkZ1ZEWm/gMACgByY3BnMTI1FjIA+Atgbg4QMDMzTwH3AqQE9AIAY2gKwHPQZXQw IAhQbQ3gBgQrBeACgH0KgXYIkHdr6QuAZDQMYGMAUAsDC7QvEzAKsQqAEnEAFPADAAB8BQAAAAsA AYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUA AAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAABShQAAfW4BAB4ACYAIIAYAAAAAAMAAAAAAAABG AAAAAFSFAAABAAAABAAAADkuMAALAA2ACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsAOoAI IAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwA8gAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAA AAADAD2ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAaIAIIAYAAAAAAMAAAAAAAABGAAAA AAaFAAAAAAAAAwBpgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAACAfgPAQAAABAAAADrIwh9 01/TEb0tAJAABTcMAgH6DwEAAAAQAAAA6yMIfdNf0xG9LQCQAAU3DAIB+w8BAAAAlgAAAAAAAAA4 obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB+b+4AQCqADfZbgAAAGM6XERv Y3VtZW50cyBhbmQgU2V0dGluZ3Ncd29sZlxMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRh XE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAA MgAAADxOREJCTE5DTk9MTERBSUhJT0VGRE9FRk9IREFBLmtiMmJseEB3ZWJ1c2ExLmNvbT4AAAAD AAYQAAAAAAMABxAAAAAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAAQAAAAAAAAD59w== --Boundary_(ID_SYi2iOQNEZZMW4MYkMUVjA)-- From owner-ietf-whois Thu Nov 15 17:47:00 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAG1l0p08632 for ietf-whois-bks; Thu, 15 Nov 2001 17:47:00 -0800 (PST) Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAG1kw808628 for ; Thu, 15 Nov 2001 17:46:58 -0800 (PST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.9.3) with ESMTP id fAG1nTm22092; Thu, 15 Nov 2001 20:49:30 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200111160149.fAG1nTm22092@nic-naa.net> To: ietf-whois@imc.org cc: brunner@nic-naa.net Subject: Draft: Request to Move RFC-954 to Historic Status Date: Thu, 15 Nov 2001 20:49:29 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, This is a different approach from the one several people have pursued over the past years, fixing it. Here I propose we simply make 954 historic, and remove any "IETF Standards" justification for registrant (user) data being available without restriction. To quote from rfc2026: 4.2.4 Historic A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. Personally I think that the existing formats are worth harmonizing, and something similar to rfc2870 (whois server operational requirements) is worth writing, but a large coarse wooden stake needs to be driven through the heart of the unrestricted disclosure [ENOPRIVACY] policy and its sets of wildly thoughtless advocates and practitioners. Comments to me, or the list. Eric Internet Engineering Task Force Eric Brunner-Williams Internet-Draft wampumpeag August, 2001 Expires February 2002 Request to Move RFC 954 to Historic Status Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo changes the status of RFC 954, "NICNAME/WHOIS", from Unknown to Historic. 1. Introduction The NICNAME/WHOIS [1] protocol, a TCP transaction based query/response protocol, and server [2], ran on a host located at SRI International. It was one of a series of internet services maintained by the DDN Network Information Center (NIC) at SRI International on behalf of the Defense Communications Agency (DCA). Brunner Expires April 2002 [Page 1] Internet-Draft Request to Move RFC 954 to Historic Status November 2001 This service provided DDN-network-wide directory service to internet users, via user programs running on local hosts, and delivered the full name, U.S. mailing address, telephone number, and network mailbox for DDN users who were registered in the NIC database. 2. Action Since the Defense Communications Agency (DCA) no longer contracts to SRI International to operate the DDN Network Information Center (NIC) at SRI International on its behalf, and the ARPANET was retired in 1990, and all DDN services terminated in 1995, MILNET included, the IESG is moving RFC 954 from Unknown to Historic status. 3. Security Considerations Moving RFC 954 to historic ends the application of DCA user data disclosure practices (unrestricted) to non-DCA Network Information Centers. Unrestricted access to NIC user registration data is a significant cause of limited user trust in network security, hence in a trustable network. Unrestricted access to NIC user registration data gives rise to excessive load on NIC user registration data services, excessive load on mail relays via unsolicited bulk email, and related abuses. 4. References [1] Harrenstein K., Stahl M., and E. Feinler, "NICNAME/WHOIS", RFC-954, Network Information Center, SRI International, October 1985. [2] MILNET address: 26.0.0.73, ARPANET address: 10.0.0.51 Author's Addresses Eric Brunner-Williams wampumpeag 1415 Forest Ave., Portland, ME 04103 Email: brunner@nic-naa.net Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are Brunner Expires April 2002 [Page 2] Internet-Draft Request to Move RFC 954 to Historic Status November 2001 included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Brunner Expires April 2002 [Page 3] From owner-ietf-whois Sun Feb 10 13:37:09 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1ALb9A01080 for ietf-whois-bks; Sun, 10 Feb 2002 13:37:09 -0800 (PST) Received: from dogberry.rutgers.edu (IDENT:ZkjWnHEr2uL44uAP0sGWDjwAC0DsSlSc@dogberry.rutgers.edu [165.230.209.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1ALb7301076 for ; Sun, 10 Feb 2002 13:37:08 -0800 (PST) Received: from fluellen.rutgers.edu (sendmail@fluellen.rutgers.edu [165.230.209.229]) by dogberry.rutgers.edu (8.11.2/8.11.2) with ESMTP id g1ALikC146462 for ; Sun, 10 Feb 2002 16:44:46 -0500 (EST) Received: (from easmith@localhost) by fluellen.rutgers.edu (8.11.2/8.11.2) id g1ALgh058142; Sun, 10 Feb 2002 16:42:43 -0500 (EST) From: "Allen Smith" Message-Id: <10202101642.ZM58245@fluellen.rutgers.edu> Date: Sun, 10 Feb 2002 16:42:43 -0500 In-Reply-To: Ed Allen Smith "draft-campbell-whois-00.txt" (Feb 10, 1:35pm) References: <200202101829.g1AITm246121@cesario.rutgers.edu> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: ietf-whois@imc.org, uwho@lists.research.netsol.com, rfci-discuss@megacity.org, anti-spam-wg@ripe.net Subject: Re: draft-campbell-whois-00.txt Cc: bruce_campbell@ripe.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I apologize about the cross-posting, but this is something that multiple lists are appropriate for discussing. The applicability of ietf-whois and uwho should be obvious; the rfci-discuss@megacity.org mailing list is for the http://www.rfc-ignorant.org project, which (among other things) tries to reduce spam (and other network abuse) burdens by providing blacklists (blocklists) of domains (whois.rfc-ignorant.org) and IP addresses (ipwhois.rfc-ignorant.org) which do not provide proper contact data (to which complaints about spam and other abuse can be sent). (Even if one does not have time to send complaints (even via automated means such as spamcop.net), I have found that blocking those IP address blocks lacking adequate WHOIS information to be useful in blocking spam in general - there is a correlation between such and inadequate/nonexistent policies at ISPs et al versus spam (or versus having an open relay which is used to transmit spam). There is also the correlation that many spammers, other than "mainsleaze" companies, tend to want to conceal their postal addresses to prevent legal papers from being served on them - Alan Ralsky, with his addresses located in the middle of the Hudson River (which I am sorry to say his registrar, Joker.com, refuses to do anything about), is a notorious example.) Given this anti-spam usage, the RIPE anti-spam WG mailing list is also included. On Feb 10, 1:35pm, Ed Allen Smith wrote: > Network Working Group Bruce Campbell > Internet Draft RIPE NCC > Expires: May 2002 November 2001 > Updates: RFC954 > > The basic NICNAME/WHOIS protocol > draft-campbell-whois-00.txt > Abstract > > This memo defines the basic WHOIS protocol as used on > the Internet today. Umm... it seems to have at least as much about policy - namely, claims as to a lack of requirements of WHOIS service - as it does about the actual _protocol_ as used today. > The original reference document for WHOIS[RFC954]] specifies two items. > > The first being a simple server<->client question and answer protocol > known as 'WHOIS', running on port 43 of a given machine. The second > item specifies a number of requirements for placement of data within > the 'SRI-NIC' database. > > The second item has caused much confusion and quasi-religious debates > over the years, especially given that the 'SRI-NIC' database has been > superceded several times. True. Although there are a number of other RFCs that have implications for WHOIS databases and their availability, as well as more implications in RFC954 regarding WHOIS (as opposed to NICNAME) than you are stating here: RFC954, in its discussion of looking up records for users in the SRI-NIC database: "full name, U.S. mailing address, telephone number, and network mailbox for DDN users who are registered in the NIC database" That portion of the RFC is, however, talking about the NICNAME database, which while accessible via the same port is supposed to be used _together_ with the WHOIS database: "This server, together with the corresponding WHOIS Database can also deliver online look-up of individuals or their online mailboxes, network organizations, DDN nodes and associated hosts, and TAC telephone numbers." In interpreting this, see, for instance, bcp46: "In addition, ISPs have a duty to make sure that their contact information, in Whois, in routing registries [[10]RFC1786] or in any other repository, is complete, accurate and reachable." RFC3013: "In addition, ISPs have a duty to make sure that their contact information, in Whois, in routing registries [[10]RFC1786] or in any other repository, is complete, accurate and reachable." RFC2167: "Early in the development of the ARPANET, the SRI-NIC established a centralized Whois database that provided host and network information about the systems connected to the network and the electronic mail (email) addresses of the users on those systems [RFC 954]." "The original Whois function was to be a central directory of resources and people on ARPANET." RFC2167 extends this concept to rwhois. RFC1834 on Whois++ also contains some information on what standard whois is supposed to provide: "NICNAME/WHOIS [HARR85] service is a TCP transaction based query/response server, running on a few specific central machines, that provides netwide directory service to Internet users. The Network Information Center (NIC) maintains the central NICNAME database and server, defined in [7]RFC 954, providing online look-up of individuals, network organizations, key host machines, and other information of interest to users of the Internet." And the following required fields from a server: Individual records Name Name of the individual required Organization Name of the organization required Handle A unique identifier for this required record on the local server Last-record-update Date this record was last required updated Host records Hostname Full domain name required IPAddress Address required Domain records Domain-name Domain name registered with required the Network Information Center (NIC) Network-address Network address associated required with this domain name Admin-name Name of the Administrative required Contact for this domain Admin-address Postal address of the required Admintistrative Contact for this domain Admin-telephone Telephone number of the required Admintistrative Contact for this domain Admin-email Electronic mail address in required [10]RFC 1822 format for the Administrative Contact for this domain Tech-name Name of the Technical Contact required for this domain Tech-address Postal address of the required Administrative Contact for this domain Tech-telephone Telephone number of the required Technical Contact for this domain Tech-email Electronic mail address in required [11]RFC 822 format for the Administrative Contact for this domain Last-update Last date this record was required updated The requirements for an IP-address Registrar (including Local Registrars as well as IANA, RIPE, APNIC, and ARIN) in RFC2050 are also of interest: 1. Introduction: [...] 3) Registration: Provision of a public registry documenting address space allocation and assignment. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels. Please note in this the word "public" - the information in question is to be disclosed to, essentially, whoever asks - and the information that is needed - that used "for Internet trouble shooting", and that this is needed information "at all levels". In other words, this RFC acknowledges that information needs to be provided by any IP address registry that will enable dealing with Internet problems, and this information needs to be provided to _anyone_ who needs it to deal with Internet problems. (Such Internet problems include, for instance, spam, as acknowledged in other RFCs. They do not, per se, include Intellectual Property issues, although I am glad of the support of the Intellectual Property Community for WHOIS data being available (see http://ipc.songbird.com/whois_paper.html).) A restriction on disclosure to, for instance, "law enforcement" (as I have seen proposed by some, such as CDT) is not workable. The postmaster of one mail-receiving host (e.g., me) has just as much legitimate need for such information as does the largest ISP, Registry, or Country. It is in the interest of the Internet community as a whole that the above goals be pursued. However it should be noted that "Conservation" and "Routability" are often conflicting goals. All the above goals may sometimes be in conflict with the interests of individual end-users or Internet service providers. Careful analysis and judgement is necessary in each individual case to find an appropriate compromise. Registries (including ccTLD registries as well as registries of other domain names and of IP addresses), ICANN, IANA, et al do not exist for the sake of their members, of the countries they are in, or anything else other than in the interest of the Internet community as a whole. Acting in the interest of that community is their responsibility. To the degree they fail to disclose sufficient information for "Internet trouble shooting", in a format accessible by standard tools (i.e., whois, as specified by RFC954 and further Internet-accepted documents) and, when such is needed (as in spam), they are failing to live up to that responsibility. To the degree possible, as it states, that compromises between the interests of individuals and the interest of the Internet community as a whole can be made, without significantly compromising the latter, they of course should be. For instance, if a private individual with a DSL line wishes a permanent IP address, it is perfectly reasonable for them to ask for the ISP's contact information to be used for their own, especially since dealing with problems is just as likely to be the job of the ISP as it is of that particular individual. (This would not be the case if the ISP is not capable (or willing) to deal with problems, of course. The party in the contact information in WHOIS must be capable of solving Internet problems.) ICANN's Registrar agreement is also of interest in this regard: Any Registered Name Holder that intends to license use of a domain name to a third party is nonetheless the Registered Name Holder of record and is responsible for providing its own full contact information and for providing and updating accurate technical and administrative contact information adequate to facilitate timely resolution of any problems that arise in connection with the Registered Name. A Registered Name Holder licensing use of a Registered Name according to this provision shall accept liability for harm caused by wrongful use of the Registered Name, unless it promptly discloses the identity of the licensee to a party providing the Registered Name Holder reasonable evidence of actionable harm. I can see another possibility, at least in the case of IP addresses, namely giving up the IP address block in question (and any fees associated with it). This is necessary for privacy purposes, in that the ultimate protection of the privacy of a registrant is if even the Registry doesn't know who the person is - they thus cannot be pressured (or otherwise forced, such as through a breakin) to disclose it under inappropriate circumstances. [...] Section 4: 2. Regardless of the source of its address space, sub-registries (Local IRs, ISPs, etc.) must adhere to the guidelines of its regional registry. In turn, it must also ensure that its customers follow those guidelines. In the relationship between a local IR (e.g., a country IR) and the regional registry, it is not appropriate for a regional registry to claim that it has to follow the policies of a local IR, due to "lack of data ownership" of data in a database, an individual country's wishes as to data privacy (or data disclosure), etcetrea. The local IRs are delegated to by the regional registry, not the other way around. > 1.2 Aims of this Document > > This document aims to provide an accurate definition of the basic WHOIS > protocol used on the Internet today. It includes observed variations > on possible queries and answers. > > This document does NOT provide definitions of the possibly sensitive > subjects as follows: > > Data that must be registered in any Database > Data that must be protected by Privacy Concerns > Output Format of Data Is there some particular reason why, at the minimum, either the RIPE-181 or RPSL format should not be available (with others being available at the option of the database operator)? (I personally favor requiring RPSL, but realize that not all clients have been migrated to parse it. Either it or RIPE-181 have the considerable advantage, as opposed to other proposals such as XML, of being directly humanly parseable without more than the simplest client interpretation. This is of immense help for, for instance, client programming and debugging.) > Question Format (beyond a requirement for 'help') > > The above definitions are defined by the Registry operating a > particular Database, and the Laws of that Registry's Country. I suggest deletion of the above two lines, at the minimum. There are a number of other factors which govern this: A. Other RFCs, with their requirements for registries, et al; see above. B. Requirements of parent registries and of ICANN. The latter has a section (3.3) in its Registrar Accreditation Agreement (see http://www.icann.org/registrars/ra-agreement-17may01.htm); while a "registrar" and a "registry" do differ, effectively a Registrar is acting as a Registry in regard to the database - I regret that this agreement, or similar, is not a requirement for all Registrars, including for ccTLDs. (Lest anyone believe that I am being US-centric in this regard, please be aware that the .us TLD is in the whois.rfc-ignorant.org blacklist due to the lack of a .us whois. I no more wish a US Registrar, even one fully authorized by the US government, to be able to not publish adequate WHOIS information than I do the Registrar for any other ccTLD.) I am, incidentally, curious in regard to the laws of various countries, whether many (or even all) of them may be gettable around via a direct requirement for permission of data disclosure in order to get a domain name or IP address block - especially if such a requirement is imposed by a "higher authority" such as ICANN/IANA or a parent registry. [...] > 2. Requirements [...] > A public 'WHOIS' Server SHOULD have as one of its aliases, a > hostname of 'whois', eg 'whois.example.com'. Aliases? Unless you're meaning this in a different sense than I have customarily seen it used, "alias" implies that this is not the (or a) "real hostname" of the server in question (i.e., that which will be returned by a PTR lookup (or will be among those returned by a PTR lookup) and which is not the domain name for a CNAME record - in common parlance, "is not a CNAME"). "SHOULD have as one of its hostnames (or aliases)", perhaps? > Such a Server MUST respond on the common 'WHOIS' port of > '43'. [STD2] Agreed. > 2.2.1 Server Operator > > The Entity or Entities in charge of a given 'WHOIS' Server who is/are > responsible for the behaviour and operation of a given Server. The > Server Operator MUST report usage, problems (etc) with the 'WHOIS' > Server to the Registry responsible for the Database. This implies > that the Server MUST log usage of the Server in some fashion. > > The Server Operator, in addition to abiding by any restrictions set > by the Registry, may add extra restrictions to the use of the Server, > possibly dynamically in response to Client behaviour. Except as required otherwise by the Registry and other RFCs, including those governing the conduct of Registries, or as the welfare of the Internet may dictate. > 2.3 Registry > > The Entity or Entities in charge of a given Database which is > accessible via a given 'WHOIS' Database. Normally, the Server > Operator(s) and the Registry are the same Entities, however a > distinction must be made between the two to reflect operational > practice. > > Where the Registry is the custodian of Data covered by Privacy > Restrictions, the Registry MUST enforce these restrictions. Is there some reason why this needs to be in the RFC? Normally, such "Privacy Restrictions" are imposed by laws (either privacy laws or contract laws). If a country (or association of countries, such as the EU) wishes to have and enforce such laws, they have their own means of doing so... > The Registry MAY also add extra restrictions to the use of it's > Data/Database. Again, so long as these do not conflict with rules by a parent Registry, ICANN/IANA, or the welfare of the Internet community as a whole. > 2.3.2 Updating the Database > [...] > The Registry may require certain information required for the > Registry's Operation to be registered within it's Database. >From the RFCs I have cited above, and the needs of the Internet for contact and other information to deal with problems, this information MUST be required by the Registry to be placed in the database and made public. > 2.3.3 Normal Usage of Data > > The exact usage of the Data within a Database is left for the > Registry to define, however Data obtained via WHOIS has historically > been for Internet Operational Purposes. Users should refer to the > usage conditions imposed by a given Registry. The data in such a database MUST be available to be used for purposes needed by the Internet community. [...] > 3.2.1 Language and Character Set > > The 'WHOIS' Server operator MAY nominate a Language and Character Set > to be used for any part of the 'Question'. If a Language or > Character Set other than 'English' and 'US-ASCII' is expected from > the Client, the Server MAY provide an initial banner message before > the Question is asked, specifying the Language and Character set in > use. [BCP18] I suggest "SHOULD", at least for Character Sets other than 'US-ASCII', given possible problems with clients not expecting other Character Sets. [...] > 3.3.3 Banner > > The Server MAY supply a Banner Message at three points during the > connection: > > Immediately after initial connection, > > Immediately after the termination of the Question by the Client > and before the output of the Answer. > > Immediately after the output of the Answer. > > To assist readability, the Banner Message SHOULD NOT exceed a polite > 4 lines. > > The Client MUST display any Banner Message to the User without > alteration. Umm... including without, say, translation into a different language, alteration of character set for display purposes, etcetera? [...] > 3.3.5 Warning Messages > > The Server MAY supply Warning Messages where part or all of the > Question is inappropriate as defined by the Server Operator. > Warning Messages should supply accurate and up to date information > about the perceived problem with the Question, Connection or Client. Is there some reason why this is not "SHOULD supply"? [...] > 3.3.6 Error Messages > > The Server MAY supply Error Messages where part or all of the Question > is inappropriate as defined by the Server Operator. Error Messages > should supply accurate and up to date information about the perceived > problem with the Question, Connection or Client. Ditto. > 3.3.7 Rejection Messages > > These are a special form of Error Message for 'problem' Clients. > They should clearly state why a given Question, Connection or Client > has been rejected. Ditto. > 7. Full Copyright Statement > > Copyright (C) The Internet Society (2001). All Rights > Reserved. > > This document and translations of it may be copied and > furnished to others, and derivative works that comment on > or otherwise explain it or assist in its implementation > may be prepared, copied, published and distributed, in > whole or in part, without restriction of any kind, > provided that the above copyright notice and this > paragraph are included on all such copies and derivative > works. However, this document itself may not be modified > in any way, such as by removing the copyright notice or > references to the Internet Society or other Internet > organizations, except as needed for the purpose of > developing Internet standards in which case the > procedures for copyrights defined in the Internet > Standards process must be followed, or as required to > translate it into languages other than English. > > The limited permissions granted above are perpetual and > will not be revoked by the Internet Society or its > successors or assigns. This document and the information > contained herein is provided on an "AS IS" basis and THE > INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE > DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY > IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE. -- Allen Smith easmith@beatrice.rutgers.edu September 11, 2001 A Day That Shall Live In Infamy II "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin From owner-ietf-whois Sun Feb 10 15:34:20 2002 Received: by above.proper.com (8.11.6/8.11.3) id g1ANYK602908 for ietf-whois-bks; Sun, 10 Feb 2002 15:34:20 -0800 (PST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1ANYJ302903 for ; Sun, 10 Feb 2002 15:34:19 -0800 (PST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1B2Ror08499; Sun, 10 Feb 2002 18:27:51 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202110227.g1B2Ror08499@nic-naa.net> To: "Allen Smith" cc: ietf-whois@imc.org, bruce_campbell@ripe.net, brunner@nic-naa.net Subject: Re: draft-campbell-whois-00.txt In-Reply-To: Your message of "Sun, 10 Feb 2002 16:42:43 EST." <10202101642.ZM58245@fluellen.rutgers.edu> Date: Sun, 10 Feb 2002 18:27:50 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Allen, In responding to your note I've deleted the following lists: uwho@lists.research.netsol.com - not an ietf activity, see nsi and/or vgrs about their activity or activities, rfci-discuss@megacity.org - not a "whois" list, of any stripe, anti-spam-wg@ripe.net - ditto. I didn't add the !43 list. I think it is a legitimate ietf list, and several people are on both the :43 and the !43 lists, and that list's animators can forward your note should they choose. The re-purpurposing you propose (or others have earlier imputed and you have chosen to accept uncritically) to rfc954 (NICNAME/WHOIS) service, one of UCE reduction, fails at least two tests: o this purpose could not have been stated prior to the initiation of the CIX agreements, and o this purpose is inconsistent with other normative texts, viz, http://europa.eu.int/comm/internal_market/en/dataprot/wpdocs/wp33en.htm Cheers, Eric From owner-ietf-whois Sun Feb 10 15:41:28 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1ANfSq03057 for ietf-whois-bks; Sun, 10 Feb 2002 15:41:28 -0800 (PST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1ANfR303053 for ; Sun, 10 Feb 2002 15:41:27 -0800 (PST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1B2ZGr08528 for ; Sun, 10 Feb 2002 18:35:17 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202110235.g1B2ZGr08528@nic-naa.net> To: ietf-whois@imc.org Subject: Someone want to forward this to Mr. Allen Smith? Date: Sun, 10 Feb 2002 18:35:16 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------- Forwarded Message Return-Path: MAILER-DAEMON Delivery-Date: Sun Feb 10 18:28:19 2002 Return-Path: Received: from localhost (localhost) by nic-naa.net (8.11.6/8.11.1) id g1B2SIr08500; Sun, 10 Feb 2002 18:28:18 -0800 (PST) (envelope-from MAILER-DAEMON) Date: Sun, 10 Feb 2002 18:28:18 -0800 (PST) From: Mail Delivery Subsystem Message-Id: <200202110228.g1B2SIr08500@nic-naa.net> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="g1B2SIr08500.1013394498/nic-naa.net" Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message - --g1B2SIr08500.1013394498/nic-naa.net The original message was received at Sun, 10 Feb 2002 18:27:51 -0800 (PST) from localhost.nic-naa.net [127.0.0.1] ----- The following addresses had permanent fatal errors ----- (reason: 550 5.0.0 ... Mail from rr.com rejected due to open relays (refusal to allow tests)) ----- Transcript of session follows ----- ... while talking to dogberry.rutgers.edu.: >>> RCPT To: <<< 550 5.0.0 ... Mail from rr.com rejected due to open relays (refusal to allow tests) 550 5.1.1 ... User unknown - --g1B2SIr08500.1013394498/nic-naa.net Content-Type: message/delivery-status Reporting-MTA: dns; nic-naa.net Received-From-MTA: DNS; localhost.nic-naa.net Arrival-Date: Sun, 10 Feb 2002 18:27:51 -0800 (PST) Final-Recipient: RFC822; easmith@beatrice.rutgers.edu Action: failed Status: 5.0.0 Remote-MTA: DNS; dogberry.rutgers.edu Diagnostic-Code: SMTP; 550 5.0.0 ... Mail from rr.com rejected due to open relays (refusal to allow tests) Last-Attempt-Date: Sun, 10 Feb 2002 18:28:09 -0800 (PST) - --g1B2SIr08500.1013394498/nic-naa.net Content-Type: message/rfc822 Return-Path: Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1B2Ror08499; Sun, 10 Feb 2002 18:27:51 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202110227.g1B2Ror08499@nic-naa.net> To: "Allen Smith" cc: ietf-whois@imc.org, bruce_campbell@ripe.net, brunner Subject: Re: draft-campbell-whois-00.txt In-Reply-To: Your message of "Sun, 10 Feb 2002 16:42:43 EST." <10202101642.ZM58245@fluellen.rutgers.edu> Date: Sun, 10 Feb 2002 18:27:50 -0800 From: Eric Brunner-Williams in Portland Maine MIME-Version: 1.0 Allen, In responding to your note I've deleted the following lists: uwho@lists.research.netsol.com - not an ietf activity, see nsi and/or vgrs about their activity or activities, rfci-discuss@megacity.org - not a "whois" list, of any stripe, anti-spam-wg@ripe.net - ditto. I didn't add the !43 list. I think it is a legitimate ietf list, and several people are on both the :43 and the !43 lists, and that list's animators can forward your note should they choose. The re-purpurposing you propose (or others have earlier imputed and you have chosen to accept uncritically) to rfc954 (NICNAME/WHOIS) service, one of UCE reduction, fails at least two tests: o this purpose could not have been stated prior to the initiation of the CIX agreements, and o this purpose is inconsistent with other normative texts, viz, http://europa.eu.int/comm/internal_market/en/dataprot/wpdocs/wp33en.htm Cheers, Eric - --g1B2SIr08500.1013394498/nic-naa.net-- ------- End of Forwarded Message From owner-ietf-whois Sun Feb 10 17:35:08 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1B1Z8E05017 for ietf-whois-bks; Sun, 10 Feb 2002 17:35:08 -0800 (PST) Received: from dogberry.rutgers.edu (IDENT:dURmCvYS1TV7QI1L/hJvHHG6POpPWpvq@dogberry.rutgers.edu [165.230.209.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1B1Z7305013 for ; Sun, 10 Feb 2002 17:35:07 -0800 (PST) Received: from fluellen.rutgers.edu (sendmail@fluellen.rutgers.edu [165.230.209.229]) by dogberry.rutgers.edu (8.11.2/8.11.2) with ESMTP id g1B1fjM148487; Sun, 10 Feb 2002 20:41:46 -0500 (EST) Received: (from easmith@localhost) by fluellen.rutgers.edu (8.11.2/8.11.2) id g1B1fiH58443; Sun, 10 Feb 2002 20:41:44 -0500 (EST) From: "Allen Smith" Message-Id: <10202102041.ZM58424@fluellen.rutgers.edu> Date: Sun, 10 Feb 2002 20:41:43 -0500 In-Reply-To: Eric Brunner-Williams in Portland Maine "Re: draft-campbell-whois-00.txt" (Feb 10, 7:44pm) References: <200202110227.g1B2Ror08499@nic-naa.net> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Eric Brunner-Williams in Portland Maine Subject: Re: draft-campbell-whois-00.txt Cc: ietf-whois@imc.org, bruce_campbell@ripe.net, admin@rfc-ignorant.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Feb 10, 7:44pm, Eric Brunner-Williams in Portland Maine wrote: > In responding to your note I've deleted the following lists: > > uwho@lists.research.netsol.com - not an ietf activity, see nsi > and/or vgrs about their activity or activities, Yes, but discussion of WHOIS regarding privacy has been taking place on there - CDT's comments, for instance. > rfci-discuss@megacity.org - not a "whois" list, of any stripe, Umm... incorrect. Bruce, I, and others, including the list manager, have been discussing WHOIS requirements on there quite a bit. I'll CC this to the list manager for whether he feels further discussion (as opposed to my response to Bruce's proposal, which he had announced on there) is relevant to that list. > anti-spam-wg@ripe.net - ditto. Again, incorrect, given the usage of whois for responses to spam, but I'll see what the reactions of those on there are. > I didn't add the !43 list. I think it is a legitimate ietf list, and > several people are on both the :43 and the !43 lists, and that > list's animators can forward your note should they choose. That's the logic that I used myself in not sending it there - or to, say, the RIPE/ARIN/APNIC database mailing lists, which I am also on. > The re-purpurposing you propose (or others have earlier imputed and > you have chosen to accept uncritically) I would not describe it as uncritically; by no means am I unaware of, for instance, privacy concerns, being a long-time EFF et al member. (Indeed, as someone who has been listed directly and is still (via an aliased address which goes to several people) in the WHOIS database, I am well aware of the spam that comes in as a result of being so listed... and given that the domains in question are associated with controversial (sexual/relationship and religious) matters, I am also well aware of the other potential misuses of such data.) > to rfc954 (NICNAME/WHOIS) service, one of UCE reduction, This is by no means the _only_ purpose of WHOIS - tracking back Internet problems and what can be done about them, whether those problems are UBE (not UCE; the first spamming was ideological in nature, and some of it continues to be) or others (including unintentional ones) is a more general usage. > fails at least two tests: > > o this purpose could not have been stated prior to the > initiation of the CIX agreements, The purpose of tracking back problems to those who can do something about them, or be held responsible for them, has been part of the purpose of WHOIS from the beginning, as my analysis of RFC954 shows. RFC2050 shows that that said purpose has continued to be a function of registries. > and > o this purpose is inconsistent with other normative texts, > viz, > http://europa.eu.int/comm/internal_market/en/dataprot/wpdocs/wp33en.htm Not a normative text for the Internet as a whole, any more than, say, France trying to insist that French should be the language of the Internet would be (or English-speaking nations trying to make English the only language used online, for that matter). Moreover, consent to disclosure (normally including consent as a part of a contract, business deal, or whatever) is sufficient to allow publication of all important information, even under EU regulations on the subject, so long as (as I suggested) there are provisions for an intermediary who is willing and able to do something about network abuse (or other network problems, unintentionally caused). -Allen -- Allen Smith easmith@beatrice.rutgers.edu September 11, 2001 A Day That Shall Live In Infamy II "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin From owner-ietf-whois Sun Feb 10 17:38:14 2002 Received: by above.proper.com (8.11.6/8.11.3) id g1B1cES05055 for ietf-whois-bks; Sun, 10 Feb 2002 17:38:14 -0800 (PST) Received: from dogberry.rutgers.edu (IDENT:bDbiThTP3k1JkZo3ehF6OD05hyBUR05k@dogberry.rutgers.edu [165.230.209.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1B1cD305051 for ; Sun, 10 Feb 2002 17:38:13 -0800 (PST) Received: from fluellen.rutgers.edu (sendmail@fluellen.rutgers.edu [165.230.209.229]) by dogberry.rutgers.edu (8.11.2/8.11.2) with ESMTP id g1B1jZM148971; Sun, 10 Feb 2002 20:45:36 -0500 (EST) Received: (from easmith@localhost) by fluellen.rutgers.edu (8.11.2/8.11.2) id g1B1jZU58235; Sun, 10 Feb 2002 20:45:35 -0500 (EST) From: "Allen Smith" Message-Id: <10202102045.ZM58477@fluellen.rutgers.edu> Date: Sun, 10 Feb 2002 20:45:33 -0500 In-Reply-To: Eric Brunner-Williams in Portland Maine "Someone want to forward this to Mr. Allen Smith?" (Feb 10, 7:56pm) References: <200202110235.g1B2ZGr08528@nic-naa.net> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Eric Brunner-Williams in Portland Maine , ietf-whois@imc.org Subject: Re: Someone want to forward this to Mr. Allen Smith? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I got it, thank you. I will add nic-naa.net (and its various other hostnames, IP addresses, etcetera) as a whitelisted address. rr.com, which nic-naa.net appears to be using, has been the cause of enough spam (largely due to their refusal to be tested for open relays) that we're blocking them locally. We do the same for, say, home.com. -Allen -- Allen Smith easmith@beatrice.rutgers.edu September 11, 2001 A Day That Shall Live In Infamy II "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin From owner-ietf-whois Sun Feb 10 20:21:19 2002 Received: by above.proper.com (8.11.6/8.11.3) id g1B4LJU07207 for ietf-whois-bks; Sun, 10 Feb 2002 20:21:19 -0800 (PST) Received: from bean.ar.com (66.123.187.68.ar.com [66.123.187.68] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1B4LH307203 for ; Sun, 10 Feb 2002 20:21:17 -0800 (PST) Received: from loki (IDENT:wessorh@loki [66.123.187.67]) by bean.ar.com (8.12.0/8.12.0) with ESMTP id g1B44KU1026899; Sun, 10 Feb 2002 20:04:21 -0800 (PST) Date: Sun, 10 Feb 2002 20:04:20 -0800 (PST) From: Rick H Wesson To: Allen Smith cc: , , , , Subject: Re: draft-campbell-whois-00.txt In-Reply-To: <10202101642.ZM58245@fluellen.rutgers.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: Allen, per your complaint against Joker/Alan Ralsky please take it up with ICANN they are very interested in this as Whois policy is reviewed. please file your complaints at http://www.internic.net/cgi/registrars/problem-report.cgi and feel free to make an automated posting mechanism so that everyone can tie it into their scripts. also you may want to encourage your registrar to 'hide' your e-mail address. best regards, -rick CTO, Registrars Constituency. On Sun, 10 Feb 2002, Allen Smith wrote: > > I apologize about the cross-posting, but this is something that > multiple lists are appropriate for discussing. The applicability of > ietf-whois and uwho should be obvious; the rfci-discuss@megacity.org > mailing list is for the http://www.rfc-ignorant.org project, which > (among other things) tries to reduce spam (and other network abuse) > burdens by providing blacklists (blocklists) of domains > (whois.rfc-ignorant.org) and IP addresses (ipwhois.rfc-ignorant.org) > which do not provide proper contact data (to which complaints about > spam and other abuse can be sent). (Even if one does not have time to > send complaints (even via automated means such as spamcop.net), I have > found that blocking those IP address blocks lacking adequate WHOIS > information to be useful in blocking spam in general - there is a > correlation between such and inadequate/nonexistent policies at ISPs > et al versus spam (or versus having an open relay which is used to > transmit spam). There is also the correlation that many spammers, > other than "mainsleaze" companies, tend to want to conceal their > postal addresses to prevent legal papers from being served on them > - Alan Ralsky, with his addresses located in the middle of the Hudson > River (which I am sorry to say his registrar, Joker.com, refuses to do > anything about), is a notorious example.) Given this anti-spam usage, > the RIPE anti-spam WG mailing list is also included. > From owner-ietf-whois Mon Feb 11 02:09:54 2002 Received: by above.proper.com (8.11.6/8.11.3) id g1BA9s604363 for ietf-whois-bks; Mon, 11 Feb 2002 02:09:54 -0800 (PST) Received: from mel-rto4.wanadoo.fr (smtp-out-4.wanadoo.fr [193.252.19.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BA9q304359 for ; Mon, 11 Feb 2002 02:09:52 -0800 (PST) Received: from mel-rta9.wanadoo.fr (193.252.19.69) by mel-rto4.wanadoo.fr; 11 Feb 2002 11:09:41 +0100 Received: from jfc2.wanadoo.fr (80.13.185.54) by mel-rta9.wanadoo.fr; 11 Feb 2002 11:09:23 +0100 Message-Id: <5.1.0.14.0.20020211100448.0258e480@pop.wanadoo.fr> X-Sender: jefsey@pop.wanadoo.fr X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Feb 2002 10:29:35 +0100 To: Jeff Williams , Rick H Wesson From: Jefsey Morfin Subject: Re: [Uwho] Re: draft-campbell-whois-00.txt Cc: Allen Smith , ietf-whois@imc.org, uwho@lists.research.netsol.com, rfci-discuss@megacity.org, anti-spam-wg@ripe.net, bruce_campbell@ripe.net, icann board address In-Reply-To: <3C6775E7.2C8BA31A@ix.netcom.com> 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: Dear Jeff, At 08:42 11/02/02, Jeff Williams wrote: > Makes one wonder what ICANN does do, doesn't it? ICANN has nothing to do except: - to publish the ICP consensual documents ruling the entries into the three pages of the IANA Excel table in a way it foster competition in being open to everyone on equal terms, and matches IETF requirements. - to check these prerequisites are met - to carry the entries. These documents are to be writen by its specialized support organizations where the stakholding Internet Participant gathered by Constituencies may uncover their consensus. They are to be endorsed for consistency and practical application by the BoD. They are to be enacted by the Staff. The whole process is under the control of the general @large assembly of the Internet Participants. To reach stablity: - 9 Directors come from the interested Internet Participants through the Constituencies and SO indirect channel, - 9 Directors are directly elected by the interested Internet Participants (@large) - 1 Director represents the Staff. This is it: a simple and stable solution for the Internet Community to get a trusted custodian for the IANA functions (which provides the Internet Consensus Infrastructure). The ICANN is currently suffering from a mission creep some say inherited from the DoC others from the confusion of some partners between entrusted service and commercial ownership. Whatever the reason of the desease the cure will probably be the transfer of the ICANN under the responsibility of the ITU/T. Once the Governments and the consumer organizations understand from the way it is used - instead of the way some want to use or benefit from it - that the Internet is not a network but the interconnection of its individual participants stations, systems and networks; not a a media but a low level medium falling under common rules and laws. It will only have costed the world billions in delayed development. Jefsey Morfin PS. I know of no WHOIS international consensual agreement endorsed by the GAC. This should be obtained first as such an agreement will be form the authoritative specifications of the WHOIS service and by consequence of the programs to suppoprt it. From owner-ietf-whois Mon Feb 11 04:25:43 2002 Received: by above.proper.com (8.11.6/8.11.3) id g1BCPh515643 for ietf-whois-bks; Mon, 11 Feb 2002 04:25:43 -0800 (PST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BCPf315638 for ; Mon, 11 Feb 2002 04:25:41 -0800 (PST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1BFG1r10256; Mon, 11 Feb 2002 07:16:01 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202111516.g1BFG1r10256@nic-naa.net> To: Allen Smith cc: brunner@nic-naa.net, crocker@brandenburg.com, ietf-whois@imc.org Subject: Re: [Uwho] Re: draft-campbell-whois-00.txt Date: Mon, 11 Feb 2002 07:16:01 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Allen, When I proposed to co-chair (with David Crocker) the -51 whoisfix bof, there were certain problems I didn't want to repeat: o the daft "technical" contributions by persons utterly unqualified to fix even the simplest of :43 problems, let alone the really hard problems, o the "well-known crank" problem (Jeff Williams, Jim Flemming, etc.), o mission creep into the PROVREG WG area of responsibility, and o mission creep into the eventual !43 area of responsibility. To achieve the second item I asked Paul Hoffman to put in place this policy ... The same (prior approval w.r.t. Jeff Williams) applies to other well-known cranks, who must obtain permission from a co-chair before being allowed to write directly to the list, e.g., Flemming ... In your zeal to advance your point of view, you've introduced cross-talk from "un-policed" lists which fail to meet two, and possibly all, of these criteria. In your response to my note you correct my distinction that the nsi/vgrs uwho list is not relevant to the purposes of the ietf-whois/whoisfix/:43 list. If this list progresses to a charter, and I think it can, it will be by the consensus of its contributors, not other parties. You also correct my distinction that some other lists are not "whois" lists. You appear to make this correction based upon the purpose of those other lists, and without reference to the minutes of the -51 meeting, which are on-line, or the archives of this list, which are also on-line. You do make the very case I attempt to characterize in my draft, that the protocol is subject to arbitrary repurposing by parties, whether those who use the protocol to originate UCE to the registrants associated with some servers, to verify trademark claims by registrants associated with some servers (civil law enforcement), to assist criminal law enforcement, and now to suppress UCE. My analysis of 954 and its anticeedents differs from yours. That I know the authors of 954 and its anticeedents plays an important part in my analysis. The scope of 2050 is for one, of two or more, types of registries. The scope of 954 is for another of the two or more types. Accuracy is more important than desire. You also reject the utility of reference to the jurisdictional scope, policy, and machanism requirements of the European Union Data Protection Directives. The jurisdictional rejection of EU DP Directives, and OECD guidelines, is a common feature in US business that are favored by the lower standards of an "opt-out" legal regime. It is also a common feature of "early adopters" who agrue that the internet and its services are "sui generis" and outside the rational scope of territorial-based jurisdiction public policies. I have to stop here, as I've got a more important demand on my time, who is three. The question is, should you be writing to this list at all? Eric From owner-ietf-whois Mon Feb 11 05:01:21 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BD1LO18513 for ietf-whois-bks; Mon, 11 Feb 2002 05:01:21 -0800 (PST) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1BD1J318508 for ; Mon, 11 Feb 2002 05:01:20 -0800 (PST) Received: (qmail 1051 invoked by uid 0); 11 Feb 2002 13:01:15 -0000 Received: from x22.ripe.net (HELO x22.ripe.net.ripe.net) (193.0.1.22) by postman.ripe.net with SMTP; 11 Feb 2002 13:01:15 -0000 Date: Mon, 11 Feb 2002 14:01:15 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: Allen Smith cc: ietf-whois@imc.org Subject: Re: draft-campbell-whois-00.txt In-Reply-To: <10202101642.ZM58245@fluellen.rutgers.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 Sun, 10 Feb 2002, Allen Smith wrote: > > 1.2 Aims of this Document > > > > This document aims to provide an accurate definition of the basic WHOIS > > protocol used on the Internet today. It includes observed variations > > on possible queries and answers. > > > > This document does NOT provide definitions of the possibly sensitive > > subjects as follows: > > > > Data that must be registered in any Database > > Data that must be protected by Privacy Concerns > > Output Format of Data > > Is there some particular reason why, at the minimum, either the > RIPE-181 or RPSL format should not be available (with others being Current installed base of 'whois' servers indicates that such a requirement on output format would be politically incorrect, and not able to be implemented in some cases. > > Question Format (beyond a requirement for 'help') > > > > The above definitions are defined by the Registry operating a > > particular Database, and the Laws of that Registry's Country. > > I suggest deletion of the above two lines, at the minimum. There are a > number of other factors which govern this: > A. Other RFCs, with their requirements for registries, et al; > see above. > B. Requirements of parent registries and of ICANN. The latter Both correct. > > 2. Requirements > > [...] > > > A public 'WHOIS' Server SHOULD have as one of its aliases, a > > hostname of 'whois', eg 'whois.example.com'. > > Aliases? Unless you're meaning this in a different sense than I have > customarily seen it used, "alias" implies that this is not the (or a) > "real hostname" of the server in question (i.e., that which will be > returned by a PTR lookup (or will be among those returned by a PTR > lookup) and which is not the domain name for a CNAME record - in > common parlance, "is not a CNAME"). "SHOULD have as one of its > hostnames (or aliases)", perhaps? Accepted, pending a review of DNS terms. > > 2.2.1 Server Operator > > > > The Entity or Entities in charge of a given 'WHOIS' Server who is/are > > responsible for the behaviour and operation of a given Server. The > > Server Operator MUST report usage, problems (etc) with the 'WHOIS' > > Server to the Registry responsible for the Database. This implies > > that the Server MUST log usage of the Server in some fashion. > > > > The Server Operator, in addition to abiding by any restrictions set > > by the Registry, may add extra restrictions to the use of the Server, > > possibly dynamically in response to Client behaviour. > > Except as required otherwise by the Registry and other RFCs, including > those governing the conduct of Registries, or as the welfare of the > Internet may dictate. Perhaps: The Server Operator, in addition to abiding by any and all restrictions set by the Registry, may add extra restrictions to the usage of the Server where such extra restrictions do not conflict with existing restrictions. Elsewhere it covers possible behaviour in response to data-mining activities (etc), so the 'dynamically in response' is unneeded at that point. > > 2.3 Registry > > > > The Entity or Entities in charge of a given Database which is > > accessible via a given 'WHOIS' Database. Normally, the Server > > Operator(s) and the Registry are the same Entities, however a > > distinction must be made between the two to reflect operational > > practice. > > > > Where the Registry is the custodian of Data covered by Privacy > > Restrictions, the Registry MUST enforce these restrictions. > > Is there some reason why this needs to be in the RFC? Normally, such > "Privacy Restrictions" are imposed by laws (either privacy laws or > contract laws). If a country (or association of countries, such as the > EU) wishes to have and enforce such laws, they have their own means of > doing so... I suspect that I was trying to ensure that by referencing possible privacy restrictions, it would serve as a reminder that such restrictions may exist. > > The Registry MAY also add extra restrictions to the use of it's > > Data/Database. > > Again, so long as these do not conflict with rules by a parent > Registry, ICANN/IANA, or the welfare of the Internet community as a > whole. Noted, will reword similar to 2.2.1. > > 2.3.2 Updating the Database > > > [...] > > > The Registry may require certain information required for the > > Registry's Operation to be registered within it's Database. > > >From the RFCs I have cited above, and the needs of the Internet for > contact and other information to deal with problems, this information > MUST be required by the Registry to be placed in the database and made > public. Correct, but the requirement for such data disclosure cannot be in the document describing the port 43 interactions. > > 2.3.3 Normal Usage of Data > > > > The exact usage of the Data within a Database is left for the > > Registry to define, however Data obtained via WHOIS has historically > > been for Internet Operational Purposes. Users should refer to the > > usage conditions imposed by a given Registry. > > The data in such a database MUST be available to be used for purposes > needed by the Internet community. No. 'WHOIS' is used by applications other than documenting domain/ip/person records. > > 3.2.1 Language and Character Set > > > > The 'WHOIS' Server operator MAY nominate a Language and Character Set > > to be used for any part of the 'Question'. If a Language or > > Character Set other than 'English' and 'US-ASCII' is expected from > > the Client, the Server MAY provide an initial banner message before > > the Question is asked, specifying the Language and Character set in > > use. [BCP18] > > I suggest "SHOULD", at least for Character Sets other than > 'US-ASCII', given possible problems with clients not expecting other > Character Sets. Noted. > > 3.3.3 Banner > > > > The Server MAY supply a Banner Message at three points during the > > connection: > > > > Immediately after initial connection, > > > > Immediately after the termination of the Question by the Client > > and before the output of the Answer. > > > > Immediately after the output of the Answer. > > > > To assist readability, the Banner Message SHOULD NOT exceed a polite > > 4 lines. > > > > The Client MUST display any Banner Message to the User without > > alteration. > > Umm... including without, say, translation into a different language, > alteration of character set for display purposes, etcetera? Please rephrase your point as it doesn't make sense. > > 3.3.5 Warning Messages > > > > The Server MAY supply Warning Messages where part or all of the > > Question is inappropriate as defined by the Server Operator. > > Warning Messages should supply accurate and up to date information > > about the perceived problem with the Question, Connection or Client. > > Is there some reason why this is not "SHOULD supply"? Hrm. MAY as in 'the query MAY be inappropriate'. Perhaps: The Server SHOULD supply Warning Messages _if_ part or all of the Question is inappropriate as defined by the Server Operator (etc) ( noted also for error and rejection messages ) Regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations From owner-ietf-whois Mon Feb 11 06:36:54 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BEas823477 for ietf-whois-bks; Mon, 11 Feb 2002 06:36:54 -0800 (PST) Received: from dogberry.rutgers.edu (IDENT:ejn9BZWkwwk6FW+hIo2rP0CQd2xvll/v@dogberry.rutgers.edu [165.230.209.227]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BEar323472 for ; Mon, 11 Feb 2002 06:36:53 -0800 (PST) Received: from fluellen.rutgers.edu (sendmail@fluellen.rutgers.edu [165.230.209.229]) by dogberry.rutgers.edu (8.11.2/8.11.2) with ESMTP id g1BEb0V156466; Mon, 11 Feb 2002 09:37:01 -0500 (EST) Received: (from easmith@localhost) by fluellen.rutgers.edu (8.11.2/8.11.2) id g1BEaxT59581; Mon, 11 Feb 2002 09:36:59 -0500 (EST) From: "Allen Smith" Message-Id: <10202110936.ZM59516@fluellen.rutgers.edu> Date: Mon, 11 Feb 2002 09:36:57 -0500 In-Reply-To: Bruce Campbell "Re: draft-campbell-whois-00.txt" (Feb 11, 9:03am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Bruce Campbell Subject: Re: draft-campbell-whois-00.txt Cc: ietf-whois@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Feb 11, 9:03am, Bruce Campbell wrote: > On Sun, 10 Feb 2002, Allen Smith wrote: > > > > 1.2 Aims of this Document > > > > > > This document aims to provide an accurate definition of the > > > basic WHOIS protocol used on the Internet today. It includes > > > observed variations on possible queries and answers. > > > > > > This document does NOT provide definitions of the possibly > > > sensitive subjects as follows: > > > > > > Data that must be registered in any Database > > > Data that must be protected by Privacy Concerns > > > Output Format of Data > > > > Is there some particular reason why, at the minimum, either the > > RIPE-181 or RPSL format should not be available (with others being > > Current installed base of 'whois' servers indicates that such a > requirement on output format would be politically incorrect, and not > able to be implemented in some cases. Unfortunate. Perhaps a SHOULD of that it be in a format which is documented and which is capable of automatic parsing? > > > Question Format (beyond a requirement for 'help') > > > > > > The above definitions are defined by the Registry operating a > > > particular Database, and the Laws of that Registry's Country. > > > > I suggest deletion of the above two lines, at the minimum. There > > are a number of other factors which govern this: > > A. Other RFCs, with their requirements for registries, et al; > > see above. > > B. Requirements of parent registries and of ICANN. The latter > > Both correct. Thank you. > > > 2. Requirements > > > > [...] > > > > > A public 'WHOIS' Server SHOULD have as one of its aliases, a > > > hostname of 'whois', eg 'whois.example.com'. > > > > Aliases? Unless you're meaning this in a different sense than I have > > customarily seen it used, "alias" implies that this is not the (or a) > > "real hostname" of the server in question (i.e., that which will be > > returned by a PTR lookup (or will be among those returned by a PTR > > lookup) and which is not the domain name for a CNAME record - in > > common parlance, "is not a CNAME"). "SHOULD have as one of its > > hostnames (or aliases)", perhaps? > > Accepted, pending a review of DNS terms. It's relatively minor, but I'd prefer not to have things held up later by people being legalistic about terms... the intended meaning is obvious (to me at least), but that doesn't always stop quibbling! > > > 2.2.1 Server Operator > > > > > > The Entity or Entities in charge of a given 'WHOIS' Server > > > who is/are responsible for the behaviour and operation of a > > > given Server. The Server Operator MUST report usage, > > > problems (etc) with the 'WHOIS' Server to the Registry > > > responsible for the Database. This implies that the Server > > > MUST log usage of the Server in some fashion. > > > > > > The Server Operator, in addition to abiding by any > > > restrictions set by the Registry, may add extra restrictions > > > to the use of the Server, possibly dynamically in response to > > > Client behaviour. > > > > Except as required otherwise by the Registry and other RFCs, > > including those governing the conduct of Registries, or as the > > welfare of the Internet may dictate. > > Perhaps: > > The Server Operator, in addition to abiding by any and all > restrictions set by the Registry, may add extra restrictions to > the usage of the Server where such extra restrictions do not > conflict with existing restrictions. Looks good, except, perhaps, "where such extra restrictions do not conflict with existing restrictions and/or obligations". In the context in question, "restrictions" appear to primarily be discussing limits on usage, not obligations for neccessary usages. > Elsewhere it covers possible behaviour in response to data-mining > activities (etc), so the 'dynamically in response' is unneeded at that > point. Right. > > > 2.3 Registry > > > > > > The Entity or Entities in charge of a given Database which is > > > accessible via a given 'WHOIS' Database. Normally, the Server > > > Operator(s) and the Registry are the same Entities, however a > > > distinction must be made between the two to reflect operational > > > practice. > > > > > > Where the Registry is the custodian of Data covered by Privacy > > > Restrictions, the Registry MUST enforce these restrictions. > > > > Is there some reason why this needs to be in the RFC? Normally, > > such "Privacy Restrictions" are imposed by laws (either privacy > > laws or contract laws). If a country (or association of countries, > > such as the EU) wishes to have and enforce such laws, they have > > their own means of doing so... > > I suspect that I was trying to ensure that by referencing possible > privacy restrictions, it would serve as a reminder that such > restrictions may exist. Perhaps, then: "A Registry SHOULD be aware of any Privacy Restrictions which may affect distribution of the data in this Database." Of course, legal requirements from one country, for international registries, might well conflict with those from another country - privacy regulations in one country may conflict with open record laws in another (or with a legally-enforced data demand by anyone from law enforcement to holders of intellectual property, which again may conflict with the privacy laws in other countries). > > > The Registry MAY also add extra restrictions to the use of > > > it's Data/Database. > > > > Again, so long as these do not conflict with rules by a parent > > Registry, ICANN/IANA, or the welfare of the Internet community as > > a whole. > > Noted, will reword similar to 2.2.1. Excellent. > > > 2.3.2 Updating the Database > > > > > [...] > > > > > The Registry may require certain information required for the > > > Registry's Operation to be registered within it's Database. That should be "its" Database, BTW. > > From the RFCs I have cited above, and the needs of the Internet > > for contact and other information to deal with problems, this > > information MUST be required by the Registry to be placed in the > > database and made public. > > Correct, but the requirement for such data disclosure cannot be in the > document describing the port 43 interactions. True. Perhaps "The Registry may require - including as otherwise obligated - ". This may not be necessary, but it's a reminder that there are other obligations on a Registry. > > > 2.3.3 Normal Usage of Data > > > > > > The exact usage of the Data within a Database is left for the > > > Registry to define, however Data obtained via WHOIS has > > > historically been for Internet Operational Purposes. Users > > > should refer to the usage conditions imposed by a given > > > Registry. > > > > The data in such a database MUST be available to be used for purposes > > needed by the Internet community. > > No. 'WHOIS' is used by applications other than documenting > domain/ip/person records. True - whois.abuse.net, for instance. My comment is therefore overly broad; perhaps "If the Data in a Database is from a Domain Name or IP Address Registry (in the sense of RFC2050), and contains information neccessary for Internet Operational Purposes, that information MUST be available for said purposes." (Other information that a Registry gathers, including billing, reasons for IP address needs, etcetera, obviously do not fall into this category - at least to me. It is admittedly possible that others may feel differently.) > > > 3.2.1 Language and Character Set > > > > > > The 'WHOIS' Server operator MAY nominate a Language and > > > Character Set to be used for any part of the 'Question'. If > > > a Language or Character Set other than 'English' and > > > 'US-ASCII' is expected from the Client, the Server MAY > > > provide an initial banner message before the Question is > > > asked, specifying the Language and Character set in > > > use. [BCP18] > > > > I suggest "SHOULD", at least for Character Sets other than > > 'US-ASCII', given possible problems with clients not expecting other > > Character Sets. > > Noted. Thank you. Note that I am not suggesting this in regard to Language. > > > 3.3.3 Banner > > > > > > The Server MAY supply a Banner Message at three points during > > > the connection: > > > > > > Immediately after initial connection, > > > > > > Immediately after the termination of the Question by the > > > Client and before the output of the Answer. > > > > > > Immediately after the output of the Answer. > > > > > > To assist readability, the Banner Message SHOULD NOT exceed a > > > polite 4 lines. I agree with this SHOULD NOT, but its form appears to be language-specific. 4 "lines" of Chinese does not have the same amount of content as 4 lines of English. > > > The Client MUST display any Banner Message to the User without > > > alteration. Incidentally, specification of how the Client is to distinguish Banner Messages, if they are to be treated differently than others, is needed. A prefix of '#' is common but by no means universal. > > Umm... including without, say, translation into a different > > language, alteration of character set for display purposes, > > etcetera? > > Please rephrase your point as it doesn't make sense. Sorry. You say "without alteration". Including without character set mapping into ones that can be displayed accurately? (I was incorrect in bringing languages into this; the Client should, if it is doing automatic translation, first present the original Banner (insofar as > > > 3.3.5 Warning Messages > > > > > > The Server MAY supply Warning Messages where part or all of > > > the Question is inappropriate as defined by the Server > > > Operator. Warning Messages should supply accurate and up to > > > date information about the perceived problem with the > > > Question, Connection or Client. > > > > Is there some reason why this is not "SHOULD supply"? > > Hrm. MAY as in 'the query MAY be inappropriate'. Perhaps: > > The Server SHOULD supply Warning Messages _if_ part or all of the > Question is inappropriate as defined by the Server Operator > (etc) > > ( noted also for error and rejection messages ) Looks good. Yours, -Allen P.S. BTW, while I may disagree with you on a number of points, I do appreciate the work that you have done on this. -- Allen Smith easmith@beatrice.rutgers.edu September 11, 2001 A Day That Shall Live In Infamy II "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin From owner-ietf-whois Mon Feb 11 08:39:47 2002 Received: by above.proper.com (8.11.6/8.11.3) id g1BGdlJ01400 for ietf-whois-bks; Mon, 11 Feb 2002 08:39:47 -0800 (PST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BGdk301396 for ; Mon, 11 Feb 2002 08:39:46 -0800 (PST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1BJX9r11018; Mon, 11 Feb 2002 11:33:09 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202111933.g1BJX9r11018@nic-naa.net> To: ietf-whois@imc.org cc: brunner@nic-naa.net, dcrocker@brandenburg.com, randy@psg.com, paf@cisco.com Subject: !43 BoF @ -53; co-chair status; whois-fix status Date: Mon, 11 Feb 2002 11:33:09 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Oki all, For those who aren't on the !43 list (details below), a few days ago Leslie Daigle (leslie@research.netsol.com) sent out a BoF announcement for -53. In the proposed charter for the BoF (Cross-Registry Information Service Protocol (CRISP)), backwards compatibility with RFC 954 is listed as a non-goal. Shortly before -52, when I realized that both Dave and I had a beneficiary relationship with the same company, incidently a whois:43 operator, and at some risk of 3rd-party interference, I sent mail to this list announcing that for family reasons I was cutting back on non-essential travel, and would not travel from Maine to Salt Lake. While my family reasons isn't likely to change till mid-year, I'm happy to announce that the shared beneficiary relationship problem has been resolved, and there is no risk of 3rd-party interference. I propose to continue to "co" and move the -51 BoF and this mailing list to a working group -- with all of your explicit, or at least tacit consent. There is still, as I wrote then (11/9/01) still a charter to complete, and time-line drift to correct for, assuming that the dates and deliverables were approximately correct. I'll still taking updates to the chart we started at London, the per-ccTLD details. I'd like to se one for the per-RIR and per-LIR details. Anyone??? Eric This is "below": Discussions about Internet infrastructure directory service protocols and requirements that aren't whois. mailto:ietf-not43-request@lists.research.netsol.com?subject=subscribe From owner-ietf-whois Wed Feb 13 00:22:10 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D8MAn13749 for ietf-whois-bks; Wed, 13 Feb 2002 00:22:10 -0800 (PST) Received: from mail.enyo.de (cygnus-ext.enyo.de [212.9.189.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D8M9313740 for ; Wed, 13 Feb 2002 00:22:09 -0800 (PST) Received: from [212.9.189.171] (helo=deneb.enyo.de) by mail.enyo.de with esmtp (Exim 3.34 #2) id 16aug5-0003Qa-00 for ietf-whois@imc.org; Wed, 13 Feb 2002 09:22:09 +0100 Received: from fw by deneb.enyo.de with local (Exim 3.34 #4) id 16aufz-0003lI-00 for ietf-whois@imc.org; Wed, 13 Feb 2002 09:22:03 +0100 To: ietf-whois@imc.org Subject: Registering handle suffixes From: Florian Weimer Date: Wed, 13 Feb 2002 09:22:03 +0100 Message-ID: <87adudvljo.fsf@deneb.enyo.de> Lines: 2 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i686-pc-linux-gnu) 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: Is it possible to register WHOIS handle suffixes somewhere, to avoid collisions? From owner-ietf-whois Wed Feb 13 17:29:28 2002 Received: by above.proper.com (8.11.6/8.11.3) id g1E1TSK09412 for ietf-whois-bks; Wed, 13 Feb 2002 17:29:28 -0800 (PST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1E1TQ309404 for ; Wed, 13 Feb 2002 17:29:26 -0800 (PST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1E4SrN01413 for ; Wed, 13 Feb 2002 20:28:59 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202140428.g1E4SrN01413@nic-naa.net> To: ietf-whois@imc.org Subject: Some food for thought Date: Wed, 13 Feb 2002 20:28:53 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Oki all, This gem dropped into my in-tray this afternoon, and I've sanitized the part that is relevant to :43. Someone is flogging 10^^8 records that look surprisingly similar to whois data, from select spindles, in CD form, for $200, or .0005 cents/record. Of course, the mechanism of acquisition of the data need not have been any protocol, contract (bulk sale) is another possibility. Just to keep my understanding of the market in registrant data consistent with reality, anyone who has data on mass-registrant data (prices, vendors, date of acquisition, format (this vendor's format of choice is EXCELL), do drop me a note off-list. Eric ------- Forwarded Message >Subject: 10.000.000 Domains For You > >You could be interested in [advert identifer removed] > >[advert identifer removed] Multi-CD-Roms Marketeers Domain Names Kit >is a wonderful tool for Internet Marketing. >It contains a domain database with 10 million records from .com, .net, >.org, and .edu. > >Each record includes: > Domain Name, > Registrant, > Registrant Code, > Registrant Address, > Registrant City, > Admin Contact, > Admin Code, > Admin email, > Admin Company, > Admin Address, > Admin City, > Admin Tel, > Admin Fax, > Tech Contact, > Tech Code, > Tech Email, > Tech Company, > Tech Address, > Tech City, > Tech Tel, > Tech Fax, > Bill Contact, > Bill Code, > Bill Email, > Bill Company, > Bill Address, > Bill City, > Bill Tel, > Bill Fax, > Server 1, > Server IP 1, > ... > Server 6, > Server IP 6 ------- End of Forwarded Message From owner-ietf-whois Mon Feb 18 16:44:12 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1J0iCC07846 for ietf-whois-bks; Mon, 18 Feb 2002 16:44:12 -0800 (PST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1J0iB307842 for ; Mon, 18 Feb 2002 16:44:11 -0800 (PST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1J3hT163822; Mon, 18 Feb 2002 19:43:29 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202190343.g1J3hT163822@nic-naa.net> To: ietf-whois@imc.org cc: brunner@nic-naa.net Subject: Re: Some food for thought Date: Mon, 18 Feb 2002 19:43:29 -0800 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Oki all, Privately I got one response indicating that the data contained in the 2-CD offering I described on the 13th is the result of WHOIS data mining, not a bulk sale of registrant data by a registry or registrar(s). For comparison, today's inbox contains this offer (also sanitized): Bulk email list for sale: 1 million emails in total, including 200,000 UK. Emails have been validated, removing the bad ones. List comes on a CD in two files in "comma separated value" format, one file contains 200,000 UK addresses, and the other contains 1 million of the world + uk. Unlike the whois data, which is "unexpired", but hardly valid simply by assertion by a whois-server, this data is validated (correct email addrs). It also lacks any PII. It is priced at 1M units for 5 pounds Sterling, or about a third of the price of whois-mined data mentioned in my note of last week (10M for $200). To my mind, these two "offers" establish the basic value of whois and list minimally mined end-point identifiers, about $10/million. This is a data point for the access cost of personally identifying information (PII) obtained from whois-servers, and re-purposed for UCE (aka "SPAM"). However, several other arguments have been made for the re-purposing of whois derived PII: o civil law enforcement, e.g., libel or trademark infringement, o criminal law enforcement, e.g., fraud or something more colorful, o isp policy enforcement, e.g., end-system disfunction For comparison, the purposing according to rfc954: o nic policy requirement, e.g., DDN authorized user determination o rir policy requirement, e.g., intermediate-system disfunction Each of the three re-purposing claims for registry (dn/ip/...) PII has been made with an equivalent access cost (nominal) requirement. The ICANN trade marks lobby, the US DoC law enforcement lobby, and one anti-SPAM lobby all require "free" access to (registrar- or registry-resident) PII (these two locations of PII characterize the "thin" and "thick" registry models, resp). I don't think any of these three claims is convincing. None places a critical reliance upon a conversion rate equivalent to the intended use of these two examples of rational economic use for targeted UCE campaigns. Each claims a sparse use of the mined data (or mining-enabled service), with each claiming only a few thousand "hits" per million registrations. Given the disparity in the sampling (sparce vs dense) between non-marketing and direct marketing, and the value of successful access (civil, criminal or AUP prosecution vs conversion -- an on-line sale or "click-through"), the cost to each purpose is artificially low. The equivalence of access cost to SPAM marketing campaigns places no barrier to civil, criminal, or policy enforcement that is conducted similarly, and that isn't an outcome that the IETF endorssed in the RAVEN discussion. Cheers, Eric From owner-ietf-whois Wed Feb 20 15:34:29 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1KNYTR20892 for ietf-whois-bks; Wed, 20 Feb 2002 15:34:29 -0800 (PST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1KNYS320887 for ; Wed, 20 Feb 2002 15:34:28 -0800 (PST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g1KNXO175946 for ; Wed, 20 Feb 2002 15:33:24 -0800 (PST) (envelope-from brunner@nic-naa.net) Message-Id: <200202202333.g1KNXO175946@nic-naa.net> Date: Wed, 20 Feb 2002 18:33:23 -0500 From: Eric Brunner-Williams in Portland Maine Subject: NC teleconf 14/02/02 Agenda item 5: WHOIS referral from ICANN BCC: Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------- Blind-Carbon-Copy To: philip.sheppard@aim.be cc: touton@icann.org, brunner Subject: NC teleconf 14/02/02 Agenda item 5: WHOIS referral from ICANN Date: Wed, 20 Feb 2002 18:33:23 -0500 From: Eric Brunner-Williams in Portland Maine Philip, Would you be so kind as to copy me on the item that was referred to the DNSO's WHOIS TF? I've seen the Verio reconsideration request [1], this is simply to flush out anything I don't know about. Eric References: [1] http://www.icann.org/committees/reconsideration/rc01-4.htm ------- End of Blind-Carbon-Copy From owner-ietf-whois Tue Mar 12 09:31:23 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2CHVN715834 for ietf-whois-bks; Tue, 12 Mar 2002 09:31:23 -0800 (PST) Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2CHVM415830 for ; Tue, 12 Mar 2002 09:31:22 -0800 (PST) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g2CHRdZ07095 for ; Tue, 12 Mar 2002 12:27:39 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200203121727.g2CHRdZ07095@nic-naa.net> To: ietf-whois@imc.org Subject: FYI: [ARIN] New Whois Display Format Date: Tue, 12 Mar 2002 12:27:39 -0500 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Oki all, Ginny Listman sent this to the dbwg list at ARIN. It is self-explanitory. Eric ------- Forwarded Message Date: Tue, 12 Mar 2002 11:00:20 -0500 (EST) From: ginny listman To: dbwg@arin.net Subject: New Whois Display Format Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1015948820=:12375" Sender: dbwg-request@arin.net Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. - ---559023410-851401618-1015948820=:12375 Content-Type: TEXT/PLAIN; charset=US-ASCII To coincide with the release of the new database and templates, ARIN has begun development of a new Whois, in a modular format. The Output Module will define the Whois display. It is our objective to keep the Whois display in a easily readable format, while accomodating machine queries by providing labels. The requirements outlined in this document are based on feedback from the community. To provide a usable tool, we are requesting additional comments at this time. Additionally, this format will be discussed at the Member Meeting taking place April 7-10 in Las Vegas. Ginny Listman Director of Engineering ARIN ***** WHOIS REQUIREMENTS I. Uses of Whois a. As a troubleshooting aid b. For Applications that use resource assignment information c. To show address space utilization d. In the future, to display routing objects II. Privacy a. The Whois database is a public resource. III. Formats a. The "default" format is returned when querying Whois without any flags, and there is a single record returned. For ease of use all items will include labels. If a field does not exist, for example if a POC is missing a email address, a label will not be displayed. Refer to the attached "Whois Examples" for samples. The four object will be displayed as follows: i. Point Of Contact - display all attributes of the POC Name: or Handle: Address: Phone: Phone: Email: Email: ii. Organization - list the organization and all associated POCs Org Name: Org ID: Org Address: Org Handle: Org Name: Org Phone: <*> Org Email: <*> Org Handle: Org Name: Org Phone: <*> Org Email: <*> Note: Organization POC functions include Admin, Tech, Abuse and NOC. iii. Autonomous System - list the organization, the autonomous system, POCs for the autonomous system, and POCs for the organization Org Name: Org ID: Org Address: AS Number: AS Handle: AS Name: AS Handle: AS Name: AS Phone: <*> AS Email: <*> Org Handle: Org Name: Org Phone: <*> Org Email: <*> Note: All POCs for the AS will be displayed. Only the organization's Tech, Abuse and NOC POCs will be displayed. iv. IPv4 Network - list the organization, the network, POCs for the network, POCs for the organization Org Name: Org ID: Org Address: CIDR Net Address: Network Range: Network Handle: Network Name: Can Sub-Delegate: IN-ADDR: IN-ADDR: Net Handle: Net Name: Net Phone: <*> Net Email: <*> Net Handle: Net Name: Net Phone: <*> Net Email: <*> Note: All POCs for the network will be displayed. Only the organization's Tech, Abuse and NOC POCs will be displayed. * Indicates that multiple phone numbers or email addresses exist, of which only the first is displayed. b. The "list" format is returned when querying Whois without specifying any flags, and there are multiple records returned. Labels are not included. The fields that are displayed are outlined below. i. Point Of Contact - last name, first name, middle name, handle, one email address, one office phone number ii. Organization - Organization name, Organization ID iii. Autonomous System - AS name, handle, AS number iiii. Network - network name, handle, either a single CIDR block or network range. c. In the future, we may provide the output in RPSL-like format. IV. Query by type. To narrow a search, a query can include a flag indicating the object type as follows: a. n will return only networks b. a will return only autonomous systems c. p will return only point-of-contacts d. o will return only organizations V. Query by attribute. To narrow a search, a query can also include a flag as follows: a. ! will return the single match of the specified handle b. @ will return the list of POCs with the specified domain name in the email address c. . will return a list of POCs, organizations, autonomous systems, and/or networks that start with the specified name VI. Additional features a. Sub-queries can be displayed using the % flag. The queried string must return a single record to provide sub-query information. The following objects have sub-query information: i. Networks - display the reassignment/reallocation information in list format, if data exists. ii. Organizations - display the organization's resources information in list format, if data exists. b. Parentage can be displayed using the * flag. The queried string must return a single record to provide parentage information. The following objects have parentage information: i. Networks - display the parentage in default format, if data exists. ii. Organizations - will be implemented in future releases. c. Other keywords i. = will show default displays for all matches, regardless of the number returned ii. HELP will display the help screen iii. . will show a list of all matches starting with the given string. iv. SUM will show list displays, even if there is only one match. d. The maximum number of records output is limited to 256. This may be revised in future versions. e. A future enhancement will include an relational lookup. For example, if a POC is queried, the resouces associated with the POC would be displayed. - ---559023410-851401618-1015948820=:12375 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=whois-ex Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Whois Examples ICAgICAgICAgICAgICAgIFdIT0lTIEVYQU1QTEVTDQoNClRoZSBmb2xsb3dp bmcgaW5mb3JtYXRpb24gaXMgdXNlZCBhcyBzYW1wbGUgZGF0YS4NCg0KMS4g T3JnYW5pemF0aW9uIEFCQyBJU1AgaXMgcmVnaXN0ZXJlZCB3aXRoIDUgUE9D cyAtIERFRi1BUklOIGFzIHRoZSANCmFkbWluaXN0cmF0aXZlIGNvbnRhY3Qs IEFCQy1URUNILUFSSU4gYW5kICBBQkMtVEVDSDItQVJJTiBhcyB0ZWNobmlj YWwgDQpjb250YWN0cywgQUJDLU5PQy1BUklOIGFzIGEgTk9DIGNvbnRhY3Qg YW5kIEFCQy1BQlUtQVJJTiBhcyBhbiBhYnVzZSBjb250YWN0Lg0KMi4gQUJD IElTUCBoYXMgYmVlbiBhc3NpZ25lZCBhdXRvbm9tb3VzIHN5c3RlbSA2NTAw MCwgYW5kIGhhcyBBQlVTRS1BUklOIGFzIA0KYW4gYWJ1c2UgY29udGFjdC4N CjMuIEFCQyBJU1AgaGFzIGJlZW4gYWxsb2NhdGVkIHR3byBuZXR3b3JrIGJs b2Nrcy4gIFRoZSBmaXJzdCAxMC4wLjAuMC8xNQ0KZG9lcyBub3QgaGF2ZSBh bnkgcmVzb3VyY2UgUE9DcyBhc3NvY2lhdGVkIHdpdGggaXQuICBJdCBoYXMg dHdvIElOLUFERFIgc2VydmVycy4NCjQuIFRoZSBzZWNvbmQgYWxsb2NhdGlv biAxMC4zMi4wLjAvMTYgaGFzIFNVUC1BUklOIGFzIGEgdGVjaG5pY2FsIGNv bnRhY3QgYW5kDQpOT0MyLUFSSU4gYXMgYSBOT0MgY29udGFjdC4gIEl0IGhh cyA0IElOLUFERFIgc2VydmVycy4NCjUuIEFCQyBoYXMgcmVhc3NpZ25lZCAx MC4zMi4wLjAtMTAuMzIuMC4xOSB0byBYWVogSVNQLiBYWVogaGFzIHRoZSBt aW5pbWFsDQphbW91bnQgb2YgUE9DcyAtIFhZWi1URUNILUFSSU4gYXMgdGhl IG9yZ2FuaXphdGlvbmFsIHRlY2huaWNhbCBhbmQgWFlaLUFETUktQVJJTg0K YXMgdGhlIGFkbWluaXN0cmF0aXZlLiBUaGVyZSBhcmUgbm8gUE9DcyBvciBJ Ti1BRERSIHNlcnZlcnMgb24gdGhlIHJlYWxsb2NhdGlvbi4NCg0KQmFzZWQg b24gdGhpcyBpbmZvcm1hdGlvbiwgdGhlIHdob2lzIGRpc3BsYXkgd291bGQg YmUgYXMgZm9sbG93czoNCg0KMS4gd2hvaXMgYWJjDQogICAgT3JnIE5hbWU6 IEFCQyBJU1ANCiAgICBPcmcgSUQ6IEFCQw0KICAgIE9yZyBBZGRyZXNzOiAx MzIgTWFpbiBTdHJlZXQNCiAgICAgICAgICAgICAgICAgQW55dG93biwgVkEg MjIyMjINCiAgICAgICAgICAgICAgICAgVVMNCg0KICAgIE9yZyBBZG1pbiBI YW5kbGU6IERFRi1BUklODQogICAgT3JnIEFkbWluIE5hbWU6IEZvb2Jhciwg RHdpZ2h0IEUuDQogICAgT3JnIEFkbWluIFBob25lOiArMS05OTktOTk5LTc3 NzcgKE9mZmljZSkgKg0KICAgIE9yZyBBZG1pbiBFbWFpbDogZm9vYmFyQGV4 YW1wbGUubmV0DQoNCiAgICBPcmcgVGVjaCBIYW5kbGU6IEFCQy1URUNILUFS SU4NCiAgICBPcmcgVGVjaCBOYW1lOiBUZWNobmljYWwgU3VwcG9ydA0KICAg IE9yZyBUZWNoIFBob25lOiArMS05OTktOTk5LTk5OTkgKE9mZmljZSkgKg0K ICAgIE9yZyBUZWNoIEVtYWlsOiB0ZWNoQGV4YW1wbGUubmV0DQoNCiAgICBP cmcgVGVjaCBIYW5kbGU6IEFCQy1URUNIMi1BUklODQogICAgT3JnIFRlY2gg TmFtZTogVGVjaG5pY2FsIFN1cHBvcnQgTWFuYWdlcg0KICAgIE9yZyBUZWNo IFBob25lOiArMS05OTktOTk5LTg4ODggKE9mZmljZSkNCiAgICBPcmcgVGVj aCBFbWFpbDogdGVjaC1tZ3JAZXhhbXBsZS5uZXQNCg0KICAgIE9yZyBOT0Mg SGFuZGxlOiBBQkMtTk9DLUFSSU4NCiAgICBPcmcgTk9DIE5hbWU6IE5ldHdv cmsgT3BlcmF0aW9ucyBDZW50ZXINCiAgICBPcmcgTk9DIFBob25lOiArMS05 OTktOTk5LTY2NjYgKE9mZmljZSkgKg0KICAgIE9yZyBOT0MgRW1haWw6IG5v Y0BleGFtcGxlLm5ldA0KDQogICAgT3JnIEFidXNlIEhhbmRsZTogQUJDLUFC VS1BUklODQogICAgT3JnIEFidXNlIE5hbWU6IE5ldHdvcmsgQWJ1c2UgU3Vw cG9ydA0KICAgIE9yZyBBYnVzZSBQaG9uZTogKzEtOTk5LTk5OS01NTU1IChP ZmZpY2UpICoNCiAgICBPcmcgQWJ1c2UgRW1haWw6IGFidXNlQGV4YW1wbGUu bmV0DQoNCjIuIHdob2lzIDY1MDAwDQogICAgT3JnIE5hbWU6IEFCQyBJU1AN CiAgICBPcmcgSUQ6IEFCQw0KDQogICAgQVMgTnVtYmVyOiA2NTAwMA0KICAg IEFTIEhhbmRsZTogQVM2NTAwMA0KICAgIEFTIE5hbWU6IEFCQy1BU042NTAw MA0KDQogICAgQVMgQWJ1c2UgSGFuZGxlOiBBQlVTRS1BUklODQogICAgQVMg QWJ1c2UgTmFtZTogQVMgNjUwMDAgQWJ1c2UgU3VwcG9ydA0KICAgIEFTIEFi dXNlIFBob25lOiArMS03MDMtMDAwLTAwMDAgKE9mZmljZSkgKg0KICAgIEFT IEFidXNlIEVtYWlsOiBhYnVzZS02NTAwMEBleGFtcGxlLm5ldA0KDQogICAg T3JnIFRlY2ggSGFuZGxlOiBBQkMtVEVDSC1BUklODQogICAgT3JnIFRlY2gg TmFtZTogVGVjaG5pY2FsIFN1cHBvcnQNCiAgICBPcmcgVGVjaCBQaG9uZTog KzEtOTk5LTk5OS05OTk5IChPZmZpY2UpICoNCiAgICBPcmcgVGVjaCBFbWFp bDogdGVjaEBleGFtcGxlLm5ldA0KDQogICAgT3JnIFRlY2ggSGFuZGxlOiBB QkMtVEVDSDItQVJJTg0KICAgIE9yZyBUZWNoIE5hbWU6IFRlY2huaWNhbCBT dXBwb3J0IE1hbmFnZXINCiAgICBPcmcgVGVjaCBQaG9uZTogKzEtOTk5LTk5 OS04ODg4IChPZmZpY2UpDQogICAgT3JnIFRlY2ggRW1haWw6IHRlY2gtbWdy QGV4YW1wbGUubmV0DQoNCiAgICBPcmcgTk9DIEhhbmRsZTogQUJDLU5PQy1B UklODQogICAgT3JnIE5PQyBOYW1lOiBOZXR3b3JrIE9wZXJhdGlvbnMgQ2Vu dGVyDQogICAgT3JnIE5PQyBQaG9uZTogKzEtOTk5LTk5OS02NjY2IChPZmZp Y2UpICoNCiAgICBPcmcgTk9DIEVtYWlsOiBub2NAZXhhbXBsZS5uZXQNCg0K ICAgIE9yZyBBYnVzZSBIYW5kbGU6IEFCQy1BQlUtQVJJTg0KICAgIE9yZyBB YnVzZSBOYW1lOiBOZXR3b3JrIEFidXNlIFN1cHBvcnQNCiAgICBPcmcgQWJ1 c2UgUGhvbmU6ICsxLTk5OS05OTktNTU1NSAoT2ZmaWNlKSAqDQogICAgT3Jn IEFidXNlIEVtYWlsOiBhYnVzZUBleGFtcGxlLm5ldA0KDQozLiB3aG9pcyAx MC4wLjAuMA0KICAgIE9yZyBOYW1lOiBBQkMgSVNQDQogICAgT3JnIElEOiBB QkMNCg0KICAgIENJRFIgTmV0IEFkZHJlc3M6IDEwLjAuMC4wLzE1DQogICAg TmV0d29yayBSYW5nZTogMTAuMC4wLjAtMTAuMS4yNTUuMjU1DQogICAgTmV0 d29yayBIYW5kbGU6IE5FVC0xMC0wLTAtMA0KICAgIE5ldHdvcmsgTmFtZTog TkVUV09SSy0xMA0KICAgIENhbiBTdWItRGVsZWdhdGU6IFkNCiAgICBJTi1B RERSOiBucy5leGFtcGxlLm5ldA0KICAgIElOLUFERFI6IG5zMi5leGFtcGxl Lm5ldA0KDQogICAgT3JnIFRlY2ggSGFuZGxlOiBBQkMtVEVDSC1BUklODQog ICAgT3JnIFRlY2ggTmFtZTogVGVjaG5pY2FsIFN1cHBvcnQNCiAgICBPcmcg VGVjaCBQaG9uZTogKzEtOTk5LTk5OS05OTk5IChPZmZpY2UpICoNCiAgICBP cmcgVGVjaCBFbWFpbDogdGVjaEBleGFtcGxlLm5ldA0KDQogICAgT3JnIFRl Y2ggSGFuZGxlOiBBQkMtVEVDSDItQVJJTg0KICAgIE9yZyBUZWNoIE5hbWU6 IFRlY2huaWNhbCBTdXBwb3J0IE1hbmFnZXINCiAgICBPcmcgVGVjaCBQaG9u ZTogKzEtOTk5LTk5OS04ODg4IChPZmZpY2UpDQogICAgT3JnIFRlY2ggRW1h aWw6IHRlY2gtbWdyQGV4YW1wbGUubmV0DQoNCiAgICBPcmcgTk9DIEhhbmRs ZTogQUJDLU5PQy1BUklODQogICAgT3JnIE5PQyBOYW1lOiBOZXR3b3JrIE9w ZXJhdGlvbnMgQ2VudGVyDQogICAgT3JnIE5PQyBQaG9uZTogKzEtOTk5LTk5 OS02NjY2IChPZmZpY2UpICoNCiAgICBPcmcgTk9DIEVtYWlsOiBub2NAZXhh bXBsZS5uZXQNCg0KICAgIE9yZyBBYnVzZSBIYW5kbGU6IEFCQy1BQlUtQVJJ Tg0KICAgIE9yZyBBYnVzZSBOYW1lOiBOZXR3b3JrIEFidXNlIFN1cHBvcnQN CiAgICBPcmcgQWJ1c2UgUGhvbmU6ICsxLTk5OS05OTktNTU1NSAoT2ZmaWNl KSAqDQogICAgT3JnIEFidXNlIEVtYWlsOiBhYnVzZUBleGFtcGxlLm5ldA0K DQo0LiB3aG9pcyAxMC4zMi4wLjANCiAgICBORVRXT1JLLTEwLjMyIChORVQt MTAtMzItMC0wKSAgICAgICAgICAgICAgICAgIDEwLjMyLjAuMC8xNg0KICAg IE5FVC0xMC0zMi1SRSAoTkVULTEwLTMyLTAtMC0yKSAgICAgICAgIDEwLjMy LjAuMC0xMC4zMi4wLjE5DQoNCjUuIHdob2lzIE5FVC0xMC0zMi0wLTAtMg0K ICAgIE9yZyBOYW1lOiBYWVogSVNQDQogICAgT3JnIElEOiBYWVoNCg0KICAg IENJRFIgTmV0IEFkZHJlc3M6IDEwLjMyLjAuMC8yOCwgMTAuMzIuMC4xOS8z MA0KICAgIE5ldHdvcmsgUmFuZ2U6IDEwLjMyLjAuMC0xMC4zMi4wLjE5DQog ICAgTmV0d29yayBIYW5kbGU6IE5FVC0xMC0zMi0wLTAtMg0KICAgIE5ldHdv cmsgTmFtZTogTkVULTEwLTMyLVJFDQogICAgQ2FuIFN1Yi1EZWxlZ2F0ZTog Tg0KDQogICAgT3JnIFRlY2ggSGFuZGxlOiBYWVotVEVDSC1BUklODQogICAg T3JnIFRlY2ggTmFtZTogVGVjaG5pY2FsIFN1cHBvcnQNCiAgICBPcmcgVGVj aCBQaG9uZTogKzEtNzc3LTc3Ny03Nzc3IChPZmZpY2UpICoNCiAgICBPcmcg VGVjaCBFbWFpbDogdGVjaC14eXpAZXhhbXBsZS5uZXQNCg0KNi4gd2hvaXMg QUJDLU5PQy1BUklODQogICAgTmFtZTogTmV0d29yayBPcGVyYXRpb25zIENl bnRlcg0KICAgIEhhbmRsZTogQUJDLU5PQy1BUklODQogICAgQWRkcmVzczog QUJDIElTUA0KICAgICAgICAgICAgIDEzMiBNYWluIFN0cmVldA0KICAgICAg ICAgICAgIEFueXRvd24sIFZBIDIyMjIyDQogICAgICAgICAgICAgVVMNCiAg ICBQaG9uZTogKzEtOTk5LTk5OS02NjY2IChPZmZpY2UpDQogICAgUGhvbmU6 ICsxLTg4OC04ODgtODg4OCAoTW9iaWxlKQ0KICAgIFBob25lOiArMS03Nzct Nzc3LTc3NzcgKEZheCkNCiAgICBFbWFpbDogbm9jQGV4YW1wbGUubmV0DQo= - ---559023410-851401618-1015948820=:12375-- ------- End of Forwarded Message From owner-ietf-whois Thu Sep 5 10:32:32 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85HWW507315 for ietf-whois-bks; Thu, 5 Sep 2002 10:32:32 -0700 (PDT) Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85HWU207306 for ; Thu, 5 Sep 2002 10:32:30 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.11.6) with ESMTP id g85HWQP3075043; Thu, 5 Sep 2002 13:32:28 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200209051732.g85HWQP3075043@nic-naa.net> To: ietf-whois@imc.org, ietf-not43@lists.research.netsol.com, dbwg@arin.net, Woeber@CC.UniVie.ac.at cc: ietf-provreg@cafax.se, w3c-p3p-specification@w3.org, iesg@ISI.EDU Subject: Re: Request to Move RFC 954 to Historic Status Date: Thu, 05 Sep 2002 13:32:26 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [ietf-whois and related lists] I sat down with the European Commission's Call for Expressions of Interest for the Selection of the .eu TLD Registry this week, and was pleased that Directive 95/46/EC is the controlling framework for that registry's core policy requirements (B.3, 1(b), Technical Annex, page 2). Here is the URL to the EC's DP home: http://europa.eu.int/comm/internal_market/en/dataprot/ That was my first imputus to finally submit an individual contribution to move 954 from "DRAFT STANDARD" to "HISTORIC". Now prior to Yokahama I asked around if anyone knew why and how (process) 954 had been moved from "UNKNOWN" (like 742 and 812) to "DRAFT STANDARD". No one I asked knew, but I didn't bother to formally ask the IESG and/or the RFC Editor. That change of status for 954 appears to have occured in the past two years. Perhaps someone on the IESG can enlighten me. Then there is the current ICANN announcement of some policy w.r.t. its Registrar Accreditation Agreement (RAA). The RAA contains language which appears closer to the language in 954 concerning MILNET TAC users than to the language in 954 concerning individual with a directory on an ARPANET or MILNET host. Both are in conflict with 95/46/EC, and the OEDC Guidelines (the oecd.org link is broken, so here is Roger Clarke's restatement, itself a useful read) http://www.anu.edu.au/people/Roger.Clarke/DV/PaperOECD.html I can't speculate on the actual status of :43 deployments by ccTLD operators located outside of North America. I decided not to include a mapping from the DCA language to a P3P schema, as for many, the policy scope question (controlling jurisdiction and legal theory, e.g., "fair trade" (US) vs "human rights" (EU)), not the mechanism for description and policy-scoped access, is more interesting, and both XML and schemas and/or DTDs are a distraction. I'll add it to -01. Your comments are welcome. I've cc'd the Provreg WG list due to the overlap of interest (many are also registrars and/or registry operators), and the W3C's P3P Spec WG list, also due to the overlap of interest. If anyone can provide feedback from RIPE-43 and or CENTR (Jaap?), or ICDPPC-24 (Rigo?) this month, and ARIN-X (Ed?) next month, that would be a good thing. Please be sure to cc me if replying. I started writing this before a comment got to me. The comment was: > I strongly disagree with the suggestion posed by this Draft. Whois is > a protocol in the public domain, and people can and do still use it. > The fact that SRI no longer supports it under DCA funding is an absurd > argument; it is just as irrelevant as the fact that ISI no longer > supports the DNS under DARPA funding, as it once did; should we make > the DNS protocol Historic? > > There is no protocol document obsoleting Whois, and I am not aware of > any terrible network consequence of its operation. People with > security issues on their databases do not have to participate. If > there are technical security problems with the protocol, the IESG > should move to develop a protocol to obsolete Whois. In the absence of > such a replacement, and in the absence of any demonstrable harm to the > Internet from keeping it as a Draft Standard, moving it to Historic > would be unnecessary and (I believe) a violatiokn of common sense > and proper standards setting. 954 specifies not only a protocol: C: [::printable::]\r\n S: .*\r\n It also specifies a data colleciton practice, the DCA's for MILNET TAC users, and for individual (users) with a directory on an ARPANET or MILNET host. The data collection practice itself is historic. The PROPOSED STANDARD status of a national military data collection practice is historic as well. If the IETF has any role in non-military public registry data collection practices, by RIRs, domain registry operators, or others choosing to use the above protocol on port 43, 954 is historic. Strong disagreement noted. Eric ------- Forwarded Message To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-brunner-rfc954-historic-00.txt Date: Thu, 05 Sep 2002 07:18:36 -0400 Sender: nsyracus@cnri.reston.va.us - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Request to Move RFC 954 to Historic Status Author(s) : E. Brunner-Williams Filename : draft-brunner-rfc954-historic-00.txt Pages : 3 Date : 2002-9-4 This memo requests a change of the status of RFC 954, A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-rfc954-historic-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-brunner-rfc954-historic-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-brunner-rfc954-historic-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-4143115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brunner-rfc954-historic-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-brunner-rfc954-historic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-4143115.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From owner-ietf-whois Thu Sep 5 13:01:22 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g85K1ME13972 for ietf-whois-bks; Thu, 5 Sep 2002 13:01:22 -0700 (PDT) Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85K1K213967 for ; Thu, 5 Sep 2002 13:01:20 -0700 (PDT) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g85K19pZ002717; Thu, 5 Sep 2002 22:01:09 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200209052001.g85K19pZ002717@bartok.sidn.nl> To: Eric Brunner-Williams in Portland Maine cc: ietf-whois@imc.org, ietf-not43@lists.research.netsol.com, Woeber@CC.UniVie.ac.at, ietf-provreg@cafax.se, iesg@isi.edu Subject: Re: Request to Move RFC 954 to Historic Status In-reply-to: Your message of Thu, 05 Sep 2002 13:32:26 -0400. <200209051732.g85HWQP3075043@nic-naa.net> Date: Thu, 05 Sep 2002 22:01:09 +0200 From: Jaap Akkerhuis Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've cc'd the Provreg WG list due to the overlap of interest (many are also registrars and/or registry operators), and the W3C's P3P Spec WG list, also due to the overlap of interest. I first didn't want to react to you proposal, but since you are spreading this around over various maillists and have my name in there, a short reaction. Note that whois is not on the agenda of provreg. If anyone can provide feedback from RIPE-43 and or CENTR (Jaap?), or ICDPPC-24 (Rigo?) this month, and ARIN-X (Ed?) next month, that would be a good thing. If you want to have feed back from the RIPE about this, you should get it on the agenda of the appropriate workgroups. You might even do it by proxy, you have your ideas presented by some (nuetral) person. For CENTR oppinions, suggest to contact the CENTR office. I'm not part of that, only my organisation (SIDN) is member of CENTR. jaap From owner-ietf-whois Thu Sep 5 13:41:15 2002 Received: by above.proper.com (8.11.6/8.11.3) id g85KfF415252 for ietf-whois-bks; Thu, 5 Sep 2002 13:41:15 -0700 (PDT) Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g85KfE215246 for ; Thu, 5 Sep 2002 13:41:14 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g85Kfk9X000471; Thu, 5 Sep 2002 16:41:47 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200209052041.g85Kfk9X000471@nic-naa.net> X-Mailer: exmh version 1.6.9 8/22/96 To: Jaap Akkerhuis cc: ietf-whois@imc.org, ietf-not43@lists.research.netsol.com, Woeber@CC.UniVie.ac.at, ietf-provreg@cafax.se, iesg@isi.edu Subject: Re: Request to Move RFC 954 to Historic Status In-Reply-To: Your message of "Thu, 05 Sep 2002 22:01:09 +0200." <200209052001.g85K19pZ002717@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Sep 2002 16:41:46 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I first didn't want to react to you proposal, but since you are > spreading this around over various maillists and have my name in there, a > short reaction. My appologies Jaap. From owner-ietf-whois Fri Sep 6 07:31:32 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g86EVWn05998 for ietf-whois-bks; Fri, 6 Sep 2002 07:31:32 -0700 (PDT) Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g86EVVk05991 for ; Fri, 6 Sep 2002 07:31:31 -0700 (PDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g86EVvnn002670; Fri, 6 Sep 2002 10:31:57 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200209061431.g86EVvnn002670@nic-naa.net> To: "Derek J. Balling" cc: Eric Brunner-Williams in Portland Maine , ietf-whois@imc.org, iesg@isi.edu, brunner@nic-naa.net Subject: Re: Request to Move RFC 954 to Historic Status In-Reply-To: Your message of "Thu, 05 Sep 2002 14:12:33 EDT." <0C98942B-C0FB-11D6-AF9D-00039384A830@megacity.org> Date: Fri, 06 Sep 2002 10:31:57 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [cc's limited to ietf-whois and iesg lists] > ... and should be postponed until - at bare minimum - a new/updated > RFC defines the protocol ... 954 is ignored by or irrelavent to a lot of registry (name and address) operators. See whois++, whois-fix, X.500, ... the wait may be considerable. > We can debate what the policy RFC would say at a later date. ;-) In some other body than the IETF. A proposal for one or more mechanisms capable of supporting types of policy _could_ be the subject of contributors to the IETF. Mechanism is "in scope". Policy isn't, or rubbish like a nation state's tests for intent and residence for use of the DNS [1] could be standards-track nstead of junk I-Ds. Incidently, the mechanism in [1] is rubbish also. Eric [1] http://www.ietf.org/internet-drafts/draft-liu-epp-ustld-00.txt From owner-ietf-whois Wed Apr 23 08:01:15 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NF1Ft2024099 for ; Wed, 23 Apr 2003 08:01:15 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NF1F6h024098 for ietf-whois-bks; Wed, 23 Apr 2003 08:01:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from nicolette.nic.cl (nicolette.nic.cl [216.72.164.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NF1Dt2024093 for ; Wed, 23 Apr 2003 08:01:14 -0700 (PDT) (envelope-from hsalgado@nic.cl) Received: from vulcano.intra.nic.cl [172.30.10.58] by nicolette.nic.cl (8.12.9/Main-DCCV9-Jo) id h3NF19Vg001680; Wed, 23 Apr 2003 11:01:09 -0400 Message-ID: <3EA6AA8E.50901@nic.cl> Date: Wed, 23 Apr 2003 11:00:30 -0400 From: "Hugo Salgado H." Organization: NIC Chile User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-whois@imc.org Subject: Re: Request to Move RFC 954 to Historic Status 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: Hi. This is my first mail to this list. My name is Hugo Salgado, and i work on NIC Chile, the .CL cctld administrator. Since few weeks ago we've been receiving complaints for the mail-blocking list that www.rfc-ignorant.com mantains. That list is blocking entire ccTLDs that are not respecting the RFC 954 on their whois service. As you were discussing before, that RFC lacks of things like privacy policies, anti-data-mining for spammers, etc. In .CL we don't publish the email addresses for our registrants, and that is the cause that rfc-ignorant is blocking the entire .cl email addresses. Is there an RFC that overrides the very old 954 ?? i know that .PL is listed in the blocked countries, for the same privacy policies in whois.dns.pl, but that was dicussed before in this list ?? Thanks, and sorry for my spanglish ;) -- Hugo Salgado H. R&D NIC Chile - http://www.nic.cl Agustinas 1357, piso 4, Cod. Postal 6500587 Santiago Chile Phone: (562) 940 7700 Fax: (562) 940 7701 From owner-ietf-whois Wed Apr 23 09:18:48 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NGImt2028483 for ; Wed, 23 Apr 2003 09:18:48 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NGImtf028482 for ietf-whois-bks; Wed, 23 Apr 2003 09:18:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NGIkt2028476 for ; Wed, 23 Apr 2003 09:18:47 -0700 (PDT) (envelope-from shane@ripe.net) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h3NGIeSs030273; Wed, 23 Apr 2003 18:18:40 +0200 Received: (from shane@localhost) by x17.ripe.net (8.12.9/8.12.6) id h3NGIejT010458; Wed, 23 Apr 2003 18:18:40 +0200 Date: Wed, 23 Apr 2003 18:18:40 +0200 From: Shane Kerr To: "Hugo Salgado H." Cc: ietf-whois@imc.org Subject: Re: Request to Move RFC 954 to Historic Status Message-ID: <20030423161840.GA9517@x17.ripe.net> References: <3EA6AA8E.50901@nic.cl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA6AA8E.50901@nic.cl> User-Agent: Mutt/1.4.1i Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hugo, On 2003-04-23 11:00:30 -0400, Hugo Salgado H. wrote: > > This is my first mail to this list. My name is Hugo Salgado, > and i work on NIC Chile, the .CL cctld administrator. > Since few weeks ago we've been receiving complaints for the > mail-blocking list that www.rfc-ignorant.com mantains. > That list is blocking entire ccTLDs that are not respecting > the RFC 954 on their whois service. > As you were discussing before, that RFC lacks of things like > privacy policies, anti-data-mining for spammers, etc. > In .CL we don't publish the email addresses for our registrants, > and that is the cause that rfc-ignorant is blocking the entire > .cl email addresses. > > Is there an RFC that overrides the very old 954 ?? i know that > .PL is listed in the blocked countries, for the same privacy > policies in whois.dns.pl, but that was dicussed before in this > list ?? I guess you're referring to this: http://www.rfc-ignorant.org/policy-whois.php http://www.rfc-ignorant.org/policy-ipwhois.php The only part of RFC 954 that *we* use is: PROTOCOL To access the NICNAME/WHOIS server: 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. To be honest, I think the rfc-ignorant people are misreading the RFC. There are clearly huge parts of it which don't apply any more. The entire INTRODUCTION is wrong. The WHO SHOULD BE IN THE DATABASE has no meaning today. The EXISTING USER PROGRAMS is also extremely out of date. Nobody implements the COMMAND LINES AND REPLIES as listed. In the RIPE NCC database group, we've had bad experiences with the rfc-ignorant people in the past. They don't like our policies, but have been unwilling to participate in any of our forums - by which I mean open mailing lists - to change the policies to meet their needs. Regarding your proposal, I agree. Or perhaps a "protocol-only" RFC could replace it. -- Shane Kerr RIPE NCC From owner-ietf-whois Wed Apr 23 09:31:31 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NGVVt2028937 for ; Wed, 23 Apr 2003 09:31:31 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NGVV5e028936 for ietf-whois-bks; Wed, 23 Apr 2003 09:31:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from narn.megacity.org (narn.megacity.org [65.242.171.25]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NGVSt2028931 for ; Wed, 23 Apr 2003 09:31:30 -0700 (PDT) (envelope-from dredd@megacity.org) Received: from megacity.org (hvc-204-210-140-244.hvc.rr.com [204.210.140.244]) (authenticated bits=0) by narn.megacity.org (8.12.9/8.12.9/Debian-1) with ESMTP id h3NGU8R3005569 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 23 Apr 2003 12:30:10 -0400 Date: Wed, 23 Apr 2003 12:30:30 -0400 Subject: Re: Request to Move RFC 954 to Historic Status Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Shane Kerr To: ietf-whois@imc.org From: "Derek J. Balling" In-Reply-To: <20030423161840.GA9517@x17.ripe.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wednesday, April 23, 2003, at 12:18 PM, Shane Kerr wrote: > In the RIPE NCC database group, we've had bad experiences with the > rfc-ignorant people in the past. They don't like our policies, but > have been unwilling to participate in any of our forums - by which I > mean open mailing lists - to change the policies to meet their needs. Errrr, nobody gave me the info on any to join. I know a number of RIPE folks are on our mailing list, though. Send me information off-list on what lists you think would be appropriate, if you would, and I'll be sub'ed to them within 24 hours. :) > Regarding your proposal, I agree. Or perhaps a "protocol-only" RFC > could replace it. For what it's worth, we (the RFCI folks) have always said 954 needed some serious updating. A "protocol-only" RFC is fine, but then there's no guidance of any kind as to what needs to be available for requestors, and there are a lot of valid reasons for requiring availability of such things as out of band contact info like snailmail and phone, which many ccTLD operators leave off. At the same time, e-mail is the de facto norm for "instant" communication. That's a whole different morass, though. D From owner-ietf-whois Wed Apr 23 09:51:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NGput2030306 for ; Wed, 23 Apr 2003 09:51:56 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NGpubI030305 for ietf-whois-bks; Wed, 23 Apr 2003 09:51:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from zak.ecotroph.net ([216.93.164.123]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NGptt2030300 for ; Wed, 23 Apr 2003 09:51:55 -0700 (PDT) (envelope-from anewton@ecotroph.net) Received: from ecotroph.net (h87.s239.netsol.com [::ffff:216.168.239.87]) (AUTH: LOGIN anewton) by zak.ecotroph.net with esmtp; Wed, 23 Apr 2003 12:51:56 -0400 Message-ID: <3EA6C797.8060207@ecotroph.net> Date: Wed, 23 Apr 2003 13:04:23 -0400 From: Andrew Newton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hugo Salgado H." CC: ietf-whois@imc.org Subject: Re: Request to Move RFC 954 to Historic Status References: <3EA6AA8E.50901@nic.cl> In-Reply-To: <3EA6AA8E.50901@nic.cl> 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: Hugo Salgado H. wrote: > > Is there an RFC that overrides the very old 954 ?? i know that > .PL is listed in the blocked countries, for the same privacy > policies in whois.dns.pl, but that was dicussed before in this > list ?? There are no RFC's, but there are a few things going on in this space. Eric Brunner-Williams submitted a draft to move 954 to historic: > http://www.ietf.org/internet-drafts/draft-brunner-rfc954-historic-00.txt Marcos Sanz has submitted a draft for whois and SRV RRs: > http://www.ietf.org/internet-drafts/draft-sanz-whois-srv-00.txt There is also an IETF working group called CRISP that is working on a replacement protocol. The requirements speak to many of the issues you have given. > http://www.ietf.org/html.charters/crisp-charter.html -andy From owner-ietf-whois Wed Apr 23 10:35:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NHZQt2032922 for ; Wed, 23 Apr 2003 10:35:26 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NHZQvZ032921 for ietf-whois-bks; Wed, 23 Apr 2003 10:35:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from nicolette.nic.cl (nicolette.nic.cl [216.72.164.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NHZOt2032913 for ; Wed, 23 Apr 2003 10:35:25 -0700 (PDT) (envelope-from hsalgado@nic.cl) Received: from vulcano.intra.nic.cl [172.30.10.58] by nicolette.nic.cl (8.12.9/Main-DCCV9-Jo) id h3NHZHVg022538; Wed, 23 Apr 2003 13:35:17 -0400 Message-ID: <3EA6CEAE.5030408@nic.cl> Date: Wed, 23 Apr 2003 13:34:38 -0400 From: "Hugo Salgado H." Organization: NIC Chile User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton CC: ietf-whois@imc.org Subject: Re: Request to Move RFC 954 to Historic Status References: <3EA6AA8E.50901@nic.cl> <3EA6C797.8060207@ecotroph.net> In-Reply-To: <3EA6C797.8060207@ecotroph.net> 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: Andrew Newton wrote: > > There is also an IETF working group called CRISP that is working on a > replacement protocol. The requirements speak to many of the issues you > have given. > >> http://www.ietf.org/html.charters/crisp-charter.html > Thanks. I've been following the CRISP discussions, but in the meaning our whois server must maintain the privacy policies defined by the "chilean internet comunity"... in despite of some black-lists. Hugo From owner-ietf-whois Wed Apr 23 11:00:13 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NI0Dt2033691 for ; Wed, 23 Apr 2003 11:00:13 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NI0D2c033690 for ietf-whois-bks; Wed, 23 Apr 2003 11:00:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from mahler.bearnet.com (qmailr@209-41-101-140.neospire.net [209.41.101.140]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3NI0Bt2033684 for ; Wed, 23 Apr 2003 11:00:11 -0700 (PDT) (envelope-from wew@bearnet.com) Received: (qmail 30503 invoked from network); 23 Apr 2003 16:12:41 -0000 Received: from ppp-67-64-249-120.dialup.rcsntx.swbell.net (HELO mars.bearnet.com) (billw@67.64.249.120) by mahler.bearnet.com with SMTP; 23 Apr 2003 16:12:41 -0000 Message-Id: <5.2.0.9.0.20030423110453.014c6590@mail.bearnet.com> X-Mailer: BW Mailer Version 5.2.0.9 Date: Wed, 23 Apr 2003 11:12:39 -0500 To: "Hugo Salgado H." From: Bill Weinman Subject: Re: Request to Move RFC 954 to Historic Status Cc: ietf-whois@imc.org In-Reply-To: <3EA6AA8E.50901@nic.cl> 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: Hi Hugo, I think it would be a mistake to move 954 to historical status without replacing it with a more complete RFC. If someone would like to take that project on, I would be willing to participate (that's why I joined this list). I would be interested to know what large organizations are using the rfc-ignorant BL to block email. None of the admins that I know use it for blocking email and AFAIK it was never really intended for that use. --Bill At 10:00 AM 4/23/2003, Hugo Salgado H. wrote: >Hi. >This is my first mail to this list. My name is Hugo Salgado, >and i work on NIC Chile, the .CL cctld administrator. >Since few weeks ago we've been receiving complaints for the >mail-blocking list that www.rfc-ignorant.com mantains. >That list is blocking entire ccTLDs that are not respecting >the RFC 954 on their whois service. >As you were discussing before, that RFC lacks of things like >privacy policies, anti-data-mining for spammers, etc. >In .CL we don't publish the email addresses for our registrants, >and that is the cause that rfc-ignorant is blocking the entire >.cl email addresses. > >Is there an RFC that overrides the very old 954 ?? i know that >.PL is listed in the blocked countries, for the same privacy >policies in whois.dns.pl, but that was dicussed before in this >list ?? > >Thanks, and sorry for my spanglish ;) > >-- >Hugo Salgado H. >R&D NIC Chile - http://www.nic.cl >Agustinas 1357, piso 4, Cod. Postal 6500587 Santiago Chile >Phone: (562) 940 7700 Fax: (562) 940 7701 ->-- Bill Weinman Music Database Music Whois Client ->-+ From owner-ietf-whois Wed Apr 23 12:22:19 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NJMJt2036389 for ; Wed, 23 Apr 2003 12:22:19 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NJMJK3036388 for ietf-whois-bks; Wed, 23 Apr 2003 12:22:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from narn.megacity.org (narn.megacity.org [65.242.171.25]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NJMIt2036383 for ; Wed, 23 Apr 2003 12:22:18 -0700 (PDT) (envelope-from dredd@megacity.org) Received: from megacity.org ([204.210.140.244]) (authenticated bits=0) by narn.megacity.org (8.12.9/8.12.9/Debian-1) with ESMTP id h3NI4RR3008194 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 23 Apr 2003 14:05:20 -0400 Date: Wed, 23 Apr 2003 14:04:01 -0400 Subject: Re: Request to Move RFC 954 to Historic Status Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: "Derek J. Balling" To: ietf-whois@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <3EA6CEAE.5030408@nic.cl> Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wednesday, April 23, 2003, at 01:34 PM, Hugo Salgado H. wrote: > Thanks. I've been following the CRISP discussions, but in the meaning > our whois server must maintain the privacy policies defined by the > "chilean internet comunity"... in despite of some black-lists. Without attempting to drag out this discussion *too* long, I would say that it's entirely possible for jurisdictions to legislate various stupid things, and it isn't necessarily the role of the net "at large" to be accepting of silly policies just because some countries have them as legislated mandates. For hyperbole's sake, $random_country could legislate tomorrow that "all mail servers must accept and deliver mail for all users" (open relays). Just because admins in $random_country are hamstrung by that silly rule doesn't mean that users in (! $random_country) have to accept messages from said servers. What I'm getting at, longwindedly, is that it's important that policy documents represent "best practices" and not have said policies be weakened because particular jurisdictions don't like them, or whatever. D From owner-ietf-whois Wed Apr 23 13:03:45 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NK3jt2037542 for ; Wed, 23 Apr 2003 13:03:45 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NK3j2w037541 for ietf-whois-bks; Wed, 23 Apr 2003 13:03:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from mahler.bearnet.com (qmailr@209-41-101-140.neospire.net [209.41.101.140]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h3NK3ht2037536 for ; Wed, 23 Apr 2003 13:03:43 -0700 (PDT) (envelope-from wew@bearnet.com) Received: (qmail 4980 invoked from network); 23 Apr 2003 20:03:45 -0000 Received: from ppp-67-64-249-120.dialup.rcsntx.swbell.net (HELO mars.bearnet.com) (billw@67.64.249.120) by mahler.bearnet.com with SMTP; 23 Apr 2003 20:03:45 -0000 Message-Id: <5.2.0.9.0.20030423145523.012652b8@mail.bearnet.com> X-Mailer: BW Mailer Version 5.2.0.9 Date: Wed, 23 Apr 2003 15:03:42 -0500 To: "Derek J. Balling" From: Bill Weinman Subject: Re: Request to Move RFC 954 to Historic Status Cc: ietf-whois@imc.org In-Reply-To: References: <3EA6CEAE.5030408@nic.cl> 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 01:04 PM 4/23/2003, Derek J. Balling wrote: >Without attempting to drag out this discussion *too* long, I would say >that it's entirely possible for jurisdictions to legislate various stupid >things, and it isn't necessarily the role of the net "at large" to be >accepting of silly policies just because some countries have them as >legislated mandates. Typical flame-bait -- "don't want to drag out the discussion" ... and ... "your policies are stupid and silly". With dialog like that, no wonder there's no workable policy. There are some very compelling arguments on both sides of this issue. If you want a rational debate, start by acknowledging opposing points of view. If you want a flamewar, please take it somewhere else. --Bill ->-- Bill Weinman Music Database Music Whois Client ->-+ From owner-ietf-whois Wed Apr 23 13:19:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NKJRt2037869 for ; Wed, 23 Apr 2003 13:19:27 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3NKJRQo037868 for ietf-whois-bks; Wed, 23 Apr 2003 13:19:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from narn.megacity.org (narn.megacity.org [65.242.171.25]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3NKJPt2037863 for ; Wed, 23 Apr 2003 13:19:26 -0700 (PDT) (envelope-from dredd@megacity.org) Received: from megacity.org (hvc-204-210-140-244.hvc.rr.com [204.210.140.244]) (authenticated bits=0) by narn.megacity.org (8.12.9/8.12.9/Debian-1) with ESMTP id h3NKHOR3011969 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 23 Apr 2003 16:17:25 -0400 Date: Wed, 23 Apr 2003 16:17:46 -0400 Subject: Re: Request to Move RFC 954 to Historic Status Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: "Derek J. Balling" To: ietf-whois@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <5.2.0.9.0.20030423145523.012652b8@mail.bearnet.com> Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wednesday, April 23, 2003, at 04:03 PM, Bill Weinman wrote: > At 01:04 PM 4/23/2003, Derek J. Balling wrote: >> Without attempting to drag out this discussion *too* long, I would >> say that it's entirely possible for jurisdictions to legislate >> various stupid things, and it isn't necessarily the role of the net >> "at large" to be accepting of silly policies just because some >> countries have them as legislated mandates. > > Typical flame-bait -- "don't want to drag out the discussion" ... and > ... "your policies are stupid and silly". > > With dialog like that, no wonder there's no workable policy. Sorry, that was not my intention. My "stupid things" statement was a segue into my hyperbolic example later in the post (which, it should be noted, really did describe a legally-mandated stupid policy), and was not intended to imply "privacy is stupid". My point was simply to indicate that "local legal policies" which seem perfectly reasonable to a local municipality, country or region of the world, may not necessarily be in line with "best practices" from a pure standpoint of "keeping a network up 24x7x365", and it's important that - for any RFC - the standards not be watered down in terms of their effectiveness to satisfy non-technical concerns. That Chileans (in the real-world example given) cannot include certain information on the WHOIS record does *not* mean by default that including it in WHOIS is "bad", and when writing a new policy document, that document should not consider it bad just because XX% of the countries have laws forbidding it. Does that wording make more sense? > There are some very compelling arguments on both sides of this issue. > If you want a rational debate, start by acknowledging opposing points > of view. If you want a flamewar, please take it somewhere else. I will certainly agree that there are good arguments for privacy. I know that I personally fall on the side of those who say "you're using part of a shared IP/name-space, and the rest of the net needs to be able to reach you if your portion is (screwed,acting-up,down,abusive,whatever)", but I was not meaning to imply that the other side of that many-sided coin's arguments were "dumb". Sorry for any misconceptions there. D From owner-ietf-whois Thu Apr 24 07:16:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEG0t2006226 for ; Thu, 24 Apr 2003 07:16:00 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OEG0Ml006225 for ietf-whois-bks; Thu, 24 Apr 2003 07:16:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEFvt2006216 for ; Thu, 24 Apr 2003 07:15:58 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3OEFo07025948 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 24 Apr 2003 16:15:51 +0200 To: "Derek J. Balling" Cc: ietf-whois@imc.org Subject: Re: Request to Move RFC 954 to Historic Status References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030424:dredd@megacity.org:fbea313f05619160 X-Hashcash: 0:030424:dredd@megacity.org:fbea313f05619160 X-Payment: hashcash 1.2 0:030424:ietf-whois@imc.org:0a2674ebb35f827a X-Hashcash: 0:030424:ietf-whois@imc.org:0a2674ebb35f827a Date: Thu, 24 Apr 2003 16:15:50 +0200 In-Reply-To: (Derek J. Balling's message of "Wed, 23 Apr 2003 16:17:46 -0400") Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Derek J. Balling" writes: > That Chileans (in the real-world example given) cannot include certain > information on the WHOIS record does *not* mean by default that > including it in WHOIS is "bad", and when writing a new policy > document, that document should not consider it bad just because XX% of > the countries have laws forbidding it. In this case, the reason didn't seem to be laws, but a privacy policy. A new policy document could discuss that problem and argue that the positive effects of publishing contact information generally outweigh the negative effects, to make people reconsider their policies. If the motivation behind the privacy policy is to reduce spam, then they need to do some research. Most spam research I've read (including the recent CDT study [1]) indicate that whois databases aren't used as a major source of spam addresses, and the benefits of having working whois when tracking down spam are immense. Also, some countries have registries that bogusly claim the reason is local laws, which is another reason to not codify that whois is bad in a document (registries may simply say laws forbid it, so they won't have to support the infrastructure required). Finally, even when there are valid laws that forbid this, having the policy part of 954 be updated could be used as input to change these laws, for the benefit of Internet users. [1] http://www.cdt.org/speech/spam/030319spamreport.shtml From owner-ietf-whois Thu Apr 24 07:15:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEFSt2006208 for ; Thu, 24 Apr 2003 07:15:28 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OEFS5s006207 for ietf-whois-bks; Thu, 24 Apr 2003 07:15:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from nicolette.nic.cl (nicolette.nic.cl [216.72.164.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEFQt2006201 for ; Thu, 24 Apr 2003 07:15:27 -0700 (PDT) (envelope-from hsalgado@nic.cl) Received: from vulcano.intra.nic.cl [172.30.10.58] by nicolette.nic.cl (8.12.9/Main-DCCV9-Jo) id h3OEFLVg014308; Thu, 24 Apr 2003 10:15:21 -0400 Message-ID: <3EA7F14F.10200@nic.cl> Date: Thu, 24 Apr 2003 10:14:39 -0400 From: "Hugo Salgado H." Organization: NIC Chile User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Derek J. Balling" CC: ietf-whois@imc.org Subject: Re: Request to Move RFC 954 to Historic Status References: In-Reply-To: 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: Derek J. Balling wrote: > > > On Wednesday, April 23, 2003, at 04:03 PM, Bill Weinman wrote: > >> At 01:04 PM 4/23/2003, Derek J. Balling wrote: >> >>> Without attempting to drag out this discussion *too* long, I would >>> say that it's entirely possible for jurisdictions to legislate >>> various stupid things, and it isn't necessarily the role of the net >>> "at large" to be accepting of silly policies just because some >>> countries have them as legislated mandates. >> >> >> Typical flame-bait -- "don't want to drag out the discussion" ... and >> ... "your policies are stupid and silly". >> >> With dialog like that, no wonder there's no workable policy. > > > That Chileans (in the real-world example given) cannot include certain > information on the WHOIS record does *not* mean by default that > including it in WHOIS is "bad", and when writing a new policy document, > that document should not consider it bad just because XX% of the > countries have laws forbidding it. > i just want to clarify that the local policy was taken in a process of analyzing the policies of the rest of cctlds, the recomendations of icann, and discussions in other mailing lists. anyway, my principal concern in this mail list was to ask and promote for a critical update on rfc 954... that respects the "privacy concerns" that the community itself is waiting to, in this days. hugo From owner-ietf-whois Thu Apr 24 07:41:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEf0t2007904 for ; Thu, 24 Apr 2003 07:41:00 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3OEex2Q007903 for ietf-whois-bks; Thu, 24 Apr 2003 07:40:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3OEevt2007890 for ; Thu, 24 Apr 2003 07:40:58 -0700 (PDT) (envelope-from jas@extundo.com) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h3OEet07026695 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 24 Apr 2003 16:40:56 +0200 To: ietf-whois@imc.org Subject: Re: Request to Move RFC 954 to Historic Status References: <3EA7F14F.10200@nic.cl> From: Simon Josefsson X-Payment: hashcash 1.2 0:030424:ietf-whois@imc.org:f333090702fa3189 X-Hashcash: 0:030424:ietf-whois@imc.org:f333090702fa3189 Date: Thu, 24 Apr 2003 16:40:55 +0200 In-Reply-To: <3EA7F14F.10200@nic.cl> (Hugo Salgado H.'s message of "Thu, 24 Apr 2003 10:14:39 -0400") Message-ID: User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-22.4 required=5.0 tests=BAYES_00,IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm sure most of you are familiar with the following document, but I'll waste some bandwidth to reach the remaining readers. http://www.icann.org/committees/security/whois-recommendation-01dec02.htm From owner-ietf-whois Thu Apr 24 20:44:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3P3iSt2043085 for ; Thu, 24 Apr 2003 20:44:28 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h3P3iSbt043084 for ietf-whois-bks; Thu, 24 Apr 2003 20:44:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from nicolette.nic.cl (nicolette.nic.cl [216.72.164.131]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h3P3iQt2043074 for ; Thu, 24 Apr 2003 20:44:27 -0700 (PDT) (envelope-from hsalgado@nic.cl) Received: from localhost [127.0.0.1] by nicolette.nic.cl (8.12.9/Main-DCCV9-Jo) id h3P3iIVg004676; Thu, 24 Apr 2003 23:44:18 -0400 Received: from 200.89.34.98 (SquirrelMail authenticated user hsalgado) by webmail.nic.cl with HTTP; Thu, 24 Apr 2003 23:44:18 -0400 (CLT) Message-ID: <33299.200.89.34.98.1051242258.squirrel@webmail.nic.cl> Date: Thu, 24 Apr 2003 23:44:18 -0400 (CLT) Subject: Re: Request to Move RFC 954 to Historic Status From: "=?iso-8859-1?Q?Hugo_Salgado_Hern=E1ndez?=" To: In-Reply-To: References: <3EA6AA8E.50901@nic.cl> X-Priority: 3 Importance: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.9) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The point of contact exists in the web page of the .cl cctld, where anyone can ask for the name, emails and phone numbers of the technical contacts of any domain. In this way, we can keep track of posibly misuse of this data. Hugo > The fact that spammers and others misuse data still leaves us > with the original purpose of network operations issues. > If someone in your ccTLD is hacking or spamming or has been infected by > CodeRed, it is neccessary to have a publicly available point of contact > so that the issue can be resolved. Indeed, if we are trying to reach > some place and things are broken we need a (possibly different) contact. > If you feel your privacy concerns are more important, please > don't connect to the rest of the Internet so we don't need to contact > you when something goes wrong. > > Conform to the RFC. That does not mean you cannot come up with a service > to relay mail that screens for spam and other misuse and list those > mailboxes. In addition you could come up with a call centre which relays > calls on behalf of registrants so that if we need to reach someone voice > (perhaps because their network is unreachable or mail bounces), we can > do so. > > Quality of data in WHOIS records is not uniform, many dolts here in the > US register absolute garbage in the contact fields and registrant name > and some registrars allow it. > > > > > > > > > > > On Wed, 23 Apr 2003, Hugo Salgado H. wrote: > >> >> Hi. >> This is my first mail to this list. My name is Hugo Salgado, >> and i work on NIC Chile, the .CL cctld administrator. >> Since few weeks ago we've been receiving complaints for the >> mail-blocking list that www.rfc-ignorant.com mantains. >> That list is blocking entire ccTLDs that are not respecting >> the RFC 954 on their whois service. >> As you were discussing before, that RFC lacks of things like >> privacy policies, anti-data-mining for spammers, etc. >> In .CL we don't publish the email addresses for our registrants, and >> that is the cause that rfc-ignorant is blocking the entire >> .cl email addresses. >> >> Is there an RFC that overrides the very old 954 ?? i know that >> .PL is listed in the blocked countries, for the same privacy >> policies in whois.dns.pl, but that was dicussed before in this >> list ?? >> >> Thanks, and sorry for my spanglish ;) -- Hugo Salgado H. Agustinas 1357, 4º piso - Santiago Chile Phone: (562) 940 7700 Fax: (562) 940 7701 From owner-ietf-whois Fri May 2 07:04:51 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42E4pi2046274 for ; Fri, 2 May 2003 07:04:51 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h42E4ppm046273 for ietf-whois-bks; Fri, 2 May 2003 07:04:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from usmi0022k06.apogent.com ([63.164.6.133]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42E4ni2046267 for ; Fri, 2 May 2003 07:04:49 -0700 (PDT) (envelope-from kchhabria@apogent.com) Received: by usmi0022k06.apogent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 May 2003 10:04:45 -0400 Message-ID: <9EE9982696300C47B28BB7B6C9420526077752AE@usmi0022k06.apogent.com> From: "Chhabria, Kavita - Apogent" To: "'ietf-whois@imc.org'" Subject: How do I identify if a particular registrar complies with the 'wh ois export and exchange format'? Date: Fri, 2 May 2003 10:04:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C310B3.C3106D90" Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C310B3.C3106D90 Content-Type: text/plain Hello all: I came across this internet draft just yesterday and would certainly like to have some more information on it. Also, I am faced with a requirement in a program to be able to use the whois protocol and extract data out of the output from different registrars by parsing them. However, since the output varies from registrar to registrar, I decided to search for ways to overcome this problem and that is when I came across this 'whois export and exchange format'. The question that I now have is that how do I identify if a registrar is capable of sending me the output of the whois query as an xml document as outlined in this draft? Pls pls explain me that. I have been trying to solve this problem for a long time now and any help in this regard would be greatly appreciated. Thanks Kavita Chhabria Systems Developer Apogent Technologies (616) 544-7515 kchhabria@apogent.com ------_=_NextPart_001_01C310B3.C3106D90 Content-Type: text/html Message
Hello all:
 
I came across this internet draft just yesterday and would certainly like to have some more information on it.
 
Also, I am faced with a requirement in a program to be able to use the whois protocol and extract data out of the output from different registrars by parsing them. However, since the output varies from registrar to registrar, I decided to search for ways to overcome this problem and that is when I came across this 'whois export and exchange format'.  The question that I now have is that how do I identify if a registrar is capable of sending me the output of the whois query as an xml document as outlined in this draft?  Pls pls explain me that.
 
I have been trying to solve this problem for a long time now and any help in this regard would be greatly appreciated.
 
Thanks
 
Kavita Chhabria
Systems Developer
Apogent Technologies
(616) 544-7515
 
------_=_NextPart_001_01C310B3.C3106D90-- From owner-ietf-whois Sun May 18 03:24:54 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4IAOrAF045065 for ; Sun, 18 May 2003 03:24:53 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4IAOrFF045064 for ietf-whois-bks; Sun, 18 May 2003 03:24:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from mail (mail.managerzone.com [62.95.110.220]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4IAOoAF045027 for ; Sun, 18 May 2003 03:24:51 -0700 (PDT) (envelope-from root@managerzone.com) Received: by mail (Postfix, from userid 0) id 4D7EA35D4FC; Sun, 18 May 2003 12:24:46 +0200 (CEST) X-Sieve: cmu-sieve 2.0 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by mail.managerzone.com (Postfix) with ESMTP id E33032A59B9 for ; Fri, 2 May 2003 16:10:45 +0200 (CEST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42E4pi2046274 for ; Fri, 2 May 2003 07:04:51 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h42E4ppm046273 for ietf-whois-bks; Fri, 2 May 2003 07:04:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from usmi0022k06.apogent.com ([63.164.6.133]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42E4ni2046267 for ; Fri, 2 May 2003 07:04:49 -0700 (PDT) (envelope-from kchhabria@apogent.com) Received: by usmi0022k06.apogent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 May 2003 10:04:45 -0400 Message-ID: <9EE9982696300C47B28BB7B6C9420526077752AE@usmi0022k06.apogent.com> From: "Chhabria, Kavita - Apogent" To: "'ietf-whois@imc.org'" Subject: How do I identify if a particular registrar complies with the 'wh ois export and exchange format'? Date: Fri, 2 May 2003 10:04:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C310B3.C3106D90" List-Archive: List-Unsubscribe: List-ID: X-Sanitizer: Anomy @ ManagerZone (www.managerzone.com) X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.68 2003/05/09 16:59:41 bre Exp $ Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C310B3.C3106D90 Content-Type: text/plain Hello all: I came across this internet draft just yesterday and would certainly like to have some more information on it. Also, I am faced with a requirement in a program to be able to use the whois protocol and extract data out of the output from different registrars by parsing them. However, since the output varies from registrar to registrar, I decided to search for ways to overcome this problem and that is when I came across this 'whois export and exchange format'. The question that I now have is that how do I identify if a registrar is capable of sending me the output of the whois query as an xml document as outlined in this draft? Pls pls explain me that. I have been trying to solve this problem for a long time now and any help in this regard would be greatly appreciated. Thanks Kavita Chhabria Systems Developer Apogent Technologies (616) 544-7515 kchhabria@apogent.com ------_=_NextPart_001_01C310B3.C3106D90 Content-Type: text/html Message Hello all:   I came across this internet draft just yesterday and would certainly like to have some more information on it.   Also, I am faced with a requirement in a program to be able to use the whois protocol and extract data out of the output from different registrars by parsing them. However, since the output varies from registrar to registrar, I decided to search for ways to overcome this problem and that is when I came across this 'whois export and exchange format'.  The question that I now have is that how do I identify if a registrar is capable of sending me the output of the whois query as an xml document as outlined in this draft?  Pls pls explain me that.   I have been trying to solve this problem for a long time now and any help in this regard would be greatly appreciated.   Thanks   Kavita Chhabria Systems Developer Apogent Technologies (616) 544-7515 kchhabria@apogent.com   ------_=_NextPart_001_01C310B3.C3106D90-- From owner-ietf-whois Sun May 18 09:38:09 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4IGc9AF063039 for ; Sun, 18 May 2003 09:38:09 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4IGc8sR063038 for ietf-whois-bks; Sun, 18 May 2003 09:38:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from mahler.bearnet.com (qmailr@209-41-101-140.neospire.net [209.41.101.140]) by above.proper.com (8.12.9/8.12.8) with SMTP id h4IGc7AF063031 for ; Sun, 18 May 2003 09:38:07 -0700 (PDT) (envelope-from wew@bearnet.com) Received: (qmail 18414 invoked from network); 18 May 2003 16:37:58 -0000 Received: from adsl-66-142-176-75.dsl.rcsntx.swbell.net (HELO mars.bearnet.com) (billw@66.142.176.75) by mahler.bearnet.com with SMTP; 18 May 2003 16:37:58 -0000 Message-Id: <5.2.0.9.0.20030518113326.0157aea0@mail.bearnet.com> X-Mailer: BW Mailer Version 5.2.0.9 Date: Sun, 18 May 2003 11:37:53 -0500 To: "Chhabria, Kavita - Apogent" From: Bill Weinman Subject: Re: How do I identify if a particular registrar complies with the 'wh ois export and exchange format'? Cc: "'ietf-whois@imc.org'" In-Reply-To: <9EE9982696300C47B28BB7B6C9420526077752AE@usmi0022k06.apoge nt.com> 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: The next version of my BW Whois (version 4.0) will parse data from the different registrars and deliver XML. (In the process I am working with Rich Wesson to update the expired whois-export draft -- it will likely change.) I'm currently scheduled to have a beta version ready by the end of June. (I have a proof of concept working already.) --Bill At 09:04 AM 5/2/2003, Chhabria, Kavita - Apogent wrote: >Hello all: I came across this internet draft just yesterday and would >certainly like to have some more information on it. Also, I am faced >with a requirement in a program to be able to use the whois protocol and >extract data out of the output from different registrars by parsing them. >However, since the output varies from registrar to registrar, I decided to >search for ways to overcome this problem and that is when I came across >this 'whois export and exchange format'. The question that I now have is >that how do I identify if a registrar is capable of sending me the output >of the whois query as an xml document as outlined in this draft? Pls pls >explain me that. I have been trying to solve this problem for a long >time now and any help in this regard would be greatly >appreciated. Thanks Kavita Chhabria Systems Developer Apogent >Technologies (616) 544-7515 >kchhabria@apogent.com ->-- Bill Weinman Music Database Music Whois Client ->-+ From owner-ietf-whois Fri Jul 30 16:06:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UN6kME004775; Fri, 30 Jul 2004 16:06:46 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i6UN6k8k004774; Fri, 30 Jul 2004 16:06:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i6UN6k90004764 for ; Fri, 30 Jul 2004 16:06:46 -0700 (PDT) (envelope-from dromasca@avaya.com) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i6UN0KSG001127 for ; Fri, 30 Jul 2004 18:00:20 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i6UN0ISG001118 for ; Fri, 30 Jul 2004 18:00:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47689.E29A7964" Subject: Out of Office AutoReply: Mail Delivery (failure dromasca@avaya.com) Date: Sat, 31 Jul 2004 02:06:45 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mail Delivery (failure dromasca@avaya.com) Thread-Index: AcR2ieKTlNvR3WDlRu6DA7od/rpJcwAAAAGc From: "Romascanu, Dan (Dan)" To: 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_001_01C47689.E29A7964 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I will be traveling for business purposes between August 1 and 12, and = then will be on vacation until August 30. My e-mail connectivity will be = scarce during this period, especially after August 14. I will however = check voice mail daily, and can be reached for urgent matters at the = mobile phone number +1-917-622-7831. Regards, Dan ------_=_NextPart_001_01C47689.E29A7964 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: <Possible SPAM> Mail Delivery = (failure dromasca@avaya.com)

I will be traveling for business purposes between = August 1 and 12, and then will be on vacation until August 30. My e-mail = connectivity will be scarce during this period, especially after August = 14. I will however check voice mail daily, and can be reached for urgent = matters at the mobile phone number +1-917-622-7831.

Regards,

Dan

------_=_NextPart_001_01C47689.E29A7964-- From owner-ietf-whois Thu Aug 19 03:59:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JAxUVY006300; Thu, 19 Aug 2004 03:59:30 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JAxUEg006299; Thu, 19 Aug 2004 03:59:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from web50706.mail.yahoo.com (web50706.mail.yahoo.com [206.190.38.104]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7JAxTQZ006235 for ; Thu, 19 Aug 2004 03:59:29 -0700 (PDT) (envelope-from myself_rajat@yahoo.com) Message-ID: <20040819105925.62311.qmail@web50706.mail.yahoo.com> Received: from [61.11.60.240] by web50706.mail.yahoo.com via HTTP; Thu, 19 Aug 2004 03:59:25 PDT Date: Thu, 19 Aug 2004 03:59:25 -0700 (PDT) From: Rajat Subject: Regarding whois query in xml format To: ietf-whois@imc.org 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: Hello all, I am in process of finding the location of a given IP address. So I made some queries to the whois servers(using TCP@43), but whatever response I got is in human readable text formate. More over the response format of each server is of different form. I compiled following servers, whois.arin.net whois.apnic.net whois.ripe.net whois.lacnic.net I am not able to parse the response and get the relevent information. Is there any way to get the response in proper xml format. So that I can easily parse it. I got one mail in a message archive, in that it was stated that if we sand whois query in XML format then will get the response in XML format only. Other wise simple text response will be returned. Does any body know that how we can query the whois srevr in xml format? And is it depends on servers xml compatibility?? Thanks in advance. Regards, Rajat __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-ietf-whois Thu Aug 19 06:09:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JD9tsx061253; Thu, 19 Aug 2004 06:09:55 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JD9tcm061252; Thu, 19 Aug 2004 06:09:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JD9qRQ061174 for ; Thu, 19 Aug 2004 06:09:55 -0700 (PDT) (envelope-from engin@ripe.net) Received: by postman.ripe.net (Postfix, from userid 8) id 3FE284E79E; Thu, 19 Aug 2004 15:09:45 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id E33234E798; Thu, 19 Aug 2004 15:09:44 +0200 (CEST) Received: from x47.ripe.net (x47.ripe.net [193.0.1.47]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i7JD9iW7021775; Thu, 19 Aug 2004 15:09:44 +0200 Received: (from engin@localhost) by x47.ripe.net (8.12.10/8.12.6) id i7JD9itH005139; Thu, 19 Aug 2004 15:09:44 +0200 Date: Thu, 19 Aug 2004 15:09:44 +0200 From: Engin Gunduz To: Rajat Cc: ietf-whois@imc.org Subject: Re: Regarding whois query in xml format Message-ID: <20040819130944.GA2969@x47.ripe.net> References: <20040819105925.62311.qmail@web50706.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline In-Reply-To: <20040819105925.62311.qmail@web50706.mail.yahoo.com> User-Agent: Mutt/1.4.2.1i X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 308ef2c91cc8933be60cbdfb56bd59e2 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear Rajat, None of the whois servers you list below supports XML. There is an effort called CRISP, or Cross-Registry Information Service Protocol at IETF, that aims at solving the problem you mentioned (no common data format) among others. CRISP is an ongoing work now. See http://www.ietf.org/html.charters/crisp-charter.html for more information. Best regards, -engin On 2004-08-19 03:59:25 -0700, Rajat wrote: > Hello all, > I am in process of finding the location of a given IP > address. So I made some queries to the whois > servers(using TCP@43), but whatever response I got is > in human readable text formate. More over the response > format of each server is of different form. I compiled > following servers, > > whois.arin.net > whois.apnic.net > whois.ripe.net > whois.lacnic.net > > I am not able to parse the response and get the > relevent information. > > Is there any way to get the response in proper xml > format. So that I can easily parse it. I got one mail > in a message archive, in that it was stated that if we > sand whois query in XML format then will get the > response in XML format only. Other wise simple text > response will be returned. > > Does any body know that how we can query the whois > srevr in xml format? And is it depends on servers xml > compatibility?? > > Thanks in advance. > > Regards, > Rajat -- Engin Gunduz RIPE NCC Software Engineering Department From owner-ietf-whois Thu Aug 19 06:53:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JDrCMI077055; Thu, 19 Aug 2004 06:53:12 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JDrCn3077054; Thu, 19 Aug 2004 06:53:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from screamer.tcp-ip.info (screamer.tcp-ip.info [68.167.18.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JDrCwB077048 for ; Thu, 19 Aug 2004 06:53:12 -0700 (PDT) (envelope-from dhudes@hudes.org) Received: by screamer.tcp-ip.info (Postfix, from userid 500) id 660CE2F478; Thu, 19 Aug 2004 09:53:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by screamer.tcp-ip.info (Postfix) with ESMTP id 5F1852DC12; Thu, 19 Aug 2004 09:53:14 -0400 (EDT) Date: Thu, 19 Aug 2004 09:53:14 -0400 (EDT) From: Dana Hudes X-X-Sender: dhudes@screamer.tcp-ip.info To: Rajat Cc: ietf-whois@imc.org Subject: Re: Regarding whois query in xml format In-Reply-To: <20040819105925.62311.qmail@web50706.mail.yahoo.com> Message-ID: References: <20040819105925.62311.qmail@web50706.mail.yahoo.com> 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: nowhere is it required to provide xml in response to whois. yes the address registries all have their own format. There's nothing to specify the syntax of the response to a WHOIS request. A whatever-to-xml translator is interesting idea. I hope one day to get back to my work on Perl WHOIS modules. I have No time ( due to no funding) now. On Thu, 19 Aug 2004, Rajat wrote: > > Hello all, > I am in process of finding the location of a given IP > address. So I made some queries to the whois > servers(using TCP@43), but whatever response I got is > in human readable text formate. More over the response > format of each server is of different form. I compiled > following servers, > > whois.arin.net > whois.apnic.net > whois.ripe.net > whois.lacnic.net > > I am not able to parse the response and get the > relevent information. > > Is there any way to get the response in proper xml > format. So that I can easily parse it. I got one mail > in a message archive, in that it was stated that if we > sand whois query in XML format then will get the > response in XML format only. Other wise simple text > response will be returned. > > Does any body know that how we can query the whois > srevr in xml format? And is it depends on servers xml > compatibility?? > > Thanks in advance. > > Regards, > Rajat > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > From owner-ietf-whois Thu Aug 19 08:32:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFWwPY014392; Thu, 19 Aug 2004 08:32:58 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JFWwlc014391; Thu, 19 Aug 2004 08:32:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JFWvJc014367 for ; Thu, 19 Aug 2004 08:32:57 -0700 (PDT) (envelope-from paf@cisco.com) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Aug 2004 17:42:38 +0200 X-BrightmailFiltered: true Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7JFWmuS005711; Thu, 19 Aug 2004 17:32:49 +0200 (MEST) Received: from xfe-lon-302.cisco.com ([64.103.98.18]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Aug 2004 16:34:26 +0100 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-lon-302.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Aug 2004 16:32:47 +0100 In-Reply-To: <20040819105925.62311.qmail@web50706.mail.yahoo.com> References: <20040819105925.62311.qmail@web50706.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <02424C7E-F1F5-11D8-907B-000A95B2B926@cisco.com> Content-Transfer-Encoding: 7bit Cc: ietf-whois@imc.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Regarding whois query in xml format Date: Thu, 19 Aug 2004 08:32:41 -0700 To: Rajat X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 19 Aug 2004 15:32:48.0039 (UTC) FILETIME=[C7EB4370:01C48601] Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Aug 19, 2004, at 03:59, Rajat wrote: > Is there any way to get the response in proper xml > format. No...unfortunately no. No standardized way. Some whois servers might have a different interface, but there is no standard. paf From owner-ietf-whois Thu Aug 19 09:17:31 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGHVDf022020; Thu, 19 Aug 2004 09:17:31 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JGHVvx022019; Thu, 19 Aug 2004 09:17:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from mail.rcaconsulting.it (194-185-52-42.f5.ngi.it [194.185.52.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGHU98022012 for ; Thu, 19 Aug 2004 09:17:30 -0700 (PDT) (envelope-from bulldog@rcart.com) Received: from smtp.rcart.it ([194.185.52.42]) by mail.rcaconsulting.it with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 19 Aug 2004 18:17:33 +0200 Received: from smtp.rcart.com ([194.185.52.44]) by smtp.rcart.it with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 19 Aug 2004 18:17:33 +0200 Received: from flex01 ([194.185.52.45]) by smtp.rcart.com with RCA Consulting RCAS (0, 7, 0, 0); Thu, 19 Aug 2004 18:17:33 +0200 Message-ID: <002d01c48608$076c1280$3f44000a@lan1.adslgw.encryption.it> Reply-To: "Francesco ORLANDO" From: "Francesco ORLANDO" To: References: <20040819105925.62311.qmail@web50706.mail.yahoo.com> Subject: Re: Regarding whois query in xml format Date: Thu, 19 Aug 2004 18:17:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7JGHV98022013 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Rajat, ----- Original Message ----- From: "Rajat" To: Sent: Thursday, August 19, 2004 12:59 PM Subject: Regarding whois query in xml format | | Hello all, | I am in process of finding the location of a given IP | address. do You mean "the country of a given IP"? or do You mean "the responsible person of a given IP"? Country= simply look at http://countries.nerd.dk RP= You may use Sam Spade http://www.samspade.org (or a classical human-readable query ;-) | So I made some queries to the whois | servers(using TCP@43), but whatever response I got is | in human readable text formate. You're human and You've received human-readable data... ;-) That sounds good for me, because the whois-bulk-access MUST be restricted for anti-spam purposes! Please, read that document: http://www.pfir.org/statements/whois-access | I am not able to parse the response and get the | relevent information. | OT: I've developed a whois-parser that export the results of a whois query in XML format and that's running as a secured and restricted-access web service for internal use only. BUT, I've intentionally limited my service to serve max 10queries/hour to avoid *internal* "abuse"... /OT | Is there any way to get the response in proper xml | format. So that I can easily parse it. ??? What are the purposes of that "parsing of whois data"? | Thanks in advance. | | Regards, | Rajat | best regards, Francesco From owner-ietf-whois Thu Aug 19 09:17:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGHC5d021979; Thu, 19 Aug 2004 09:17:12 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JGHCLr021972; Thu, 19 Aug 2004 09:17:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from mail.rcaconsulting.it (194-185-52-42.f5.ngi.it [194.185.52.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JGHAoS021956 for ; Thu, 19 Aug 2004 09:17:11 -0700 (PDT) (envelope-from bulldog@rcart.com) Received: from smtp.rcart.it ([194.185.52.42]) by mail.rcaconsulting.it with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 19 Aug 2004 18:17:09 +0200 Received: from smtp.rcart.com ([194.185.52.44]) by smtp.rcart.it with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 19 Aug 2004 18:17:09 +0200 Received: from flex01 ([194.185.52.45]) by smtp.rcart.com with RCA Consulting RCAS (0, 7, 0, 0); Thu, 19 Aug 2004 18:17:09 +0200 Message-ID: <002c01c48607$f8f89430$3f44000a@lan1.adslgw.encryption.it> Reply-To: "Francesco ORLANDO" From: "Francesco ORLANDO" To: References: <20040819105925.62311.qmail@web50706.mail.yahoo.com> Subject: Re: Regarding whois query in xml format Date: Thu, 19 Aug 2004 18:17:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7JGHCoS021967 Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Rajat, ----- Original Message ----- From: "Rajat" To: Sent: Thursday, August 19, 2004 12:59 PM Subject: Regarding whois query in xml format | | Hello all, | I am in process of finding the location of a given IP | address. do You mean "the country of a given IP"? or do You mean "the responsible person of a given IP"? Country= simply look at http://countries.nerd.dk RP= You may use Sam Spade http://www.samspade.org (or a classical human-readable query ;-) | So I made some queries to the whois | servers(using TCP@43), but whatever response I got is | in human readable text formate. You're human and You've received human-readable data... ;-) That sounds good for me, because the whois-bulk-access MUST be restricted for anti-spam purposes! Please, read that document: http://www.pfir.org/statements/whois-access | I am not able to parse the response and get the | relevent information. | OT: I've developed a whois-parser that export the results of a whois query in XML format and that's running as a secured and restricted-access web service for internal use only. BUT, I've intentionally limited my service to serve max 10queries/hour to avoid *internal* "abuse"... /OT | Is there any way to get the response in proper xml | format. So that I can easily parse it. ??? What are the purposes of that "parsing of whois data"? | Thanks in advance. | | Regards, | Rajat | best regards, Francesco From owner-ietf-whois Thu Aug 19 16:51:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JNpKtu093715; Thu, 19 Aug 2004 16:51:20 -0700 (PDT) (envelope-from owner-ietf-whois@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7JNpKfu093714; Thu, 19 Aug 2004 16:51:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-whois@mail.imc.org using -f Received: from hexillion.com (iml105.datareturn.com [216.46.253.232]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7JNpJ4b093705 for ; Thu, 19 Aug 2004 16:51:19 -0700 (PDT) (envelope-from gavin@hexillion.com) Received: from rigel [206.176.128.122] by hexillion.com with ESMTP (SMTPD32-6.06) id A26A612300B0; Thu, 19 Aug 2004 19:14:34 -0500 From: "Gavin Williams (Hexillion)" Organization: Hexillion Technologies To: Rajat Date: Thu, 19 Aug 2004 18:51:20 -0500 MIME-Version: 1.0 Subject: Re: Regarding whois query in xml format Reply-to: Gavin Williams CC: ietf-whois@imc.org Message-ID: <4124F6A8.1747.18883E33@localhost> In-reply-to: <20040819105925.62311.qmail@web50706.mail.yahoo.com> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: owner-ietf-whois@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Rajat, > Is there any way to get the response in proper xml > format. So that I can easily parse it. I got one mail > in a message archive, in that it was stated that if we > sand whois query in XML format then will get the > response in XML format only. Other wise simple text > response will be returned. > > Does any body know that how we can query the whois > srevr in xml format? And is it depends on servers xml > compatibility?? As others on the list have indicated, the Whois servers will not return a standard XML format. However, since you asked, I will point out that my company provides commercial Whois software and proxy services that do return Whois information in XML format. Here are a couple demo links: http://www.hexillion.com/samples/WhoisXML/?query=yahoo.com http://www.hexillion.com/samples/WhoisXML/?query=66.94.231.98 More information here: http://www.Hexillion.com/whois/ We have a paid service (not mentioned on the site yet) that works almost exactly like the demo. You can query our server for IP addresses or domain names and get XML results. The terms of use forbid using the service to build mailing lists. Feel free to contact me off-list if you want to know more. For those who are curious, the demo (and all our online utilities) have fairly strict usage limits in place. Our customers are mostly Internet security firms, anti-spam companies, and government agencies looking to automate their investigation and analysis processes. -- Gavin Williams, technical director Hexillion Technologies gavin@hexillion.com http://www.hexillion.com/