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
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.
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
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
Please contact i...@arin.net if you experience any issues.