Your IP address could not be determined at this time.

Draft Policies and Proposals

Recommended Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment
Status:
Last Calll  
Discussion Tracking
Mailing List:
Formal introduction on PPML on 21 November 2017

Origin - ARIN-prop-247

Draft Policy - 21 November 2017

Revised - 12 March 2018

Recommended for Adoption - 20 March 2018

Last Call - 23 April 2018

Public Policy Mailing List
ARIN Public Policy Meeting:
ARIN Advisory Council:

AC Shepherds:
Chris Tacit, Leif Sawyer

ARIN Board of Trustees:
Revisions Implementation

Version Date: 12 March 2018

AC Assessment of Conformance with the Principles of Internet Number Resource Policy:

Recommended Draft Policy ARIN 2017-12 contributes to fair and impartial number resources administration by making it easier for ARIN to contact the correct individuals who perform the POC functions for reassigned resources, in conjunction with ARIN's administration of those resources. It is technically sound in that it ensures that the correct POCs for reassigned numbering resources are associated with those resources. There is significant community support for this recommended draft policy as written.

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

##########

Earlier version

##########

Version Date: 21 November 2017

Problem Statement:

Some large ISPs assign individuals to be POCs for reassigned blocks without consultation of the individual they are inserting into Whois. One year later, the POC is contacted by ARIN as part of Annual POC Validation policies.  The POC often does not know who ARIN is, what Whois is, and why they are in Whois.

This policy proposal seeks to improve the situation where a POC is unwittingly and unwantingly 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 two new sections 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.

3.8 Downstream Validation of Simple Reassignments

When an ISP submits a valid simple reassigment request to ARIN with an organization name OR postal address that is identical to one or more existing OrgIDs, ARIN will notify the downstream organization and obtain guidance on whether to accept the simple reassigment, or redirect it to one of the existing OrgIDs as a detailed reassignment.

Timetable for implementation: Immediate

##########

ARIN STAFF & LEGAL ASSESSMENT

Draft Policy ARIN-2017-12

Require New POC Validation Upon Reassignment

https://arin.net/policy/proposals/2017_12.html

Date of Assessment:  2 February 2018

___

1.  Summary (Staff Understanding)

Draft Policy 2017-12 NRPM section 3.7 requires that all requests for reallocation or detailed reassignment that will result in the creation of a new POC object be validated by ARIN prior to approving the request. Validation will be accomplished by contacting the new POC by email. If the contacted POC fails to validate within 10 days ARIN will reject the request. This is a very big change to current business processes. In addition, Section 3.8 in the Draft Policy requires staff to notify an organization in a simple reassignment if either the organization name or address is identical to an existing OrgID for the purpose of obtaining guidance as to approve the simple reassignment or redirect it to an existing OrgID as a detailed reassignment.

___

2.  Comments

A.  ARIN Staff Comments

* The problem statement is vague as to the actual reassignment process which creates the problem. Recommend additional wording that more accurately describes how a POC is created during the reassignment process. Example language could be something like: 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.

* The proposed NRPM 3.7 policy text represents a very significant change to current operations. The largest impact would be on the ARIN Engineering department. This is a major engineering effort and will involve significant testing with the community using this new model. This work has been estimated to take at least 6 months for the planning and development work which does not include the testing and interaction with the community. When the work is completed, there will have to be a period of time where ISP's will have to retool their applications that interface with ARIN before this new system is to be placed into production. At the point this is put into production, all current systems developed by ARIN customers will have to be updated in order to continue working with the new states introduced by this policy. 

* Draft Policy NRPM section 3.7 would not have a direct effect on RSD operations as far as processing the requests for reallocations and detailed reassignments due to the fact that they are automated; however, there would be a significant increase in customer support calls and tickets.  A conservative estimate would suggest that at least 50% of these requests would require some type of manual follow up from/with the person receiving the validation email. This increase in interaction with organizations that do not have a direct relationship with ARIN could result in the need for additional staffing within RSD.  

* One possible improvement in business processes regarding the NRPM section 3.7 proposed policy text would be if the policy text specified that the Org's Abuse contact would be put on the reallocation or detailed reassignment record and then the request approved.  ARIN would issue notification to the proposed new contact and if the new contact validated, the new validated contact record would replace the abuse contact on the reallocation or reassignment.

* This change would result in reducing the number of POCs associated with a single email which would reduce the number of POC validation requests each email receives annually. Today there are several emails that have multiple POCs associated. Here are the numbers from our database: 

Total email addresses    465,529

Email with 5-9 POCs         15,721 

Email with 10-24 POCs      4,638

Email with >25 POCs           1,261

* It is worth noting that if Draft Policy 2017-03 is adopted which eliminates the requirement for annual POC validation for detailed reassignments that approximately 77% of the current POC validation load is eliminated:

Networks in Whois requiring POC validation:

Direct Allocation 23,665 (04%)

Direct Assignment 35,755 (05%)

Reallocation 89,612 (14%)

Detailed Reassignments 511,637 (77%)

* The wording in Draft Policy NRPM section 3.8 is 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.  Note also that 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.

* This policy could not be implemented as written, but could be implemented with significant effort if the proposed NRPM 3.8 section was removed.

B.  ARIN General Counsel – Legal Assessment

 * No material legal risk in this policy

___

3.  Resource Impact

 

Implementation of this policy would have extreme resource impact. It is estimated that it would take over 6 ½ months of development work. There will need to be extensive testing performed with the community as well.

* Updated guidelines and internal procedures

* Staff training

* Extensive engineering work will be required

___

4. Proposal/Draft Policy Text Assessed

Draft Policy 2017-12: Require New POC Validation Upon Reassignment

Version Date: 21 November 2017

Problem Statement:

Some large ISPs assign individuals to be POCs for reassigned blocks without consultation of the individual they are inserting into Whois. One year later, the POC is contacted by ARIN as part of Annual POC Validation policies.  The POC often does not know who ARIN is, what Whois is, and why they are in Whois. 

This policy proposal seeks to improve the situation where a POC is unwittingly and unwantingly 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 two new sections 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.

3.8 Downstream Validation of Simple Reassignments

When an ISP submits a valid simple reassigment request to ARIN with an organization name OR postal address that is identical to one or more existing OrgIDs, ARIN will notify the downstream organization and obtain guidance on whether to accept the simple reassigment, or redirect it to one of the existing OrgIDs as a detailed reassignment. 

Search Related Content

full site search.