ARIN-2017-12

Draft Policy ARIN-2017-12: POC Notification and Validation Upon Reassignment or Reallocation

Status: Under Discussion

Staff and Legal Review: 2 February 2018 | 28 February 2019

Advisory Council Shepherds: Chris Tacit, David Farmer

Join the Public Policy Mailing List

History:

Revisions:

Advisory Council Meetings:

Board of Trustees Meetings:

Presented at:

Latest Version: 7 March 2019

Problem Statement:

Some 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 prevent the situation where a POC is unwittingly and unintentionally inserted into Whois. Doing so will reduce the significant amount of time that ARIN staff spend fielding phone calls from POCs who have no idea they are in Whois.

The proposal will improve the overall POC validation situation, by ensuring that all reallocation or detailed reassignment requests are related to a pre-existing receiving organization with at least one valid POC object, and by requesting that any other existing invalid POC objects are validated.

Policy statement:

Insert one new section into NRPM 3:

3.7 POC Notification and Validation Upon Reassignment or Reallocation

When a request for reallocation or detailed reassignment is made to ARIN, the receiving organization must already be in the ARIN database and associated with at least one validated POC object. If there are no validated POC objects associated with the receiving organization, ARIN shall reject the request.

In addition to notifying the requester, ARIN will also notify, via email, all POCs associated with the receiving organization, whether the request was successful or not, and will request validation of any invalid POC objects associated with the receiving organization.

Note: Simple reassignments are made without any linkage to an organization or POC objects in the ARIN database.

##########

Earlier version

##########

Version Date: 26 February 2019

Problem Statement:

Some 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 prevent the situation where a POC is unwittingly and unintentionally inserted into Whois. Doing so will reduce the significant amount of time that ARIN staff spend fielding phone calls from POCs who have no idea they are in Whois.

The proposal will improve the overall POC validation situation, by ensuring that all reallocation or detailed reassignment requests are related to a pre-existing receiving organization with at least one valid POC object, and by requesting that any other existing invalid POC objects are validated.

Policy statement:

Insert one new section into NRPM 3:

3.7 POC Notification and Validation Upon Reassignment or Reallocation 

When a request for reallocation or detailed reassignment is made to ARIN, the receiving organization must already be in the ARIN database and linked to at least one valid POC object. If there is no valid POC object associated with the receiving organization, ARIN shall reject the request.

In addition to notifying the requester, ARIN will also notify, via email, all POCs associated with the receiving organization, whether the request was successful or not, and will request validation of any invalid POC objects associated with the receiving organization. 

Note: Simple reassignments are made without any linkage to an organization or POC objects in the ARIN database.

Timetable for implementation: Immediate

##########

ARIN STAFF & LEGAL ASSESSMENT
Draft Policy ARIN-2017-12
Require New POC Validation Upon Reassignment

Date of Assessment: 28 February 2019


  1. Summary (Staff Understanding)

Draft Policy 2017-12 NRPM section 3.7 requires that all requests for reallocation or detailed reassignment can only be made to existing organizations in the ARIN database with at least one validated POC object. This is a large change to the way we currently do business. There are several customers that have automated their reallocation/reassignment process with ARIN following the current model. These changes will add some complexity and possibly additional states to automated systems interacting with ARIN for the reallocation/detailed reassignment process. These changes will require customers requesting reallocation or detailed reassignments to gather and verify information from their customers prior to submitting their requests. These changes will provide a higher degree of privacy protection to the organizations that are having reallocations/detailed reassignments submitted on their behalf. ARIN would be required to notify all POCs requiring validation through email notification whether the request is successful or not.


  1. Comments

A. ARIN Staff Comments

  • It is recommended that the two instances of “valid POC object” in the first paragraph of section 3.7 be changed to “validated POC object”.

  • Overall these changes will result in more accurate information in the ARIN Whois database.

  • 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, initially there could be an increase in customer support calls and tickets.

  • The development effort for these changes is estimated to take 8 weeks.

  • This policy could be implemented as written.

B. ARIN General Counsel – Legal Assessment

  • No material legal risk in this policy

  1. Resource Impact

Implementation of this policy would have a large resource impact. It is estimated that it would take about 8 weeks of development work and there will need to be extensive testing performed with the community as well. It is estimated that this policy could be implemented approximately 6 months after ratification by the ARIN Board of Trustees.

  • Updated guidelines and internal procedures
  • Updated documentation on website
  • Staff training
  • Extensive engineering work will be required

  1. Proposal/Draft Policy Text Assessed

Latest Version: 26 February 2019

Problem Statement:

Some 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 prevent the situation where a POC is unwittingly and unintentionally inserted into Whois. Doing so will reduce the significant amount of time that ARIN staff spend fielding phone calls from POCs who have no idea they are in Whois.

The proposal will improve the overall POC validation situation, by ensuring that all reallocation or detailed reassignment requests are related to a pre-existing receiving organization with at least one valid POC object, and by requesting that any other existing invalid POC objects are validated.

Policy statement:

Insert one new section into NRPM 3:

3.7 POC Notification and Validation Upon Reassignment or Reallocation

When a request for reallocation or detailed reassignment is made to ARIN, the receiving organization must already be in the ARIN database and linked to at least one valid POC object. If there is no valid POC object associated with the receiving organization, ARIN shall reject the request.

In addition to notifying the requester, ARIN will also notify, via email, all POCs associated with the receiving organization, whether the request was successful or not, and will request validation of any invalid POC objects associated with the receiving organization.

Note: Simple reassignments are made without any linkage to an organization or POC objects in the ARIN database.

Comments:

Timetable for implementation: Immediate

##########

Earlier version

##########

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

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.

___

  1. 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 ifnotificationwere 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

___

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

___

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