[dbwg] ORG POC Enforcement Solution

Mazzella, John N John.Mazzella at qwest.com
Mon May 12 16:15:05 EDT 2003


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



More information about the Dbwg mailing list