[arin-ppml] Updated text: ARIN 2020-6 Swap Policy

[Mike Burns]

Hi Chris,

Thanks for your feedback.

I understand the purpose, but there are already many incentives in place for sellers to sell in larger chunks, so I don't see the need to restrict sales to a single block size. In most cases, the sale would be of the largest block in its entirety, but often there is that last /24 that's hardest to renumber out of that would restrict the seller from engaging in any sales at all. I say allow the freedom to sell to the market, taking as much time as needed but having the flexibility to engage in partial sales. All the while restricted from receiving any more addresses until the larger block is sold. If somebody wanted to sell a larger block in small pieces, they would not be needing or wanting to buy addresses.

Your objection to the second issue is noted, but any operator who has the potential to grow fast should not be availing themselves of this policy option IMO.

I think the automatic /24 qualification language should be in there as this is a unique policy and I don't think other language covers this circumstance.

Regards,
Mike




-----Original Message-----
From: Chris Woodfield <chris at semihuman.com> 
Sent: Thursday, August 26, 2021 2:08 PM
To: Mike Burns <mike at iptrading.com>
Cc: ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Updated text: ARIN 2020-6 Swap Policy

Inline:

> On Aug 26, 2021, at 10:46 AM, Mike Burns <mike at iptrading.com> wrote:
> 
> Hi,
> 
> I think the larger block should be allowed to be sold in pieces, notwithstanding the disaggregation.

The intent of this policy is to allow organizations to avoid deaggregation, and contributing to global BGP table bloat, by transferring a smaller block in, then a larger block out in one piece. If the policy allows selling the larger block in pieces, that’s really no different than if they simply renumbered into a smaller portion of it and sold off the rest, making this policy language more or less pointless IMO.

> 
> I think the recipient should lose the ability to receive addresses immediately upon receipt of the smaller block, until the larger block is completely sold. Including waitlist addresses, not included other reserved addresses.

After my last email, I did think of a corner case this might bite an otherwise-trying-to-do-the-right-thing operator: they transfer in, say, a /24, but grow faster than expected and need a second /24 (or larger block) before they can get rid of the block they’re seeking to transfer. As such, I rescind my earlier mention of this as a potential change I’d support.

> 
> If the smaller block is a /24, there should be no needs test.

Agreed, but I think this is already covered in other language? Does it need to be repeated here if so?

> I would lose the officer attestation.

My assumption is that this needs to be in place currently, as it is with other sections regarding needs-based requests; once the consultation is done, if the result of that process is to remove, I expect an omnibus proposal to be authored removing the language wherever it exists.

Thanks,

-C

> 
> Regards,
> Mike
> 
> 
> 
> 
> -----Original Message-----
> From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of Chris 
> Woodfield
> Sent: Thursday, August 26, 2021 1:09 PM
> To: ARIN-PPML List <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Updated text: ARIN 2020-6 Swap Policy
> 
> This new language has my support, with a few comments:
> 
> - If I’m reading this properly, the prohibition on transferring the smaller block kicks in if the larger block isn’t transferred within a year. Have we considered the option of having that restriction kick in immediately until the larger block is transferred? Or was that considered too onerous?
> 
> - I’ve noticed that officer attestation language is present in the new 8.5.5.1.1 subsection; I’m assuming this will remain in place despite the separate discussion on removing the need for officer attestations, and removed via a future policy proposal if that action is taken. Please advise if that assumption is incorrect.
> 
> Thanks,
> 
> -C
> 
>> On Aug 26, 2021, at 6:54 AM, Rob Seastrom <rs-lists at seastrom.com> wrote:
>> 
>> 
>> Dear ARIN Community,
>> 
>> Please read the updated text for policy proposal ARIN 2020-6 Swap Policy (below) and offer your thoughts and comments.
>> 
>> All the best,
>> 
>> -r
>> 
>> -=-=-=-=-
>> 
>> ARIN 2020-6 Swap Policy
>> 
>> Current text:
>> 
>> 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.
>> 
>> 
>> Add:
>> 
>> 8.5.5.1- Transfer for the Purpose of Renumbering Organizations with 
>> larger direct allocations or assignments than they require may receive transfer of a smaller block for the purpose of renumbering onto the smaller block if they transfer the entire larger block to a qualified recipient under section 8 within one year of receipt of transfer of the smaller block. If the larger block is not transferred within one year of receipt of the smaller block, the smaller block will be ineligible for transfer under sections 8.3 and 8.4, and the organization will be ineligible to receive any further transfers under this policy.
>> 
>> 	8.5.5.1.1 Smaller Block Size
>> 	Organizations may qualify to receive transfer of a smaller block by 
>> providing documentation to ARIN which details the use of at least 50% 
>> of the smaller block size within 24 months. Current use of the larger 
>> block may be used to satisfy this criteria. An officer of the 
>> organization shall attest to the documentation provided to ARIN
>> 
>> Current text:
>> 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.
>> 
>> Add:
>> 
>> 8.5.6.1 Transfer for the Purpose of Renumbering Organizations 
>> receiving transfer of a smaller block under section 8.5.5.1 may deduct the larger block they are transferring to a qualified recipient when calculating their efficient utilization of previous blocks under section 8.5.6.
>> 
>> Current Text:
>> Sections 8.3 and 8.4, under “Conditions on Source Of the Transfer”:	
>> “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 8.2 transfers.
>> 
>> Add:
>> This requirement may be waived by ARIN for transfers made in connection with a renumbering exercise designed to more efficiently utilize number resources under section 8.5.5.1.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> ARIN-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:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> ARIN-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:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>