Recommended Draft Policy ARIN-2017-12

POC Notification and Validation Upon Reassignment or Reallocation

Status: Pending Implementation
Shepherds: Chris Tacit, David Farmer

Current Text (26 March 2019)

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

This recommended draft policy: (1) enables fair and impartial number administration as it ensures that ARIN has the means to communicate with organizations receiving reallocations or detailed reassignments, and does so in a clear, complete, concise and unambiguous manner; (2) is technically sound in that it supports ARIN’s ability to maintain the unique registration of Internet number resources; and (3) has community support.

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.

Timetable for Implementation: Immediate

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.

Comments

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.

ARIN General Counsel – Legal Assessment

  • No material legal risk in this policy

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.

The following would be needed in order to implement:

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

Proposal/Draft Policy Text Assessed: 26 March 2019 Version

History and Earlier Versions

History
Action Date
Proposal 17 October 2017
Draft Policy 21 November 2017
Revised 12 March 2018
Recommended Draft Policy 20 March 2018
Last Call 23 April 2018
Moved to Board for Review 22 May 2018
Remanded to AC 16 August 2018
Moved to Draft Policy 26 February 2019
Revised 26 February 2019
Revised 7 March 2019
Recommended Draft Policy 26 March 2019
Last Call 15 April 2019
Advanced to Board 21 May 2019
Adopted 20 June 2019