[arin-ppml] Draft Policy 2017-12: Require POC Validation Upon Reassignment

[Owen DeLong]

> On Mar 13, 2018, at 11:54 , Scott Leibrand <scottleibrand at gmail.com> wrote:
> 
> How do we address the risk that companies with fully automated whois-population systems simply don't bother to do that research, and their delegation ends up not getting added to whois at all?

I see that as less of a problem than the current situation. Eventually, this will result in complaints that reach
their whois contacts and/or their ARIN billing contacts.

If the billing contacts don’t respond, well, then their use of the IP addresses will become a short-term problem in most
cases.

> This may be an implementation detail, but I think we should make sure the policy allows for an option for the new POC to replace the proposed new POC object with a reference to one of their existing POC records…

Not sure how you expect that to work, but would be interested if you think you have a feasible proposal.

The devil is in the details.

You have Company A creating a POC for an individual that works at Company B and now you  want that individual from Company B to be able to ask ARIN to substitute the link on an IP block registered to Company A with an alternative POC provided by the individual from Company B. What could possibly go wrong?

Owen

> 
> -Scott
> 
> On Tue, Mar 13, 2018 at 11:07 AM, <hostmaster at uneedus.com <mailto:hostmaster at uneedus.com>> wrote:
> I support.
> 
> I think this will go a long way in getting correct POC's in the database at the start.  Currently, whoever is doing the ordering might end up with their contacts in the database, because that is the only information that the service provider has. This is how we end up with purchasing or accounting contacts in Whois who have no clue as to abuse complaints and/or the annual validation email.  This will force the service provider to actually ASK who the company wants as a Whois contact, and to explain to them what duties this involves, including a reminder of the annual validation email that they need to respond to.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> 
> On Mon, 12 Mar 2018, Christian Tacit 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 (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180314/35d9a16f/attachment.htm>