It seems that is suggested the interest of the sellers may be above the
interests of the ARIN community which I obviously disagree. Need to find
out what fits for the current scenario we face but community interests
should always prevail.
And again RIPE examples are almost always not very good ones to be
replicated in other regions. It may be good for certain actors of this
business, but not necessarily for most of the community involved.
Every time a "good" RIPE example is mentioned in contrast with something
the opposite somewhere else I kind of fell that this somewhere else may
be going in a good direction.
Regarding the merit of the proposal what would the acceptable size to to
allow to fractionatethat block, if any ?
Regards
Fernando
On 08/02/2022 14:29, Mike Burns wrote:
Hi Rob,
I am opposed to the policy as written because it requires the larger block to
be sold in one piece.
This isn't always possible or desirable for a seller. What if they have a /14
or larger?
I prefer allowing the workaround with the new Org for the small block with a
restriction on the new Org's access to the waiting list.
It would be better for ARIN to wake up and realize cluttering the NRPM with
these increasingly byzantine rules has been proven to be unnecessary by the
RIPE experience. Maybe a decade is long enough for the experiment? In RIPE, we
don't have this deaggregation problem because the problem stems from the hoary
needs test regime at ARIN.
Get rid of the needs-test and streamline the NRPM, continuing down the
needs-test road will inevitably lead to more confusion as we carve out more and
more exceptions.
Also this policy allows any block holder to buy a smaller block without a needs
test by claiming they plan to sell the larger block in the future, they all get
one bite at this apple without attestation.
Regards,
Mike
-----Original Message-----
From: ARIN-PPML<arin-ppml-boun...@arin.net> On Behalf Of Rob Seastrom
Sent: Saturday, February 05, 2022 11:56 AM
To: ARIN-PPML List<arin-ppml@arin.net>
Subject: [arin-ppml] Updated text for ARIN-2020-6 'Allowance for IPv4
Allocation “Swap” Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR
Transfers'
Dear ARIN Community,
Pursuant to December's Staff and Legal review of ARIN-2020-6, the following
changes have been made:
In section 8.5.5.1, changed
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.
to
If the larger block is not transferred within one year of receipt of the
smaller block, the organization will be ineligible to receive any further
transfers under this section until the larger block is transferred.
Also:
* removed reference to officer attestation as a result of last summer's ACSP
consultation.
* Clarified section 8.3 and 8.4 "Conditions on Source of Transfer" to refer
directly to proposed section 8.5.5.1
The new text of the proposal is as follows. Please share your thoughts.
Allowance for IPv4 Allocation “Swap” Transactions via 8.3 Specified Transfers
and 8.4 Inter-RIR Transfers
Problem Statement: Organizations wishing to “swap out” a larger block for a
smaller one in the interest of avoiding deaggregation (as opposed to breaking
up their existing block and transferring only a part of it) are forbidden by
existing 8.3 policy from being the source of the transfer for their larger
block after receiving a smaller one for 12 months after receiving the smaller
block. In practice, ARIN staff has been allowing orgs to transfer out blocks
after receiving smaller ones inside of the 12-month window, but many ARIN
resource holders are not aware of this. Some resource holders have worked
around the restriction by creating a new org to receive the smaller block, but
this practice has implications on waitlist policy, as the new org is now
technically eligible to apply for wait-list space while the original org cannot.
Similar language is present in NRPM Section 8.4, as such, the practice should
be sanctioned for those types of transfers as well.
Policy Statement: Clarify the conditions under 8.3 and 8.4 that explicitly
allows transfer of a larger block in exchange for a smaller one as part of a
renumbering plan by making the following changes in 8.3, 8.4, and 8.5:
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
organization will be ineligible to receive any further transfers under this
section until the larger block is transferred.
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.
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.
Change to:
With the exception of M&A transfers under section 8.2, the source entity must
not have received a transfer, allocation, or assignment from ARIN for the past 12
months. 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.
Timetable for Implementation: Immediate
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contacti...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contacti...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
