This problem is not scoped only to with a new POC is created. This was also supposed to be a check in 3.7 to insure a resource is not randomly SWIP'd to a pre-existing org.
3.8 was intended to chatch when a resource is SWIP'd to a pre-existing org, but that org ID is not used, and that org's address is put into a reassign simple. I don't see how this is not implementable.. - If the compnay name is a match for something ARIN already has a relationship with, then they should have good contact info. - If the contact info is a known address of a compnay that ARIN already has a relationship with, then they should have good contact info for that compnay. - If all else fails they can send a post card to the mailing address. At a mimimum, if the post card is undeliverable, or a holder of the the post card contacts ARIN, they should revoke the SWIP. ___Jason On Mon, Mar 12, 2018 at 5:47 PM, Christian Tacit <[email protected]> wrote: > Dear Community Members, > > > > The shepherds for the Draft Policy 2017-12: Require POC Validation Upon > Reassignment, are making two changes to its text. > > > > First, the problem statement is being expanded a bit to explain how POCs > for reassigned blocks can be assigned without the knowledge of the > individuals so assigned under the present policy. > > > > Second, proposed section 3.8 has been deleted. This is because it is > unintentionally misleading because a simple reassignment results in a > customer identifier versus an OrgID. There is no contact information > contained in a simple reassignment other than street address that could be > used for notification, and thus it does not appear that the proposed NRPM > 3.8 policy text is implementable. Even if notification were possible, the > “OR postal address” in this section may also cause significant problems for > some companies as many companies have the same name associated with many > different locations and there are several locations that have many > companies registered there. > > > > Based on these changes, the revised text reads: > > > > *Version Date: March 12, 2018* > > > > *Problem Statement:* > > Some large ISPs assign individuals to be POCs for reassigned blocks > without consultation of the individual they are inserting into Whois. For > example, during the reassignment/reallocation process, some large ISPs > automatically create POCs from their customer’s order form. This process is > automated for many ISPs and therefore the resulting POCs are not validated > prior to being created in the ARIN Whois database. This creates unknowing > POCs that have no idea what Whois is or even who ARIN is at the time they > receive the annual POC validation email. It can also create multiple POCs > per email address causing that same person to receive a multitude of POC > Validation emails each year. > > This policy proposal seeks to improve the situation where a POC is > unwittingly and unintentionally inserted into Whois. > > It also seeks to mitigate the significant amount of time that ARIN staff > reports that they spend fielding phone calls from POCs who have no idea > they are in Whois. > > Finally, it is hopeful that this proposal will improve the overall POC > validation situation, by forcing ISPs and customers to work together to > insert proper information into Whois at the time of sub-delegation. > > > > *Policy statement:* > > Insert one new section into NRPM 3: > > 3.7 New POC Validation Upon Reassignment > > When an ISP submits a valid reallocation or detailed reassignment request > to ARIN which would result in a new POC object being created, ARIN must > (before otherwise approving the request) contact the new POC by email for > validation. ARIN's notification will, at a minimum, notify the POC of: > > - the information about the organization submitting the record; and > - the resource(s) to which the POC is being attached; and > - the organization(s) to which the POC is being attached. > > If the POC validates the request, the request shall be accepted by ARIN > and the new objects inserted into Whois. If the POC does not validate the > request within 10 days, ARIN must reject the request. > > > > *Timetable for implementation:* Immediate > > > > Comments from the community are welcome! > > > > > Christian S. Tacit > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|[email protected]|571-266-0006
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
