From John.Mazzella at qwest.com Fri May 2 19:05:58 2003 From: John.Mazzella at qwest.com (Mazzella, John N) Date: Fri, 2 May 2003 17:05:58 -0600 Subject: [dbwg] ORG POC enforcement change? Message-ID: <49F78F5E3F07D511818200508B5C785108CC95BB@BALNTEX001.qwest.net> > Hostmaster, > > I apologize for being new to this newsgroup, and I'm certain that this > thread has already been asked and answered, but I had a question regarding > the recent enforcement of ORG ADmin and Tech POCs under each ORG ID. Is > it possible to have ARIN inherit the ORG POC from REASSIGN / REALLOCATE > swip, to fill in the gaps in the customer incomplete ORG ID. If there > already exists either the ADmin or Tech POC, or if both POCs exist, then > no inheritance would occur; the pre-existing POCs would be preserved. > > Thank you, > John Mazzella > Qwest IP Group From ipadmin at qwest.com Tue May 6 19:19:14 2003 From: ipadmin at qwest.com (IP Admin) Date: Tue, 6 May 2003 17:19:14 -0600 Subject: [dbwg] ORG POC Enforcement Solution Message-ID: <49F78F5E3F07D511818200508B5C785108CC95DA@BALNTEX001.qwest.net> DBWG, Upon re-reading my email below, allow me to add some additional details to my request: 1) Last August 2002, ARIN introduced the concept of "ORG ID" and created several thousand incomplete ORG IDs out of the old Maintainer IDs. These are the troublesome ORG IDs, because all of the new ORG IDs created post-August 2002 via REASSIGN and REALLOCATE are already populated with ORG POCs from within these swips. 2) After ARIN's recent meeting this Spring 2003, ARIN wants to populate all ORG IDs with Admin/Tech POCs. 3) ARIN has put this onus on the ISP's as of May 1, 2003. 4) Two ways to POCulate these matchbox ORG IDs are: a) ask ARIN to send us an enormous list of ORG IDs needing POCs that are downstream to each ISP. This solution will require herculean efforts to clean up by the ISP, and it will either require thousands of hand-built swips or it will be expensive to design an automated solution. Neither option here is preferable. b) ask ARIN to use the ORG POC information from our swips to fill in the gaps in an incomplete or empty ORG ID. i) if the ORG ID contains both POCs, there is no issue, the swip is not failed. ii) if the ORG ID contains only one POC or none of the POCs, use the ORG POC information for one or both POCs. iii) pre-existing POCs will remain untouched and will not be overwritten. I think that 4b) above is the preferred solution: - it brings the matchbox ORG IDs into alignment with the new ORG IDs created post-August 2002 - it requires absolutely no new automation from the ISPs who already automate the swips - it satisfies the intention of the ISP to correctly and completely populate the ORG IDs under its jurisdiction - it simplifes ARIN's initiative to verify POC info on all ORG IDs; ARIN benefits from reviewing POC info that has already passed through the verification processes from the ISPs. I know that the ARIN database is not designed for 4b) today but I wanted to place this request with ARIN in the hopes that it can be implemented soon. Again, I am certain that my question has been asked and answered, so if there is a thread on ARIN's databases somewhere, please send it along because I cannot find it. I invite everyone to send feedback, hopefully no flames. However, we maintain that it is the intention of the ISP who submits downstream REASSIGN and REALLOCATE to populate pre-existing ORG IDs with the ORG POCs from within these swips. Thank you, John Mazzella Qwest IP Group -----Original Message----- From: Mazzella, John N [mailto:John.Mazzella at qwest.com] Sent: Friday, May 02, 2003 7:06 PM To: 'dbwg at arin.net' Subject: [dbwg] ORG POC enforcement change? > Hostmaster, > > I apologize for being new to this newsgroup, and I'm certain that this > thread has already been asked and answered, but I had a question regarding > the recent enforcement of ORG ADmin and Tech POCs under each ORG ID. Is > it possible to have ARIN inherit the ORG POC from REASSIGN / REALLOCATE > swip, to fill in the gaps in the customer incomplete ORG ID. If there > already exists either the ADmin or Tech POC, or if both POCs exist, then > no inheritance would occur; the pre-existing POCs would be preserved. > > Thank you, > John Mazzella > Qwest IP Group From einar.bohlin at mci.com Thu May 8 15:42:39 2003 From: einar.bohlin at mci.com (Einar Bohlin) Date: Thu, 8 May 2003 15:42:39 -0400 (EDT) Subject: [dbwg] ORG POC Enforcement Solution In-Reply-To: <49F78F5E3F07D511818200508B5C785108CC95DA@BALNTEX001.qwest.net> Message-ID: Hi John, I've seen a few failed reassign detailed templates this week too. I wish ARIN had used your '4b' approach below. Regards, Einar Bohlin, IP Analyst IP Team - Ashburn Virginia - MCI/UUNET 703 886-7362 (VNET 806-7362) einar.bohlin at mci.com On Tue, 6 May 2003, IP Admin wrote: > DBWG, > > Upon re-reading my email below, allow me to add some additional details to > my request: > > 1) Last August 2002, ARIN introduced the concept of "ORG ID" and created > several thousand incomplete ORG IDs out of the old Maintainer IDs. These > are the troublesome ORG IDs, because all of the new ORG IDs created > post-August 2002 via REASSIGN and REALLOCATE are already populated with ORG > POCs from within these swips. > 2) After ARIN's recent meeting this Spring 2003, ARIN wants to populate all > ORG IDs with Admin/Tech POCs. > 3) ARIN has put this onus on the ISP's as of May 1, 2003. > 4) Two ways to POCulate these matchbox ORG IDs are: > a) ask ARIN to send us an enormous list of ORG IDs needing POCs that > are downstream to each ISP. This solution will require herculean efforts to > clean up by the ISP, and it will either require thousands of hand-built > swips or it will be expensive to design an automated solution. Neither > option here is preferable. > b) ask ARIN to use the ORG POC information from our swips to fill in > the gaps in an incomplete or empty ORG ID. > i) if the ORG ID contains both POCs, there is no issue, > the swip is not failed. > ii) if the ORG ID contains only one POC or none of the > POCs, use the ORG POC information for one or both POCs. > iii) pre-existing POCs will remain untouched and will not be > overwritten. > > I think that 4b) above is the preferred solution: > - it brings the matchbox ORG IDs into alignment with the new ORG IDs > created post-August 2002 > - it requires absolutely no new automation from the ISPs who already > automate the swips > - it satisfies the intention of the ISP to correctly and completely > populate the ORG IDs under its jurisdiction > - it simplifes ARIN's initiative to verify POC info on all ORG IDs; > ARIN benefits from reviewing POC info that has already passed through the > verification processes from the ISPs. > > I know that the ARIN database is not designed for 4b) today but I wanted to > place this request with ARIN in the hopes that it can be implemented soon. > > Again, I am certain that my question has been asked and answered, so if > there is a thread on ARIN's databases somewhere, please send it along > because I cannot find it. I invite everyone to send feedback, hopefully no > flames. > > However, we maintain that it is the intention of the ISP who submits > downstream REASSIGN and REALLOCATE to populate pre-existing ORG IDs with the > ORG POCs from within these swips. > > Thank you, > John Mazzella > Qwest IP Group > > > > -----Original Message----- > From: Mazzella, John N [mailto:John.Mazzella at qwest.com] > Sent: Friday, May 02, 2003 7:06 PM > To: 'dbwg at arin.net' > Subject: [dbwg] ORG POC enforcement change? > > > > Hostmaster, > > > > I apologize for being new to this newsgroup, and I'm certain that this > > thread has already been asked and answered, but I had a question regarding > > the recent enforcement of ORG ADmin and Tech POCs under each ORG ID. Is > > it possible to have ARIN inherit the ORG POC from REASSIGN / REALLOCATE > > swip, to fill in the gaps in the customer incomplete ORG ID. If there > > already exists either the ADmin or Tech POC, or if both POCs exist, then > > no inheritance would occur; the pre-existing POCs would be preserved. > > > > Thank you, > > John Mazzella > > Qwest IP Group > > From John.Mazzella at qwest.com Mon May 12 16:15:05 2003 From: John.Mazzella at qwest.com (Mazzella, John N) Date: Mon, 12 May 2003 14:15:05 -0600 Subject: [dbwg] ORG POC Enforcement Solution Message-ID: <49F78F5E3F07D511818200508B5C785108CC9653@BALNTEX001.qwest.net> Einar, Thanks for the feedback. So far as of May 12, we are experiencing several obstacles in getting accurate ORG POC information, primarily getting the customer to correct their own Org IDs. The learning curve is apparently quite steep. Several customers have said that they feel that this responsibility belongs to the upstream ISP, and so far none of the customers have prioritized this effort. Our pile of rejected swips keeps growing... However, our customers do provide us their POC info during the sale of their circuit; we include that info in our reassign/reallocate swips. I think that ARIN should inherit this POC info from our swips, like in 4b) below. Also I think ARIN should not combine two efforts into one: 1 - populating Org IDs with POCs 2 - verifying the POCs on all Org IDs We do due diligence in verifying the POCs on our orders, because we need a valid email and phone number so that our IP NOC will have accurate information, and this is the same info included in our swip. We also require a domain name for our automated reverse-lookup entries. We also forbid generic mailboxes, such as @yahoo.com, @hotmail.com, etc. ARIN could simply fail swips with these generic mailboxes? It sounds like you agree with 4b. It seems we have both MCI/Worldcom and Qwest in agreement with implementing 4b. Do we have enough clout to change ARIN's policy? :-) Are there any other ISPs out there who would like to chime in? Regards, John Mazzella Qwest IP Group 703.363.4139 john.mazzella at qwest.com -----Original Message----- From: Einar Bohlin [mailto:einar.bohlin at mci.com] Sent: Thursday, May 08, 2003 3:43 PM To: IP Admin Cc: 'dbwg at arin.net'; IP Leads Subject: Re: [dbwg] ORG POC Enforcement Solution Hi John, I've seen a few failed reassign detailed templates this week too. I wish ARIN had used your '4b' approach below. Regards, Einar Bohlin, IP Analyst IP Team - Ashburn Virginia - MCI/UUNET 703 886-7362 (VNET 806-7362) einar.bohlin at mci.com On Tue, 6 May 2003, IP Admin wrote: > DBWG, > > Upon re-reading my email below, allow me to add some additional details to > my request: > > 1) Last August 2002, ARIN introduced the concept of "ORG ID" and created > several thousand incomplete ORG IDs out of the old Maintainer IDs. These > are the troublesome ORG IDs, because all of the new ORG IDs created > post-August 2002 via REASSIGN and REALLOCATE are already populated with ORG > POCs from within these swips. > 2) After ARIN's recent meeting this Spring 2003, ARIN wants to populate all > ORG IDs with Admin/Tech POCs. > 3) ARIN has put this onus on the ISP's as of May 1, 2003. > 4) Two ways to POCulate these matchbox ORG IDs are: > a) ask ARIN to send us an enormous list of ORG IDs needing POCs that > are downstream to each ISP. This solution will require herculean efforts to > clean up by the ISP, and it will either require thousands of hand-built > swips or it will be expensive to design an automated solution. Neither > option here is preferable. > b) ask ARIN to use the ORG POC information from our swips to fill in > the gaps in an incomplete or empty ORG ID. > i) if the ORG ID contains both POCs, there is no issue, > the swip is not failed. > ii) if the ORG ID contains only one POC or none of the > POCs, use the ORG POC information for one or both POCs. > iii) pre-existing POCs will remain untouched and will not be > overwritten. > > I think that 4b) above is the preferred solution: > - it brings the matchbox ORG IDs into alignment with the new ORG IDs > created post-August 2002 > - it requires absolutely no new automation from the ISPs who already > automate the swips > - it satisfies the intention of the ISP to correctly and completely > populate the ORG IDs under its jurisdiction > - it simplifes ARIN's initiative to verify POC info on all ORG IDs; > ARIN benefits from reviewing POC info that has already passed through the > verification processes from the ISPs. > > I know that the ARIN database is not designed for 4b) today but I wanted to > place this request with ARIN in the hopes that it can be implemented soon. > > Again, I am certain that my question has been asked and answered, so if > there is a thread on ARIN's databases somewhere, please send it along > because I cannot find it. I invite everyone to send feedback, hopefully no > flames. > > However, we maintain that it is the intention of the ISP who submits > downstream REASSIGN and REALLOCATE to populate pre-existing ORG IDs with the > ORG POCs from within these swips. > > Thank you, > John Mazzella > Qwest IP Group > > > > -----Original Message----- > From: Mazzella, John N [mailto:John.Mazzella at qwest.com] > Sent: Friday, May 02, 2003 7:06 PM > To: 'dbwg at arin.net' > Subject: [dbwg] ORG POC enforcement change? > > > > Hostmaster, > > > > I apologize for being new to this newsgroup, and I'm certain that this > > thread has already been asked and answered, but I had a question regarding > > the recent enforcement of ORG ADmin and Tech POCs under each ORG ID. Is > > it possible to have ARIN inherit the ORG POC from REASSIGN / REALLOCATE > > swip, to fill in the gaps in the customer incomplete ORG ID. If there > > already exists either the ADmin or Tech POC, or if both POCs exist, then > > no inheritance would occur; the pre-existing POCs would be preserved. > > > > Thank you, > > John Mazzella > > Qwest IP Group > > From ebohlin at uu.net Mon May 12 17:18:54 2003 From: ebohlin at uu.net (Einar Bohlin) Date: Mon, 12 May 2003 17:18:54 -0400 (EDT) Subject: [dbwg] ORG POC Enforcement Solution In-Reply-To: <49F78F5E3F07D511818200508B5C785108CC9653@BALNTEX001.qwest.net> Message-ID: Hi John, ISPs used to make and maintain reassignments, records which the ISP owned. Since the db conversion ISPs have been making org records and attaching nets to them. The ISP still owns the net resource part, but the org record belongs to the customer. Although it seemed convenient at first to make org records for customers, I don't think that was the right approach. I believe that today the only organizations that need org records (besides direct assignments/allocations) are downstream ISPs who need to use swip and endusers who've obtained their own ASNs. Although I said I'd wished ARIN had already done 4b; I was frustrated that day with the failed swips. Upon reevaluting how swips are done, and per what I've written above, it seems to me that simples and reallocations are the way to go. We might still need to do some detailed reassignments if a customer really wanted one. But the few organizations that want or need an org record should have to make their own. Regards, Einar Bohlin, IP Analyst IP Team - Ashburn Virginia - MCI/UUNET 703 886-7362 (VNET 806-7362) einar.bohlin at mci.com On Mon, 12 May 2003, Mazzella, John N wrote: > Einar, > > Thanks for the feedback. So far as of May 12, we are experiencing several > obstacles in getting accurate ORG POC information, primarily getting the > customer to correct their own Org IDs. The learning curve is apparently > quite steep. Several customers have said that they feel that this > responsibility belongs to the upstream ISP, and so far none of the customers > have prioritized this effort. Our pile of rejected swips keeps growing... > > However, our customers do provide us their POC info during the sale of their > circuit; we include that info in our reassign/reallocate swips. I think > that ARIN should inherit this POC info from our swips, like in 4b) below. > > Also I think ARIN should not combine two efforts into one: > 1 - populating Org IDs with POCs > 2 - verifying the POCs on all Org IDs > > We do due diligence in verifying the POCs on our orders, because we need a > valid email and phone number so that our IP NOC will have accurate > information, and this is the same info included in our swip. We also > require a domain name for our automated reverse-lookup entries. We also > forbid generic mailboxes, such as @yahoo.com, @hotmail.com, etc. ARIN could > simply fail swips with these generic mailboxes? > > It sounds like you agree with 4b. It seems we have both MCI/Worldcom and > Qwest in agreement with implementing 4b. Do we have enough clout to change > ARIN's policy? :-) > > Are there any other ISPs out there who would like to chime in? > > Regards, > John Mazzella > Qwest IP Group > 703.363.4139 > john.mazzella at qwest.com > > > -----Original Message----- > From: Einar Bohlin [mailto:einar.bohlin at mci.com] > Sent: Thursday, May 08, 2003 3:43 PM > To: IP Admin > Cc: 'dbwg at arin.net'; IP Leads > Subject: Re: [dbwg] ORG POC Enforcement Solution > > > Hi John, > > I've seen a few failed reassign detailed templates > this week too. > > I wish ARIN had used your '4b' approach below. > > Regards, > > Einar Bohlin, IP Analyst > IP Team - Ashburn Virginia - MCI/UUNET > 703 886-7362 (VNET 806-7362) > einar.bohlin at mci.com > > > On Tue, 6 May 2003, IP Admin wrote: > > > DBWG, > > > > Upon re-reading my email below, allow me to add some additional details to > > my request: > > > > 1) Last August 2002, ARIN introduced the concept of "ORG ID" and created > > several thousand incomplete ORG IDs out of the old Maintainer IDs. These > > are the troublesome ORG IDs, because all of the new ORG IDs created > > post-August 2002 via REASSIGN and REALLOCATE are already populated with > ORG > > POCs from within these swips. > > 2) After ARIN's recent meeting this Spring 2003, ARIN wants to populate > all > > ORG IDs with Admin/Tech POCs. > > 3) ARIN has put this onus on the ISP's as of May 1, 2003. > > 4) Two ways to POCulate these matchbox ORG IDs are: > > a) ask ARIN to send us an enormous list of ORG IDs needing POCs that > > are downstream to each ISP. This solution will require herculean efforts > to > > clean up by the ISP, and it will either require thousands of hand-built > > swips or it will be expensive to design an automated solution. Neither > > option here is preferable. > > b) ask ARIN to use the ORG POC information from our swips to fill in > > the gaps in an incomplete or empty ORG ID. > > i) if the ORG ID contains both POCs, there is no issue, > > the swip is not failed. > > ii) if the ORG ID contains only one POC or none of the > > POCs, use the ORG POC information for one or both POCs. > > iii) pre-existing POCs will remain untouched and will not be > > overwritten. > > > > I think that 4b) above is the preferred solution: > > - it brings the matchbox ORG IDs into alignment with the new ORG IDs > > created post-August 2002 > > - it requires absolutely no new automation from the ISPs who already > > automate the swips > > - it satisfies the intention of the ISP to correctly and completely > > populate the ORG IDs under its jurisdiction > > - it simplifes ARIN's initiative to verify POC info on all ORG IDs; > > ARIN benefits from reviewing POC info that has already passed through the > > verification processes from the ISPs. > > > > I know that the ARIN database is not designed for 4b) today but I wanted > to > > place this request with ARIN in the hopes that it can be implemented soon. > > > > Again, I am certain that my question has been asked and answered, so if > > there is a thread on ARIN's databases somewhere, please send it along > > because I cannot find it. I invite everyone to send feedback, hopefully > no > > flames. > > > > However, we maintain that it is the intention of the ISP who submits > > downstream REASSIGN and REALLOCATE to populate pre-existing ORG IDs with > the > > ORG POCs from within these swips. > > > > Thank you, > > John Mazzella > > Qwest IP Group > > > > > > > > -----Original Message----- > > From: Mazzella, John N [mailto:John.Mazzella at qwest.com] > > Sent: Friday, May 02, 2003 7:06 PM > > To: 'dbwg at arin.net' > > Subject: [dbwg] ORG POC enforcement change? > > > > > > > Hostmaster, > > > > > > I apologize for being new to this newsgroup, and I'm certain that this > > > thread has already been asked and answered, but I had a question > regarding > > > the recent enforcement of ORG ADmin and Tech POCs under each ORG ID. Is > > > it possible to have ARIN inherit the ORG POC from REASSIGN / REALLOCATE > > > swip, to fill in the gaps in the customer incomplete ORG ID. If there > > > already exists either the ADmin or Tech POC, or if both POCs exist, then > > > no inheritance would occur; the pre-existing POCs would be preserved. > > > > > > Thank you, > > > John Mazzella > > > Qwest IP Group > > > > > From ginny at arin.net Wed May 14 12:41:13 2003 From: ginny at arin.net (ginny listman) Date: Wed, 14 May 2003 12:41:13 -0400 (EDT) Subject: [dbwg] Displaying Upstream POCs on Simple Reassignments Message-ID: As discussed during the Database Implementation Working Group at the Public Policy Meeting in Memphis, ARIN's WHOIS will automatically display the upstream POCs for any simple reassignment. This will be effective on Thursday May 15, 2003. Simple reassignments can be identified by having a CustName. All other delegations are identifed by having an OrgName and OrgID. Ginny Listman Director of Engineering ARIN From william at elan.net Sat May 31 09:45:10 2003 From: william at elan.net (william at elan.net) Date: Sat, 31 May 2003 06:45:10 -0700 (PDT) Subject: [dbwg] Question on unique network names for whois output. Message-ID: Today I during the ip lookup on 198.78.132.164, my whois engine coredumped. After reviewing what happened, it looks like, it first got: [whois.arin.net] Genuity GNTY-198-76 (NET-198-76-0-0-1) 198.76.0.0 - 198.79.255.255 Starlan Communications, Corp. STARLAN-128-24 (NET-198-78-128-0-1) 198.78.128.0 - 198.78.135.255 Horizon Trading LLC NET-198-78-128-0-1 (NET-198-78-132-160-1) 198.78.132.160 - 198.78.132.191 The engine is designed to then focus and do specific lookups and it looks like it worked fine with first two blocks above but it bogged on the 3rd one (see below), I'll probably adjust it to use "(NET-" as way to find corresponding network name (rather then just "NET-" which always worked before) if I can be get clear answer that all network names in (...) are always unique? I'm also wondering if the output below is considered normal or if there was some database or conversion error that so many networks are named "NET-198-78-128-0-1"? [root at sokol httpd]# whois net-198-78-128-0-1 at whois.arin.net [whois.arin.net] Starlan Communications, Corp. (STARLAN-128-24) NET-198-78-128-0-1 198.78.128.0 - 198.78.135.255 Access Global Inc NET-198-78-128-0-1 (NET-198-78-132-224-1) 198.78.132.224 - 198.78.132.255 Adam Hurtwiz NET-198-78-128-0-1 (NET-198-78-130-160-1) 198.78.130.160 - 198.78.130.175 Advance Solutions Inc. NET-198-78-128-0-1 (NET-198-78-131-224-1) 198.78.131.224 - 198.78.131.239 Alba Wheelsup International NET-198-78-128-0-1 (NET-198-78-135-128-1) 198.78.135.128 - 198.78.135.255 Alexander Capital NET-198-78-128-0-1 (NET-198-78-131-32-1) 198.78.131.32 - 198.78.131.47 Atif NET-198-78-128-0-1 (NET-198-78-130-128-1) 198.78.130.128 - 198.78.130.143 Atmind Design NET-198-78-128-0-1 (NET-198-78-130-224-1) 198.78.130.224 - 198.78.130.239 Baltic Information Technology services inc NET-198-78-128-0-1 (NET-198-78-130-112-1) 198.78.130.112 - 198.78.130.127 Blenderbox Internet Cafe NET-198-78-128-0-1 (NET-198-78-134-0-1) 198.78.134.0 - 198.78.134.63 Blenderbox, Inc. NET-198-78-128-0-1 (NET-198-78-133-0-1) 198.78.133.0 - 198.78.133.63 BYB Financial NET-198-78-128-0-1 (NET-198-78-131-48-1) 198.78.131.48 - 198.78.131.63 Coastline Capital NET-198-78-128-0-1 (NET-198-78-131-112-1) 198.78.131.112 - 198.78.131.127 Complete Network Solutions Inc. NET-198-78-128-0-1 (NET-198-78-131-192-1) 198.78.131.192 - 198.78.131.207 Cyber Professor NET-198-78-128-0-1 (NET-198-78-130-240-1) 198.78.130.240 - 198.78.130.255 Datapoint Communications Inc. NET-198-78-128-0-1 (NET-198-78-132-128-1) 198.78.132.128 - 198.78.132.159 Dencity NET-198-78-128-0-1 (NET-198-78-130-0-1) 198.78.130.0 - 198.78.130.15 Forex Capital Management NET-198-78-128-0-1 (NET-198-78-132-0-1) 198.78.132.0 - 198.78.132.31 Goodman Media Design NET-198-78-128-0-1 (NET-198-78-132-96-1) 198.78.132.96 - 198.78.132.127 Hara Glick NET-198-78-128-0-1 (NET-198-78-130-16-1) 198.78.130.16 - 198.78.130.31 Horizon Trading LLC NET-198-78-128-0-1 (NET-198-78-132-160-1) 198.78.132.160 - 198.78.132.191 IIT Inc. NET-198-78-128-0-1 (NET-198-78-131-64-1) 198.78.131.64 - 198.78.131.79 Internet Garage NET-198-78-128-0-1 (NET-198-78-134-64-1) 198.78.134.64 - 198.78.134.127 J&S Resources Inc. NET-198-78-128-0-1 (NET-198-78-132-192-1) 198.78.132.192 - 198.78.132.223 Jenro LLC NET-198-78-128-0-1 (NET-198-78-131-160-1) 198.78.131.160 - 198.78.131.175 JPS Trading NET-198-78-128-0-1 (NET-198-78-131-80-1) 198.78.131.80 - 198.78.131.95 Jump123 NET-198-78-128-0-1 (NET-198-78-130-192-1) 198.78.130.192 - 198.78.130.207 Local King Internet Cafe NET-198-78-128-0-1 (NET-198-78-134-192-1) 198.78.134.192 - 198.78.134.255 Marquis Brokerage NET-198-78-128-0-1 (NET-198-78-131-128-1) 198.78.131.128 - 198.78.131.143 Mason Young Associates NET-198-78-128-0-1 (NET-198-78-130-48-1) 198.78.130.48 - 198.78.130.111 Metro Resources Group NET-198-78-128-0-1 (NET-198-78-131-144-1) 198.78.131.144 - 198.78.131.159 Michael Onghai NET-198-78-128-0-1 (NET-198-78-130-208-1) 198.78.130.208 - 198.78.130.223 Millennium Information Group, Inc. NET-198-78-128-0-1 (NET-198-78-131-240-1) 198.78.131.240 - 198.78.131.255 Moving.com NET-198-78-128-0-1 (NET-198-78-133-64-1) 198.78.133.64 - 198.78.133.127 Nuomedia LLC NET-198-78-128-0-1 (NET-198-78-130-144-1) 198.78.130.144 - 198.78.130.159 PC Solutions Inc. NET-198-78-128-0-1 (NET-198-78-134-128-1) 198.78.134.128 - 198.78.134.191 Raw Interactive Inc. NET-198-78-128-0-1 (NET-198-78-135-0-1) 198.78.135.0 - 198.78.135.127 RBT Engineering NET-198-78-128-0-1 (NET-198-78-132-64-1) 198.78.132.64 - 198.78.132.95 Savant Trading Inc. NET-198-78-128-0-1 (NET-198-78-131-208-1) 198.78.131.208 - 198.78.131.223 SpiderWeb NET-198-78-128-0-1 (NET-198-78-130-176-1) 198.78.130.176 - 198.78.130.191 Suncomp Inc NET-198-78-128-0-1 (NET-198-78-130-32-1) 198.78.130.32 - 198.78.130.47 Tempest Consulting NET-198-78-128-0-1 (NET-198-78-131-16-1) 198.78.131.16 - 198.78.131.31 The Sporn Group Inc NET-198-78-128-0-1 (NET-198-78-131-96-1) 198.78.131.96 - 198.78.131.111 TNG Travel NET-198-78-128-0-1 (NET-198-78-131-176-1) 198.78.131.176 - 198.78.131.191 Vitcom Corp NET-198-78-128-0-1 (NET-198-78-131-0-1) 198.78.131.0 - 198.78.131.15 Wall Street Services NET-198-78-128-0-1 (NET-198-78-132-32-1) 198.78.132.32 - 198.78.132.63 From william at elan.net Sat May 31 10:16:26 2003 From: william at elan.net (william at elan.net) Date: Sat, 31 May 2003 07:16:26 -0700 (PDT) Subject: [dbwg] Re: Question on unique network names for whois output. In-Reply-To: Message-ID: Just to clarify and update, the same error happened when I tried 198.78.128.129 and the direct arin output looks like: [root at sokol httpd]# whois 198.78.128.129 at whois.arin.net [whois.arin.net] Genuity GNTY-198-76 (NET-198-76-0-0-1) 198.76.0.0 - 198.79.255.255 Starlan Communications, Corp. STARLAN-128-24 (NET-198-78-128-0-1) 198.78.128.0 - 198.78.135.255 So it saw "NET-198-78-128-0-1" as being unique name and that leads those large number of blocks. So it looks like I was wrong and my engine bogged on 2nd block and not the 3rd one and I actually already had focus set on "(NET-" and only if that not found go for "NET-" (that function is legacy of old arin whois). On Sat, 31 May 2003 william at elan.net wrote: > Today I during the ip lookup on 198.78.132.164, my whois engine coredumped. > After reviewing what happened, it looks like, it first got: > [whois.arin.net] > Genuity GNTY-198-76 (NET-198-76-0-0-1) > 198.76.0.0 - 198.79.255.255 > Starlan Communications, Corp. STARLAN-128-24 (NET-198-78-128-0-1) > 198.78.128.0 - 198.78.135.255 > Horizon Trading LLC NET-198-78-128-0-1 (NET-198-78-132-160-1) > 198.78.132.160 - 198.78.132.191 > > The engine is designed to then focus and do specific lookups and it looks > like it worked fine with first two blocks above but it bogged on the 3rd one > (see below), I'll probably adjust it to use "(NET-" as way to find > corresponding network name (rather then just "NET-" which always worked > before) if I can be get clear answer that all network names in (...) are > always unique? > > I'm also wondering if the output below is considered normal or if there > was some database or conversion error that so many networks are > named "NET-198-78-128-0-1"? > > [root at sokol httpd]# whois net-198-78-128-0-1 at whois.arin.net > [whois.arin.net] > Starlan Communications, Corp. (STARLAN-128-24) NET-198-78-128-0-1 > 198.78.128.0 - 198.78.135.255 > Access Global Inc NET-198-78-128-0-1 (NET-198-78-132-224-1) 198.78.132.224 > - 198.78.132.255 > Adam Hurtwiz NET-198-78-128-0-1 (NET-198-78-130-160-1) 198.78.130.160 - > 198.78.130.175 > Advance Solutions Inc. NET-198-78-128-0-1 (NET-198-78-131-224-1) > 198.78.131.224 - 198.78.131.239 > Alba Wheelsup International NET-198-78-128-0-1 (NET-198-78-135-128-1) > 198.78.135.128 - 198.78.135.255 > Alexander Capital NET-198-78-128-0-1 (NET-198-78-131-32-1) 198.78.131.32 - > 198.78.131.47 > Atif NET-198-78-128-0-1 (NET-198-78-130-128-1) 198.78.130.128 - > 198.78.130.143 > Atmind Design NET-198-78-128-0-1 (NET-198-78-130-224-1) 198.78.130.224 - > 198.78.130.239 > Baltic Information Technology services inc NET-198-78-128-0-1 > (NET-198-78-130-112-1) 198.78.130.112 - 198.78.130.127 > Blenderbox Internet Cafe NET-198-78-128-0-1 (NET-198-78-134-0-1) > 198.78.134.0 - 198.78.134.63 > Blenderbox, Inc. NET-198-78-128-0-1 (NET-198-78-133-0-1) 198.78.133.0 - > 198.78.133.63 > BYB Financial NET-198-78-128-0-1 (NET-198-78-131-48-1) 198.78.131.48 - > 198.78.131.63 > Coastline Capital NET-198-78-128-0-1 (NET-198-78-131-112-1) 198.78.131.112 > - 198.78.131.127 > Complete Network Solutions Inc. NET-198-78-128-0-1 (NET-198-78-131-192-1) > 198.78.131.192 - 198.78.131.207 > Cyber Professor NET-198-78-128-0-1 (NET-198-78-130-240-1) 198.78.130.240 - > 198.78.130.255 > Datapoint Communications Inc. NET-198-78-128-0-1 (NET-198-78-132-128-1) > 198.78.132.128 - 198.78.132.159 > Dencity NET-198-78-128-0-1 (NET-198-78-130-0-1) 198.78.130.0 - > 198.78.130.15 > Forex Capital Management NET-198-78-128-0-1 (NET-198-78-132-0-1) > 198.78.132.0 - 198.78.132.31 > Goodman Media Design NET-198-78-128-0-1 (NET-198-78-132-96-1) > 198.78.132.96 - 198.78.132.127 > Hara Glick NET-198-78-128-0-1 (NET-198-78-130-16-1) 198.78.130.16 - > 198.78.130.31 > Horizon Trading LLC NET-198-78-128-0-1 (NET-198-78-132-160-1) > 198.78.132.160 - 198.78.132.191 > IIT Inc. NET-198-78-128-0-1 (NET-198-78-131-64-1) 198.78.131.64 - > 198.78.131.79 > Internet Garage NET-198-78-128-0-1 (NET-198-78-134-64-1) 198.78.134.64 - > 198.78.134.127 > J&S Resources Inc. NET-198-78-128-0-1 (NET-198-78-132-192-1) > 198.78.132.192 - 198.78.132.223 > Jenro LLC NET-198-78-128-0-1 (NET-198-78-131-160-1) 198.78.131.160 - > 198.78.131.175 > JPS Trading NET-198-78-128-0-1 (NET-198-78-131-80-1) 198.78.131.80 - > 198.78.131.95 > Jump123 NET-198-78-128-0-1 (NET-198-78-130-192-1) 198.78.130.192 - > 198.78.130.207 > Local King Internet Cafe NET-198-78-128-0-1 (NET-198-78-134-192-1) > 198.78.134.192 - 198.78.134.255 > Marquis Brokerage NET-198-78-128-0-1 (NET-198-78-131-128-1) 198.78.131.128 > - 198.78.131.143 > Mason Young Associates NET-198-78-128-0-1 (NET-198-78-130-48-1) > 198.78.130.48 - 198.78.130.111 > Metro Resources Group NET-198-78-128-0-1 (NET-198-78-131-144-1) > 198.78.131.144 - 198.78.131.159 > Michael Onghai NET-198-78-128-0-1 (NET-198-78-130-208-1) 198.78.130.208 - > 198.78.130.223 > Millennium Information Group, Inc. NET-198-78-128-0-1 > (NET-198-78-131-240-1) 198.78.131.240 - 198.78.131.255 > Moving.com NET-198-78-128-0-1 (NET-198-78-133-64-1) 198.78.133.64 - > 198.78.133.127 > Nuomedia LLC NET-198-78-128-0-1 (NET-198-78-130-144-1) 198.78.130.144 - > 198.78.130.159 > PC Solutions Inc. NET-198-78-128-0-1 (NET-198-78-134-128-1) 198.78.134.128 > - 198.78.134.191 > Raw Interactive Inc. NET-198-78-128-0-1 (NET-198-78-135-0-1) 198.78.135.0 > - 198.78.135.127 > RBT Engineering NET-198-78-128-0-1 (NET-198-78-132-64-1) 198.78.132.64 - > 198.78.132.95 > Savant Trading Inc. NET-198-78-128-0-1 (NET-198-78-131-208-1) > 198.78.131.208 - 198.78.131.223 > SpiderWeb NET-198-78-128-0-1 (NET-198-78-130-176-1) 198.78.130.176 - > 198.78.130.191 > Suncomp Inc NET-198-78-128-0-1 (NET-198-78-130-32-1) 198.78.130.32 - > 198.78.130.47 > Tempest Consulting NET-198-78-128-0-1 (NET-198-78-131-16-1) 198.78.131.16 > - 198.78.131.31 > The Sporn Group Inc NET-198-78-128-0-1 (NET-198-78-131-96-1) 198.78.131.96 > - 198.78.131.111 > TNG Travel NET-198-78-128-0-1 (NET-198-78-131-176-1) 198.78.131.176 - > 198.78.131.191 > Vitcom Corp NET-198-78-128-0-1 (NET-198-78-131-0-1) 198.78.131.0 - > 198.78.131.15 > Wall Street Services NET-198-78-128-0-1 (NET-198-78-132-32-1) > 198.78.132.32 - 198.78.132.63 > > From cathym at arin.net Sat May 31 16:04:13 2003 From: cathym at arin.net (Cathy Murphy) Date: Sat, 31 May 2003 16:04:13 -0400 (EDT) Subject: [dbwg] Question on unique network names for whois output. In-Reply-To: Message-ID: Hello William, On Sat, 31 May 2003 william at elan.net wrote: > Today I during the ip lookup on 198.78.132.164, my whois engine coredumped. > After reviewing what happened, it looks like, it first got: > [whois.arin.net] > Genuity GNTY-198-76 (NET-198-76-0-0-1) > 198.76.0.0 - 198.79.255.255 > Starlan Communications, Corp. STARLAN-128-24 (NET-198-78-128-0-1) > 198.78.128.0 - 198.78.135.255 > Horizon Trading LLC NET-198-78-128-0-1 (NET-198-78-132-160-1) > 198.78.132.160 - 198.78.132.191 > > The engine is designed to then focus and do specific lookups and it looks > like it worked fine with first two blocks above but it bogged on the 3rd one > (see below), I'll probably adjust it to use "(NET-" as way to find > corresponding network name (rather then just "NET-" which always worked > before) if I can be get clear answer that all network names in (...) are > always unique? The value in parenthesis is actually the network handle, not the network name. The network handle will always be unique and can be used to pull up the network by prefacing the query with the exclamation point. So the query that would retrieved the third network on your list above is: ! NET-198-78-132-160-1 The network name is the value between the organization name and the network handle. > I'm also wondering if the output below is considered normal or if there > was some database or conversion error that so many networks are > named "NET-198-78-128-0-1"? This is not due to an error, but rather due to the registrant's selection of network names. The network name is the identifier that the registrant chooses to give the network registration, but it need not be unique. They are not prohibited from using "NET-" to begin the network name. A quick scan of the database shows more than 8400 network names that begin with "NET-". In the example above, it looks like the downstream reassignments were all registered with the parent network's handle. You can see essentially the same list of networks by doing a query for "> NET-198-78-128-0-1". There is always the possibility that a network handle is found in another search field, thus producing multiple hits. When submitting a query that you know is a network handle, it is easiest to restrict the search by using the "!". Thanks for the question. I hope this solves the problem for you. Regards, Cathy Murphy ARIN > [root at sokol httpd]# whois net-198-78-128-0-1 at whois.arin.net > [whois.arin.net] > Starlan Communications, Corp. (STARLAN-128-24) NET-198-78-128-0-1 > 198.78.128.0 - 198.78.135.255 > Access Global Inc NET-198-78-128-0-1 (NET-198-78-132-224-1) 198.78.132.224 > - 198.78.132.255 > Adam Hurtwiz NET-198-78-128-0-1 (NET-198-78-130-160-1) 198.78.130.160 - > 198.78.130.175 > Advance Solutions Inc. NET-198-78-128-0-1 (NET-198-78-131-224-1) > 198.78.131.224 - 198.78.131.239 > Alba Wheelsup International NET-198-78-128-0-1 (NET-198-78-135-128-1) > 198.78.135.128 - 198.78.135.255 > Alexander Capital NET-198-78-128-0-1 (NET-198-78-131-32-1) 198.78.131.32 - > 198.78.131.47 > Atif NET-198-78-128-0-1 (NET-198-78-130-128-1) 198.78.130.128 - > 198.78.130.143 > Atmind Design NET-198-78-128-0-1 (NET-198-78-130-224-1) 198.78.130.224 - > 198.78.130.239 > Baltic Information Technology services inc NET-198-78-128-0-1 > (NET-198-78-130-112-1) 198.78.130.112 - 198.78.130.127 > Blenderbox Internet Cafe NET-198-78-128-0-1 (NET-198-78-134-0-1) > 198.78.134.0 - 198.78.134.63 > Blenderbox, Inc. NET-198-78-128-0-1 (NET-198-78-133-0-1) 198.78.133.0 - > 198.78.133.63 > BYB Financial NET-198-78-128-0-1 (NET-198-78-131-48-1) 198.78.131.48 - > 198.78.131.63 > Coastline Capital NET-198-78-128-0-1 (NET-198-78-131-112-1) 198.78.131.112 > - 198.78.131.127 > Complete Network Solutions Inc. NET-198-78-128-0-1 (NET-198-78-131-192-1) > 198.78.131.192 - 198.78.131.207 > Cyber Professor NET-198-78-128-0-1 (NET-198-78-130-240-1) 198.78.130.240 - > 198.78.130.255 > Datapoint Communications Inc. NET-198-78-128-0-1 (NET-198-78-132-128-1) > 198.78.132.128 - 198.78.132.159 > Dencity NET-198-78-128-0-1 (NET-198-78-130-0-1) 198.78.130.0 - > 198.78.130.15 > Forex Capital Management NET-198-78-128-0-1 (NET-198-78-132-0-1) > 198.78.132.0 - 198.78.132.31 > Goodman Media Design NET-198-78-128-0-1 (NET-198-78-132-96-1) > 198.78.132.96 - 198.78.132.127 > Hara Glick NET-198-78-128-0-1 (NET-198-78-130-16-1) 198.78.130.16 - > 198.78.130.31 > Horizon Trading LLC NET-198-78-128-0-1 (NET-198-78-132-160-1) > 198.78.132.160 - 198.78.132.191 > IIT Inc. NET-198-78-128-0-1 (NET-198-78-131-64-1) 198.78.131.64 - > 198.78.131.79 > Internet Garage NET-198-78-128-0-1 (NET-198-78-134-64-1) 198.78.134.64 - > 198.78.134.127 > J&S Resources Inc. NET-198-78-128-0-1 (NET-198-78-132-192-1) > 198.78.132.192 - 198.78.132.223 > Jenro LLC NET-198-78-128-0-1 (NET-198-78-131-160-1) 198.78.131.160 - > 198.78.131.175 > JPS Trading NET-198-78-128-0-1 (NET-198-78-131-80-1) 198.78.131.80 - > 198.78.131.95 > Jump123 NET-198-78-128-0-1 (NET-198-78-130-192-1) 198.78.130.192 - > 198.78.130.207 > Local King Internet Cafe NET-198-78-128-0-1 (NET-198-78-134-192-1) > 198.78.134.192 - 198.78.134.255 > Marquis Brokerage NET-198-78-128-0-1 (NET-198-78-131-128-1) 198.78.131.128 > - 198.78.131.143 > Mason Young Associates NET-198-78-128-0-1 (NET-198-78-130-48-1) > 198.78.130.48 - 198.78.130.111 > Metro Resources Group NET-198-78-128-0-1 (NET-198-78-131-144-1) > 198.78.131.144 - 198.78.131.159 > Michael Onghai NET-198-78-128-0-1 (NET-198-78-130-208-1) 198.78.130.208 - > 198.78.130.223 > Millennium Information Group, Inc. NET-198-78-128-0-1 > (NET-198-78-131-240-1) 198.78.131.240 - 198.78.131.255 > Moving.com NET-198-78-128-0-1 (NET-198-78-133-64-1) 198.78.133.64 - > 198.78.133.127 > Nuomedia LLC NET-198-78-128-0-1 (NET-198-78-130-144-1) 198.78.130.144 - > 198.78.130.159 > PC Solutions Inc. NET-198-78-128-0-1 (NET-198-78-134-128-1) 198.78.134.128 > - 198.78.134.191 > Raw Interactive Inc. NET-198-78-128-0-1 (NET-198-78-135-0-1) 198.78.135.0 > - 198.78.135.127 > RBT Engineering NET-198-78-128-0-1 (NET-198-78-132-64-1) 198.78.132.64 - > 198.78.132.95 > Savant Trading Inc. NET-198-78-128-0-1 (NET-198-78-131-208-1) > 198.78.131.208 - 198.78.131.223 > SpiderWeb NET-198-78-128-0-1 (NET-198-78-130-176-1) 198.78.130.176 - > 198.78.130.191 > Suncomp Inc NET-198-78-128-0-1 (NET-198-78-130-32-1) 198.78.130.32 - > 198.78.130.47 > Tempest Consulting NET-198-78-128-0-1 (NET-198-78-131-16-1) 198.78.131.16 > - 198.78.131.31 > The Sporn Group Inc NET-198-78-128-0-1 (NET-198-78-131-96-1) 198.78.131.96 > - 198.78.131.111 > TNG Travel NET-198-78-128-0-1 (NET-198-78-131-176-1) 198.78.131.176 - > 198.78.131.191 > Vitcom Corp NET-198-78-128-0-1 (NET-198-78-131-0-1) 198.78.131.0 - > 198.78.131.15 > Wall Street Services NET-198-78-128-0-1 (NET-198-78-132-32-1) > 198.78.132.32 - 198.78.132.63 > >