> On Dec 15, 2020, at 3:49 PM, Mike Burns <[email protected]> wrote: > > Hi Owen, > > I thought I had replied to this, but maybe not. Answer below your snippet. > > > "Playing devils advocate for a moment, how would we prevent either of the > following abuse scenarios: > > 1. This allows virtually any ORG to acquire 1.125x their current holdings and > use all of the > addresses (smaller block + original holdings). > > 2. An ORG considering selling some (or all) of its IPv4 holdings decides that > a 1.125x > multiplier on their ROI is appealing and even though they don’t need the > space for > renumbering, chooses to take this option as a way to get a revenue bump." > > > 1. Wrong, this would only allow an ORG to acquire a maximum 0.125X their > current holdings eligible for transfer, without a needs-test.
By 1.125 I was meaning to state that they would have their original 1x + 0.125X newly acquired = 1.125X. > 2. That ORG dreaming of a multiplier would have to purchase the 0.125X and > then turn around and sell it yielding no revenue bump and no incentive for > abuse. This assumes that IPv4 prices are flat and/or that they don’t locate some sort of low-cost source for an arbitrage opportunity (e.g. waitlist). > To my mind the issue is that people can purchase 1/8th of their current > holdings without a needs test. > Not much of an issue considering every transfer in RIPE, far more than ARIN > in number, was done without a needs-test. > And those who choose this option are precluded from further needs-free > purchases forever until they sell 8 times what they purchased. Let’s consider (e.g.) a company engaged in leasing which is holding the equivalent of a /10. Under the proposal, without restrictions, they’d be able to acquire an additional /13 and continue to use the /10 + /13 for leasing with the only consequence being that they couldn’t acquire more space through an ARIN transfer until they divested of a /10 equivalent. > There might be other abuse vectors but I don't think these are worrisome, and > what's more you neglected to address the whole issue of how these > swap-desirous members are able to justify the small block unless they spin up > a new, resource-free ORG. These are colleges with old class B's who need a > /24 for the most part. They can't justify the /24 as things stand, making the > rest of the policy as written moot. I know that organizations have been getting smaller blocks for these kinds of transactions. Frankly, if we can cap the small block at /22, I’m a lot less concerned about this as an abuse vector. However, without limitation, the above scenario still concerns me. I don’t honestly know which section of the NRPM ARIN is using to facilitate these small block transfers currently. It does seem like a place where the policy falls short and I’ll look into adding language to the proposal to support that. OWen > > Regards, > Mike > > > > ---- On Tue, 15 Dec 2020 17:34:41 -0500 Owen DeLong <[email protected]> wrote > ---- > > > > > On Dec 15, 2020, at 1:32 PM, Mike Burns <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Owen, > > > > Thanks for spurring conversation on this proposal. > > > > In my experience those who frequently want to acquire a small block to > > renumber into are holders of much-larger blocks who can realize higher > > prices if they sell their much-larger block intact. The market is rewarding > > larger block sizes with higher unit prices these days. > > > > But how can they justify the small block they need to renumber into, since > > they usually have many more addresses than they are currently using? > > > > The workaround of a second ORG made it easier for the second ORG to acquire > > space, as it had none. > > > > But if we just adopt this policy language, the problem of the acquisition > > of the smaller block remains. > > I would likely advise my clients to choose the workaround. > > > > Actually I think the policy intention is good but it should be implemented > > in a different way. > > Recipients of 8.3 or 8.4 transfers can choose an option which avoids any > > needs-test in exchange for a promise to transfer out eight times the number > > received within a year. Only one option can be active at a time. These > > Recipients would be excluded from current source restrictions. > > Playing devils advocate for a moment, how would we prevent either of the > following abuse scenarios: > > 1. This allows virtually any ORG to acquire 1.125x their current holdings > and use all of the > addresses (smaller block + original holdings). > > 2. An ORG considering selling some (or all) of its IPv4 holdings decides > that a 1.125x > multiplier on their ROI is appealing and even though they don’t need the > space for > renumbering, chooses to take this option as a way to get a revenue bump. > > > I think the policy needs to consider the justification problem for > > recipients of the small block they need to renumber into, in addition to > > the exclusion of these companies from the source restrictions, or it only > > provides half the reason to avoid the workaround. > > > > > > (Also I think there should be no needs-tests or source-restrictions as > > conservation is provided by price and address turnover is not a BAD THING. > > 😉) > > We agreed to disagree about this a long time ago. Of course, you are free to > support a policy proposal to eliminate needs tests and/or source restrictions > and try to build consensus around it if you feel that’s the right way to go. > Should you need help drafting such, I am available to assist. > > Owen > > > > > Regards, > > Mike > > > > > > > > > > -----Original Message----- > > From: ARIN-PPML <[email protected] > > <mailto:[email protected]>> On Behalf Of Owen DeLong > > Sent: Tuesday, December 15, 2020 2:38 PM > > To: arin-ppml <[email protected] <mailto:[email protected]>> > > Subject: [arin-ppml] ARIN-2020-6: Allowance for IPv4 Allocation “Swap” > > Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers > > > > Dear ARIN community, > > > > We (the AC, and specifically the proposal shepherds) need to solicit some > > additional feedback in order to better know the community’s desire with > > regards to this policy. Specifically, we’d like to ask the following > > questions: > > > > 1a. Do you feel that we should place an upper limit on the size of the > > smaller block > > received in the process? > > > > 1b. If so, what should that upper limit be? > > > > 2. Do you support limits on the time period allowed for renumbering? > > > > 2a. If so, how long? > > > > 2b. If so, what consequences should there be for exceeding the time > > limit? > > > > 3. Should any additional restrictions or prohibitions be placed on use > > of waitlist > > space in these transactions? > > > > 3a. Restrictions on waitlist providing the smaller block? > > > > 3b. Restrictions on waitlist space being transferred out? > > > > 4. Do you support the policy as currently written? > > > > 5. If not, would you support it with the changes suggested in your > > answers above? > > > > Thanks for your attention to this matter, > > > > Owen DeLong > > ARIN AC > > > > _______________________________________________ > > ARIN-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: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > <https://lists.arin.net/mailman/listinfo/arin-ppml> > > Please contact [email protected] <mailto:[email protected]> if you experience any > > issues. > > > > >
_______________________________________________ ARIN-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: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
