Inline: > On Aug 26, 2021, at 10:46 AM, Mike Burns <[email protected]> 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 <[email protected]> On Behalf Of Chris Woodfield > Sent: Thursday, August 26, 2021 1:09 PM > To: ARIN-PPML List <[email protected]> > 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 <[email protected]> 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 ([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. > _______________________________________________ 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.
