[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
> 
>