> On Dec 15, 2020, at 1:32 PM, Mike Burns <[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]> On Behalf Of Owen DeLong
> Sent: Tuesday, December 15, 2020 2:38 PM
> To: arin-ppml <[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]).
> 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.
>
_______________________________________________
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.
