Here is my ARIN 42 meeting report for Vancouver, BC.

2017-12 Require New POC Validation Upon Reassignment

Policy Summary: This recommended draft policy requires that a POC be validated upon insertion into the ARIN database.

Discussion:  Under current policy an ISP can insert a Point of Contact (POC) record into the ARIN database without any “acceptance” by the POC.  This has led to situation where incorrect or undesired data is entered into the ARIN database for reassignment or reallocation records.  Often POCs would not know records have been inserted into the database until 1 year later when the POC is validated.  This policy requires that the POC be valid on insertion, and if the POC is not validated, then the insertion of the reassignment record is rejected by ARIN.  This policy was widely supported by the community at the meeting.

2018-1 Allow Inter-regional ASN transfers

Policy Summary: This recommended draft policy would allow ARIN to transfer ASNs to another RIR.

Discussion:  APNIC and RIPE have adopted policy changes that would permit ASNs to be transferred between RIRs.  It is understood that some organizations may wish to move or consolidate their resources in a different RIR and allowing ASN transfers would move toward this goal.  This policy was widely supported by the community at the meeting.

2018-2 Clarification to ISP Initial Allocation and Permit Renumbering

This draft policy attempts to clarify a discrepancy between the IPv4 policy and the IPv4 transfer policy around initial ISP block size, by setting the initial ISP allocation size to a /24.  (The current minimum is a /21).

Discussion:  At ARIN 40 the policy experience report noted a discrepancy in the policy on the initial ISP allocation size depending on if an ISP applied under the old IPv4 Allocation policy (section 4) or if they applied under the new IPv4 Transfer policy (section 8).  This policy attempts to fix this issue by setting the IPv4 policy to match the current methodology used in evaluating transfers.

2018-3 Remove Reallocation Requirements for Residential Market Assignments

This recommended draft policy removes a policy related to the original cable address policy.  Under the current policy cable organizations were required to create reallocation records for each market area to show utilization.

Discussion:  This policy is no longer needed as ARIN’s free pool is empty.  This only removes the requirement to create this records.  ISPs are free to create these records in ARIN’s database if they would like to do so for other reasons.  This change was supported by the community.

2018-4 Clarification on temporary sub assignments

This recommended draft policy clarifies when sub assignment records should be created.

Discussion:  In other regions, specifically RIPE, their policies required reassignments for a wide range of organizations and types of usages.  Some organizations were blocked from receiving additional allocations.  This policy clarifies that transient assignments do not need to be recorded in ARIN’s database. This change was supported by the community.

Next week is the ARIN 41 meeting in Miami, FL.     Here is my look ahead at the policies being discussed at the meeting.  We will have five recommended draft policies and three draft policies to discuss during the meeting.  If you aren’t going to be there in person check out the remote participation options.

2017-3 Update to NPRM 3.6: Annual Whois POC Validation

Policy Summary: This recommended draft policy make changes to the requirements for managing POC (Point of Contact) records in the ARIN database.

Discussion: This policy is intended increase the accuracy of the WHOIS information by removing records and removing ARIN online services if records are not updated.  This policy was discussed at the last meeting in San Jose.  This policy seems to have struck the balance between encouraging updates and not removing excess data from the database.

2017-8 Amend the Definition of Community Network

Policy Summary: This recommended draft policy changes the definition and IPv6 policies of a community network in ARIN policy.

Discussion:  The community network policy in the ARIN region has been very rarely used.  This new definition attempts to redefine the policy and update the definition of community network such that additional organizations can qualify for small blocks of resources under the community networks policy.  This policy draft also allows community networks to ISP like services (e.g. the ability to create reassignment records for customers, but does not allow community networks to create reallocation records)

2017-10 Repeal of Immediate Need Policy

Policy Summary: This recommended draft policy removes the Immediate Need policy from the IPv4 section of the policy manual.

Discussion:  The immediate need section has not been used since ARIN’s IPv4 free pool has been exhausted.  Since ARIN cannot provide addresses within 30 days this policy is not longer operative.  By removing this policy section we are simplifying the IPv4 policy.

2017-12 Require New POC Validation Upon Reassignment

Policy Summary: This recommended draft policy requires that a POC be validated upon insertion into the ARIN database.

Discussion:  Under current policy an ISP can insert a Point of Contact (POC) record into the ARIN database without any “acceptance” by the POC.  This has led to situation where incorrect or undesired data is entered into the ARIN database for reassignment or reallocation records.  Often POCs would not know records have been inserted into the database until 1 year later when the POC is validated.  This policy requires that the POC be valid on insertion, and if the POC is not validated, then the insertion of the reassignment record is rejected by ARIN.

2017-13 Remove ARIN review requirements for large IPv4 Reassignments and Reallocations

Policy Summary: This recommended draft policy removes a requirement for ARIN to review large IPv4 reassignment or reallocation records when they are inserted into the ARIN database.

Discussion:  Under current policy ARIN must review and accept a large (/18 or /19 or larger) reassignment and reallocation records.  This requirement was to ensure that all ISP organizations were following RFC2050 requirements for downstream large assignments.  Since the free pool is now empty and it is unlikely ISPs will assign large blocks this policy is extra work by ARIN that is no longer needed.  Removal of this section is also a cleanup item to the ARIN IPv4 numbering policy.

2017-9 Clarification of Initial Block Size for IPv4 ISP transfers

2018-2 Clarification to ISP Initial Allocation and Permit Renumbering

2017-9 Policy Summary: This draft policy attempts to clarify a discrepancy between the IPv4 policy and the IPv4 transfer policy around initial ISP block size, by setting the initial ISP transfer blocks size to a /21.  (The current minimum is a /24).

2018-2 Policy Summary: This draft policy attempts to clarify a discrepancy between the IPv4 policy and the IPv4 transfer policy around initial ISP block size, by setting the initial ISP allocation size to a /24.  (The current minimum is a /21).

Discussion:  At the ARIN 40 the policy experience report noted a discrepancy in the policy on the initial ISP allocation size depending on if an ISP applied under the old IPv4 Allocation policy (section 4) or if they applied under the new IPv4 Transfer policy (section 8).  These two policies take the opposite approach to rectifying this discrepancy.

2018-1 Allow Inter-regional ASN transfers

Policy Summary: This draft policy would allow ARIN to transfer ASNs to another RIR.

Discussion:  APNIC and RIPE have adopted policy changes that would permit ASNs to be transferred between RIRs.  At this time we are not aware of any usage of the current interRIR ASN transfer policy.  It is understood that some organizations may wish to move or consolidate their resources in a different RIR and allowing ASN transfers would move toward this goal.  There appear to be some technical details that still need to be considered on how to record the transfers between the RIRs and how the IANA top-level ASN registry would or would not reflect the reallocation of an ASN to a different RIR.