[dbwg] ORG POC Enforcement Solution
Mazzella, John N
John.Mazzella at qwest.com
Mon May 12 16:15:05 EDT 2003
- Previous message: [dbwg] ORG POC Enforcement Solution
- Next message: [dbwg] ORG POC Enforcement Solution
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 > >
- Previous message: [dbwg] ORG POC Enforcement Solution
- Next message: [dbwg] ORG POC Enforcement Solution
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the DBWG mailing list