> On Jun 22, 2016, at 11:00 , Mike Burns <[email protected]> wrote: > > Hi Scott and Andrew, > > To me, 8.5.2 seems a little redundant considering 1.2: > > 8.5.2. Operational Use > > ARIN allocates or assigns blocks of IP addresses to organizations via > transfer solely for the purpose of use on an operational network. > > 1.2. Conservation > > The principle of conservation guarantees sustainability of the Internet > through efficient utilization of unique number resources. > > Due to the requirement for uniqueness, Internet number resources of each type > are drawn from a common number space. Conservation of these common number > spaces requires that Internet number resources be efficiently distributed to > those organizations who have a technical need for them in support of > operational networks. > > 8.5.2 goes even farther than the language in 1.2. Specifically the word > “solely” rather than “in support.” What if I don’t need them now but I will > within 24 months, is that solely for the purpose of use, or is that for > planning purposes? > > I still don’t see the purpose of this section unless it’s window dressing to > slide the no-needs minimum through. > > I think it would be improved by eliminating 8.5.2 and renumbering the rest. > > So maybe the language is a little cluttered for my taste, what with > “specified” this and that and , but I am inclined to support it as a step > forward in simplifying and incentivizing accurate registration of transfers. > > True section 8 is growing but maybe someday we can prune section 4 as we > simplify IPv4 address distribution. > Pace Owen, we should let section 4 wither away rather than cling to it. > Section 4 was for the free pool, it’s silly to retain that language and > paradigm in today’s market environment. The evidence is in, and the needs > test (especially filtered through section 4 language) is not necessary to > comply with NRPM 1.2. Conservation is provided by price and IPv6 provides all > the protection from “speculators” we need. Or maybe somehow RIPE is immune > from insidious speculation despite the lack of a needs test?
Technically, RIPE has a needs test. I’ll grant you it’s not much of one, but it probably is enough to limit speculation. Owen > > Regards, > Mike > > > From: Scott Leibrand [mailto:[email protected]] > Sent: Wednesday, June 22, 2016 12:31 PM > To: Mike Burns <[email protected]> > Cc: Andrew Dul <[email protected]>; ARIN-PPML List <[email protected]> > Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: > Post-IPv4-Free-Pool-Depletion Transfer Policy > > On Wed, Jun 22, 2016 at 11:24 AM, Mike Burns <[email protected] > <mailto:[email protected]>> wrote: >> Hi Scott, >> >> I apologize, I did not scroll down and see your other comments. >> My fault for top-posting. >> >> If recipients have to attest that they are using the addresses on an >> operational network, why do we need 8.5.2? The attestation would as you say >> prevent financial speculators from acquiring them for speculative purposes. >> >> Is the attestation required for first time initial transfers of the minimum? >> It doesn’t seem to read that way. > > 8.5.2 is the policy text that supports requiring the recipient to attest that > they are using the addresses on an operational network. If that part is > unclear, we would welcome suggestions for improving the text. There is a > further attestation in 8.5.5 as well for organizations requesting more than > the minimum. > > -Scott > >> >> >> From: Scott Leibrand [mailto:[email protected] >> <mailto:[email protected]>] >> Sent: Wednesday, June 22, 2016 12:16 PM >> To: Mike Burns <[email protected] <mailto:[email protected]>> >> Cc: Andrew Dul <[email protected] <mailto:[email protected]>>; >> ARIN-PPML List <[email protected] <mailto:[email protected]>> >> >> Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: >> Post-IPv4-Free-Pool-Depletion Transfer Policy >> >> On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns <[email protected] >> <mailto:[email protected]>> wrote: >>> Hi Andrew, >>> >>> I have a couple of questions about the policy proposal. >>> >>> On Section 8.5.2 Operational Use. >>> >>> First, why is this section even in there, does it serve some particular >>> purpose? >> >> It prevents financial speculators, who have no operational use for the >> addresses, from acquiring them for speculative purposes. >> >>> >>> Second, why does it refer to assignments and allocations in a section >>> devoted to transfers? >>> >>> Overall, do we still need the verbiage about "Specified" recipients, why >>> not just recipients? >> >> ARIN allocates or assigns blocks of IP addresses to organizations via >> transfer. An organization cannot receive a transfer directly: ARIN must >> update the registration of the allocation or assignment to reflect the >> specified recipient as the new holder. This simply reflects existing policy >> language and operational practice: nothing is changing here. >> >>> >>> And lastly for now, does this mean that new buyers will automatically >>> qualify for the minimum without any needs test? >> >> There is still a needs test, but it is now much simpler: recipients without >> any previous allocations or assignments (directly or via transfer) simply >> have to attest to the fact that the addresses are needed for use on an >> operational network. That is effectively the same as "without any needs >> test" for entities operating a network that will actually use the addresses, >> while completely locking out speculators who are unwilling to engage in >> fraud and risk losing the addresses they acquired. >> >> -Scott >> >>> >>> >>> My initial impression is positive. >>> >>> Regards, >>> Mike >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: [email protected] <mailto:[email protected]> >>> [mailto:[email protected] <mailto:[email protected]>] On >>> Behalf Of Andrew Dul >>> Sent: Wednesday, June 22, 2016 11:46 AM >>> To: [email protected] <mailto:[email protected]> >>> Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: >>> Post-IPv4-Free-Pool-Depletion Transfer Policy >>> >>> As the primary author of this draft policy, I respectfully disagree with my >>> AC colleague. >>> >>> Now that the free pool has been depleted, it is time to look toward what >>> future IPv4 (primarily transfer) policy should do. While this policy looks >>> complicated, its intention is to create a very simple transfer policy which >>> allows businesses to predictably and efficiently transfer >>> IPv4 resources to meet their requirements. >>> >>> I share with you here a redline which shows the changes that would be made >>> to section 8. >>> >>> Andrew >>> >>> On 6/21/2016 9:16 AM, Owen DeLong wrote: >>> > I am opposed to this policy proposal. >>> > >>> > Given that we are now in a world where the only way to obtain IPv4 space >>> > is through transfers, I think it makes much more sense to put policy >>> > changes for IPv4 transfers into section 4 and retain the simplified text >>> > that exists today in section 8 rather than copying most of section 4 into >>> > section 8 with revisions in the process. >>> > >>> > The likely outcome of such an exercise is to create a number of changes >>> > which may or may not be fully understood by the community. The >>> > interaction of this rewrite with other types of transferable resources >>> > (AS numbers at the moment) must also be carefully considered. >>> > >>> > If we want to change IPv4 policy, then let’s change IPv4 policy in >>> > section 4. >>> > >>> > If we want to change transfer policy for all resources, we can do that >>> > cleanly in section 8. >>> > >>> > While the NRPM may not be a perfect model of a structured document, this >>> > proposal would make it significantly worse. >>> > >>> > Owen >>> > >>> >> On Jun 21, 2016, at 09:01 , ARIN <[email protected] <mailto:[email protected]>> >>> >> wrote: >>> >> >>> >> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following >>> >> Proposal to Draft Policy status: >>> >> >>> >> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy >>> >> >>> >> This Draft Policy has been numbered and titled: >>> >> >>> >> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer >>> >> Policy >>> >> >>> >> Draft Policy ARIN-2016-5 is below and can be found at: >>> >> https://www.arin.net/policy/proposals/2016_5.html >>> >> <https://www.arin.net/policy/proposals/2016_5.html> >>> >> >>> >> You are encouraged to discuss all Draft Policies on PPML. The AC will >>> >> evaluate the discussion in order to assess the conformance of this draft >>> >> policy with ARIN's Principles of Internet number resource policy as >>> >> stated in the Policy Development Process (PDP). Specifically, these >>> >> principles are: >>> >> >>> >> > Enabling Fair and Impartial Number Resource Administration >>> >> > Technically Sound >>> >> > Supported by the Community >>> >> >>> >> The PDP can be found at: >>> >> https://www.arin.net/policy/pdp.html >>> >> <https://www.arin.net/policy/pdp.html> >>> >> >>> >> Draft Policies and Proposals under discussion can be found at: >>> >> https://www.arin.net/policy/proposals/index.html >>> >> <https://www.arin.net/policy/proposals/index.html> >>> >> >>> >> Regards, >>> >> >>> >> Communications and Member Services >>> >> American Registry for Internet Numbers (ARIN) >>> >> >>> >> ########## >>> >> >>> >> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer >>> >> Policy >>> >> >>> >> Date: 21 June 2016 >>> >> >>> >> 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 >>> >> >>> >> Transfer recipients must sign an RSA for the resources being received. >>> >> >>> >> 8.5.2. Operational Use >>> >> >>> >> ARIN allocates or assigns blocks of IP addresses to organizations via >>> >> transfer solely for the purpose of use on an operational network. >>> >> >>> >> 8.5.3. Minimum transfer size >>> >> >>> >> ARIN's minimum transfer size is a /24. >>> >> >>> >> 8.5.4. Initial block >>> >> >>> >> Organizations without direct assignments or allocations from ARIN >>> >> qualify for transfer of an initial 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 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 every block 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 ([email protected] >>> >> <mailto:[email protected]>). >>> >> Unsubscribe or manage your mailing list subscription at: >>> >> http://lists.arin.net/mailman/listinfo/arin-ppml >>> >> <http://lists.arin.net/mailman/listinfo/arin-ppml> >>> >> Please contact [email protected] <mailto:[email protected]> if you experience >>> >> any issues. >>> > _______________________________________________ >>> > PPML >>> > You are receiving this message because you are subscribed to the ARIN >>> > Public Policy Mailing List ([email protected] >>> > <mailto:[email protected]>). >>> > Unsubscribe or manage your mailing list subscription at: >>> > http://lists.arin.net/mailman/listinfo/arin-ppml >>> > <http://lists.arin.net/mailman/listinfo/arin-ppml> >>> > Please contact [email protected] <mailto:[email protected]> if you experience any >>> > issues. >>> >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List ([email protected] >>> <mailto:[email protected]>). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> <http://lists.arin.net/mailman/listinfo/arin-ppml> >>> Please contact [email protected] <mailto:[email protected]> if you experience any >>> issues. >> >> > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
