From Scott.Whipple at cox.com Wed Feb 12 10:54:45 2003 From: Scott.Whipple at cox.com (Whipple, Scott (CCI-Atlanta)) Date: Wed, 12 Feb 2003 10:54:45 -0500 Subject: [dbwg] Simple Reassignment POC Message-ID: <4B8EA05057E49E4F940B74AC3AEC23F40BB753@CATL0MS03.corp.cox.com> I would like to propose a slight change to the way simple reassignments are displayed in ARIN's whois. I recently had some of our IPs listed in a black list database (ipwhois.rfc-ignorant.org). The reason that I received was that the simple reassignments in ARINs database do not have POC information. I didn't believe this was a legitimate reason to have the IPs listed because the POC information on the parent is responsible for the simple reassignment, but this was the reason given to me. I explained to them that this was not a requirement of ARIN and that the POCs on the parent block is actually who maintains the reassignments. The only way to fix this problem was to change all my simple reassignments into detailed reassignments. What I would like to propose is that when a simple reassignment is submitted the POC information listed on the parent block be imported to the simple reassignment. So, when a query is done on a simple reassignment you will get the POC information that is responsible for the network. The POC information that is actually displayed is the same as the parent but you do get a POC without having to do two queries. Is there anyone out there that has had this type of problem? Does anyone see value in making this change? Scott From ebohlin at uu.net Wed Feb 12 11:55:49 2003 From: ebohlin at uu.net (Einar Bohlin) Date: Wed, 12 Feb 2003 11:55:49 -0500 (EST) Subject: [dbwg] Simple Reassignment POC In-Reply-To: <4B8EA05057E49E4F940B74AC3AEC23F40BB753@CATL0MS03.corp.cox.com> Message-ID: Hi, Was there some other reason they picked on you? You're not the only one using simples. We should discuss this, sure. But not not in the context of these list creators who can change their requirements any time they want. By definition the POC info for a simple reassignment is the parent block info. Yes, one has to make two whois queries to get that info. As a matter of fact there is a thread in which the rfc ignorant people addressed a smiliar issue. And they went with two whois lookups being okay. This is the same thing. Where does adding to the output stop? It could get extreme. Somebody with a list might want every IP query to include full registry info and info for IANA and/or ICANN. Finally, in RFC 2050 it says the registries determine what comprises reassignment information. And since ARIN allows reassign simple records, then simple reassignments are RFC compliant. Regards, Einar Bohlin, IP Analyst IP Team - Ashburn Virginia - WorldCom Phone: 703 886-7362 (VNET 806-7362) email: einar.bohlin at wcom.com Here's the post: http://lists.megacity.org/pipermail/rfci-discuss/2002-October/001096.html ********************************************* [RFCI-Discuss] ipwhois: ARIN's nonexistent postal addresses Derek J. Balling rfci-discuss at lists.megacity.org Mon, 7 Oct 2002 18:15:50 -0400 Previous message: [RFCI-Discuss] ipwhois: ARIN's nonexistent postal addresses Next message: [RFCI-Discuss] ipwhois: ARIN's nonexistent postal addresses Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] -------------------------------------------------------------------------------- On Monday, October 7, 2002, at 05:24 PM, Will Aoki wrote: > A whois on the OrgID will show postal addresses. I didn't find any > telephone numbers on the OrgIDs that I checked, although the contact > handles I checked have phone numbers. > > Unless the RFCs are interpreted to require address data to be returned > in the first whois query, instead of needing another query to an orgid > handle, ARIN seems no more or less compliant than it was before. Thanks for digging deeper. You're right (and I don't necessarily have a problem with the way ARIN is doing it, now that I see how they've implemented it). D ********************************************* On Wed, 12 Feb 2003, Whipple, Scott (CCI-Atlanta) wrote: > I would like to propose a slight change to the way simple reassignments are displayed in ARIN's whois. I recently had some of our IPs listed in a black list database (ipwhois.rfc-ignorant.org). The reason that I received was that the simple reassignments in ARINs database do not have POC information. I didn't believe this was a legitimate reason to have the IPs listed because the POC information on the parent is responsible for the simple reassignment, but this was the reason given to me. I explained to them that this was not a requirement of ARIN and that the POCs on the parent block is actually who maintains the reassignments. The only way to fix this problem was to change all my simple reassignments into detailed reassignments. > > What I would like to propose is that when a simple reassignment is submitted the POC information listed on the parent block be imported to the simple reassignment. So, when a query is done on a simple reassignment you will get the POC information that is responsible for the network. The POC information that is actually displayed is the same as the parent but you do get a POC without having to do two queries. > > Is there anyone out there that has had this type of problem? Does anyone see value in making this change? > > Scott > From Larry at Riedel.org Wed Feb 12 11:59:56 2003 From: Larry at Riedel.org (Larry Riedel) Date: 12 Feb 2003 16:59:56 -0000 Subject: [dbwg] Simple Reassignment POC In-Reply-To: <4B8EA05057E49E4F940B74AC3AEC23F40BB753@CATL0MS03.corp.cox.com> Message-ID: <20030212165956.26810.qmail@home19.riedel.org> > when a query is done on a simple reassignment you will get > the POC information that is responsible for the network. The > POC information that is actually displayed is the same as the > parent but you do get a POC without having to do two queries. > [...] > Does anyone see value in making this change? It makes sense to me that the same attributes are always present in the query result if there is something useful to put in their values, and inherited values override corresponding values in the parent for that query result. Larry From dredd at megacity.org Wed Feb 12 12:07:26 2003 From: dredd at megacity.org (Derek J. Balling) Date: Wed, 12 Feb 2003 12:07:26 -0500 Subject: [dbwg] Simple Reassignment POC In-Reply-To: Message-ID: <76259DE7-3EAC-11D7-A4E7-000A27AF5202@megacity.org> I'll chime in that I've had a discussion with Ginny over the last 48 hours, and we would kick around possible solutions to the problem. My concern is that there could potentially be a lot of network traffic (two, three, four recursive calls for deeply nested subassignments), requiring the WHOIS client to try to intelligently parse the output and make successive calls to the database as needed. One solution I proposed was for non-POC subassignments, perhaps the whois server could do that recursion behind the scenes and include the (parent,grandparent,etc)'s POC info as appropriate. Minimizes network traffic, minimizes calls to the DB, and requires less "intelligence" in the client and/or end-user of whois. D On Wednesday, February 12, 2003, at 11:55 AM, Einar Bohlin wrote: > Hi, > > Was there some other reason they picked on you? > You're not the only one using simples. > > We should discuss this, sure. But not not in the > context of these list creators who can change > their requirements any time they want. > > By definition the POC info for a simple > reassignment is the parent block info. > Yes, one has to make two whois queries > to get that info. > > As a matter of fact there is a thread in which > the rfc ignorant people addressed a smiliar issue. > And they went with two whois lookups being okay. This > is the same thing. > > Where does adding to the output stop? It > could get extreme. Somebody with a list might > want every IP query to include full registry > info and info for IANA and/or ICANN. > > Finally, in RFC 2050 it says the > registries determine what comprises > reassignment information. And since ARIN > allows reassign simple records, then > simple reassignments are RFC compliant. > > Regards, > > Einar Bohlin, IP Analyst > IP Team - Ashburn Virginia - WorldCom > Phone: 703 886-7362 (VNET 806-7362) > email: einar.bohlin at wcom.com > > > > Here's the post: > > http://lists.megacity.org/pipermail/rfci-discuss/2002-October/ > 001096.html > > ********************************************* > > [RFCI-Discuss] ipwhois: ARIN's nonexistent postal addresses > Derek J. Balling rfci-discuss at lists.megacity.org > Mon, 7 Oct 2002 18:15:50 -0400 > > Previous message: [RFCI-Discuss] ipwhois: ARIN's nonexistent postal > addresses > Next message: [RFCI-Discuss] ipwhois: ARIN's nonexistent postal > addresses > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > ----------------------------------------------------------------------- > --------- > > On Monday, October 7, 2002, at 05:24 PM, Will Aoki wrote: >> A whois on the OrgID will show postal addresses. I didn't find any >> telephone numbers on the OrgIDs that I checked, although the contact >> handles I checked have phone numbers. >> >> Unless the RFCs are interpreted to require address data to be returned >> in the first whois query, instead of needing another query to an orgid >> handle, ARIN seems no more or less compliant than it was before. > > Thanks for digging deeper. You're right (and I don't necessarily have a > problem with the way ARIN is doing it, now that I see how they've > implemented it). > > D > > ********************************************* > > > > > On Wed, 12 Feb 2003, Whipple, Scott (CCI-Atlanta) wrote: > >> I would like to propose a slight change to the way simple >> reassignments are displayed in ARIN's whois. I recently had some of >> our IPs listed in a black list database (ipwhois.rfc-ignorant.org). >> The reason that I received was that the simple reassignments in ARINs >> database do not have POC information. I didn't believe this was a >> legitimate reason to have the IPs listed because the POC information >> on the parent is responsible for the simple reassignment, but this >> was the reason given to me. I explained to them that this was not a >> requirement of ARIN and that the POCs on the parent block is actually >> who maintains the reassignments. The only way to fix this problem >> was to change all my simple reassignments into detailed >> reassignments. >> >> What I would like to propose is that when a simple reassignment is >> submitted the POC information listed on the parent block be imported >> to the simple reassignment. So, when a query is done on a simple >> reassignment you will get the POC information that is responsible for >> the network. The POC information that is actually displayed is the >> same as the parent but you do get a POC without having to do two >> queries. >> >> Is there anyone out there that has had this type of problem? Does >> anyone see value in making this change? >> >> Scott >> > From dredd at megacity.org Wed Feb 12 12:08:56 2003 From: dredd at megacity.org (Derek J. Balling) Date: Wed, 12 Feb 2003 12:08:56 -0500 Subject: [dbwg] Simple Reassignment POC In-Reply-To: <20030212165956.26810.qmail@home19.riedel.org> Message-ID: On Wednesday, February 12, 2003, at 11:59 AM, Larry Riedel wrote: > >> when a query is done on a simple reassignment you will get >> the POC information that is responsible for the network. The >> POC information that is actually displayed is the same as the >> parent but you do get a POC without having to do two queries. >> [...] >> Does anyone see value in making this change? > > It makes sense to me that the same attributes are always > present in the query result if there is something useful > to put in their values, and inherited values override > corresponding values in the parent for that query result. shows what I get for not paying attention, I think the OP was describing the change I just mentioned. Doh. D From Geoffrey.Camps at cw.com Tue Feb 25 12:20:29 2003 From: Geoffrey.Camps at cw.com (geoffrey camps) Date: Tue, 25 Feb 2003 09:20:29 -0800 Subject: [dbwg] WHOIS Change Announcement In-Reply-To: Message-ID: This turned out even better than I had originally anticipated. Thanks for all of the help - it's much appreciated. For all of those who are interested, Todd Caine maintains the Net::Whois::ARIN Perl module (project homepage is http://net-whois-arin.sf.net/) for easily extracting information from the ARIN WHOIS database. It appears that the code has already been updated to reflect the below changes in the WHOIS output format. -gc -----Original Message----- From: dbwg-request at arin.net [mailto:dbwg-request at arin.net]On Behalf Of ginny listman Sent: Monday, January 06, 2003 8:33 AM To: dbwg at arin.net Subject: [dbwg] WHOIS Change Announcement Based on feedback from the community, ARIN will make minor modifications to the way queries are displayed in WHOIS. This changes will be released on February 6, 2003, and include the following: 1. All "Comment:" lines will have labels. 2. All "Address:" lines will have labels. 3. Introduce new fields, "City:", "StateProv:" and "PostalCode:". 4. All network and AS queries will include the org address. Ginny Listman Director of Engineering ARIN