[arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
Steven Ryerse
SRyerse at eclipse-networks.com
Mon Oct 31 15:49:12 EDT 2016
With all due respect, we have been at runout for about a year. There are lots of Legacy blocks being transferred from a willing seller to a willing buyer where an RSA gets signed as part of the process. Money changes hands in these transactions and ARIN gets a fee as well. Why do we need to try and stop or slow down transfers that go thru proper ARIN channels? Why can't we just make it reasonably easy for the market to take care of Needs and let ARIN process and manage the resources in the database going forward. Everyone wins in this scenario.
The time will come where the readily available supply of Legacy blocks will be mostly used up and then all of these policies will make it even harder to get resources. I think the time has come that ARIN should be trying to make it easier to get resources. With runout I see no real harm in making transfers easier and not harder.
+1
Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA 30338
770.656.1460 - Cell
770.399.9099 - Office
770.392.0076 - Fax
℠ Eclipse Networks, Inc.
Conquering Complex Networks℠
-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Richard J. Letts
Sent: Monday, October 31, 2016 11:59 AM
To: ARIN <info at arin.net>; arin-ppml at arin.net
Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
Following Owen's opposition to this I decided to have a look.
This is probably not relevant to many of my users so I'd not looked in detail at this.
I'm going to note that the NRPM is improperly called the Number Policy Resource Manual on the first line of the problem statement, which makes me wonder how many other errors there are in the rest of the document, or how closely this has been read by others?
I'm bothered by a proposal that has a problem statement
"Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.
"
And then goes on to to
"Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM."
If section 4 is not relevant, then modify that, and not section 8
8.2:
What incentive do I have for doing this? i.e. transferring assets between entities.
Ah! it allows though M&A for entities to accumulate more resources than they would otherwise be able to.
And provides no enforcement for the return of resources.
Hmmm... looks like a problem to me.
The other sections then exclude resources acquired through M&A activities from evaluation.
If I had looked at this previously I would have removed 'This restriction does not include M&A transfers.' From 8.3-8.5
So, I'm going to come down as opposed to this.
Richard Letts
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On Behalf Of ARIN
> Sent: Wednesday, October 26, 2016 2:17 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5:
> Post-IPv4-Free-Pool-Depletion Transfer Policy
>
> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to
> send Recommended Draft Policy ARIN-2016-5:
> Post-IPv4-Free-Pool-Depletion Transfer Policy to Last Call:
>
> The AC provided the following statement to the community:
>
> This proposal is technically sound, fair, and impartial in that it
> establishes a new set of qualifying criteria for 8.3 and 8.4 transfers
> applicable to all requests. It is strongly supported by the community.
>
> Feedback is encouraged during the Last Call period. All comments
> should be provided to the Public Policy Mailing List. This Last Call
> will expire on 9 November 2016. After Last Call, the AC will conduct their Last Call review.
>
> The full text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
> Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion
> Transfer Policy
>
> AC's assessment of conformance with the Principles of Internet Number
> Resource Policy:
>
> 2016-5 is one of a set of overlapping policies involving
> simplification of section
> 8 specified transfer policy. Each takes a somewhat different approach,
> and all have a degree of community support. Based on community
> feedback at the upcoming ARIN 38 meeting in Dallas, we hope to advance
> whichever of those proposals is best-supported by the community, or
> craft and advance a unified proposal that incorporates the best
> attributes of the proposals currently on the docket. Moving 2016-5 to
> Recommended Draft will facilitate moving the best policy forward in a timely manner.
>
> Problem Statement:
>
> Section 4 of the Number Policy Resource Manual was developed over the
> past 15+ years primarily to conservatively manage the IPv4 number free pool.
> Since the IPv4 free pool was depleted in 2015, the policies which
> developed since ARIN’s inception may now not be as relevant now that
> the primary function of the registry, with regard to IPv4 numbers, is to record transfers.
>
> Since section 4 of the NRPM now contains many use cases that are not
> as relevant, it makes sense to streamline the transfer process and to
> specifically outline the criteria that should be used to process transfers.
>
> Therefore, we propose the following rewrite of the transfer policy,
> section 8 of the NRPM.
>
> The goals of this rewrite are as follows:
>
> - Separate the criteria that is found in section 4 of the NRPM from
> the transfer process.
> - Provide a clear set of criteria that should be applied across all IPv4 transfers.
> - Lower the thresholds on utilization and future allocation size to
> negate the necessity of the corner cases which are currently
> enumerated in section 4 of the NRPM.
> - Reduce the complexity that is currently required for transfers, by
> applying simpler utilization criteria for current usage, and future allocation sizing.
>
> Policy statement:
>
> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.
>
> 8.2. Mergers, Acquisitions, and Reorganizations
>
> ARIN will consider requests for the transfer of number resources in
> the case of mergers, acquisitions, and reorganizations under the
> following
> conditions:
>
> - The current registrant must not be involved in any dispute as to the
> status of the resources to be transferred.
> - The new entity must sign an RSA covering all resources to be transferred.
> - The resources to be transferred will be subject to ARIN policies.
> - The minimum transfer size is the smaller of the original allocation
> size or the applicable minimum allocation size in current policy.
> - For mergers and acquisition transfers, the recipient entity must
> provide evidence that they have acquired assets that use the resources
> to be transferred from the current registrant. ARIN will maintain an
> up-to-date list of acceptable types of documentation.
> ARIN will proceed with processing transfer requests even if the number
> resources of the combined organizations exceed what can be justified
> under current ARIN transfer policy as defined in section 8.5. In that
> event, ARIN will work with the resource holder(s) to transfer the
> extra number resources to other organization(s) or accept a voluntary
> return of the extra number resources to ARIN.
>
> 8.3. Transfers between Specified Recipients within the ARIN Region
>
> In addition to transfers under section 8.2, IPv4 numbers resources and
> ASNs may be transferred according to the following conditions.
>
> Conditions on source of the transfer:
>
> - The source entity must be the current registered holder of the IPv4
> address resources, and not be involved in any dispute as to the status
> of those resources.
> - The source entity must not have received a transfer, allocation, or
> assignment of IPv4 number resources from ARIN for the 12 months prior
> to the approval of a transfer request. This restriction does not
> include M&A transfers.
> Conditions on recipient of the transfer:
>
> - The recipients must meet the transfer requirements as defined in
> section 8.5.
> - The resources transferred will be subject to current ARIN policies.
> 8.4. Inter-RIR Transfers to Specified Recipients
>
> Inter-regional transfers may take place only via RIRs who agree to the
> transfer and share reciprocal, compatible, needs-based policies.
>
> Conditions on source of the transfer:
>
> - The source entity must be the current rights holder of the IPv4
> address resources recognized by the RIR responsible for the resources,
> and not be involved in any dispute as to the status of those resources.
> - Source entities outside of the ARIN region must meet any
> requirements defined by the RIR where the source entity holds the registration.
> - Source entities within the ARIN region must not have received a
> transfer, allocation, or assignment of IPv4 number resources from ARIN
> for the 12 months prior to the approval of a transfer request. This
> restriction does not include M&A transfers.
>
> Conditions on recipient of the transfer:
>
> - The conditions on a recipient outside of the ARIN region will be
> defined by the policies of the receiving RIR.
> - Recipients within the ARIN region must meet the transfer
> requirements as defined in section 8.5.
> - Recipients within the ARIN region will be subject to current ARIN policies.
> 8.5. Specified Transfer Recipient Requirements
>
> 8.5.1. Registration Services Agreement
>
> The receiving entity must sign an RSA covering all resources to be
> transferred unless that entity has a current (within the last two
> versions) RSA on file.
>
> 8.5.2. Operational Use
>
> ARIN allocates or assigns number resources to organizations via
> transfer solely for the purpose of use on an operational network.
>
> 8.5.3. Minimum transfer size
>
> ARIN’s minimum IPv4 transfer size is a /24.
>
> 8.5.4. Initial block
>
> Organizations without direct assignments or allocations from ARIN
> qualify for transfer of an initial IPv4 block of ARIN’s minimum transfer size.
>
> 8.5.5. Block size
>
> Organizations may qualify for the transfer of a larger initial block,
> or an additional block, by providing documentation to ARIN which
> details the use of at least 50% of the requested IPv4 block size
> within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
>
> 8.5.6. Efficient utilization of previous blocks
>
> Organizations with direct assignments or allocations from ARIN must
> have efficiently utilized at least 50% of their cumulative IPv4
> address blocks in order to receive additional space. This includes all
> space reassigned to their customers.
>
> Comments:
>
> Timetable for implementation: immediately
>
> Anything else: A redline has been provided to help the community
> understand the changes that have been made to the NRPM.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML
mailing list