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.