[arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement

[Isaiah Olson]

Hi Mike,

Thanks for your reply. I would be happy to address each of your assertions.

> That RIPE situation is an unfortunate artifact of their reserve pool 
> for new entrants.
>
> Can you share the percent of those /24s that begin with 185?
Roughly 17% of the RIPE IP space that I have on my list comes from that 
block. I would hardly agree that the statistically significant disparity 
in transfer market abuse activity across all RIPE IP ranges is solely an 
artifact of this single block.

> First you wrote “The onus is not on ARIN to sanctify practices that 
> some are already engaging in, but rather to distribute number 
> resources in accordance with community developed policy.”
>
> My answer is that this policy proposal continues to distribute number 
> resources in accordance with community developed policy.
It will be community policy if and when it is adopted through this PDP, 
which seems unlikely at this point since you are the only person arguing 
in favor and I don't find your arguments particularly convincing since 
they are not backed up by any hard data. Whether the policy comports 
with the goals of the PDP itself is a different question.

> I would agree with you, but that doesn’t mean we should ignore 
> relevant data from our sister registry, and I brought up RIPE to deal 
> with Noah’s objection about what will happen should this policy pass
What relevant data have you provided from RIPE which justifies your 
initial assertion? Certainly you may have rejected Noah's concern that 
the RIR would collapse, given the fact that RIPE still exists, but I 
haven't seen any compelling data cited here that shows any benefit to 
the RIPE community due to their policy and I have provided data which 
shows quite the opposite. A lack of immediate negative effects is hardly 
sufficient data to declare that RIPE policy hasn't caused negative long 
term effects, of which we may not have yet seen the full impact.

> Then you won’t have to worry about leasing, because you claim there is 
> no market for it. The waiting list is not a guaranty, and has an 
> unpredictable schedule for address delivery. I gave an example of a 
> WISP seeking to try out a new area, and why leasing addresses might be 
> quite attractive to that WISP for entirely legitimate reasons. 
I would not consider the current waiting list distributions 
unpredictable, in fact I would argue it's quite the opposite in 
practice. Speaking from personal experience on the waiting list before 
ARIN moved to quarterly distributions, I waited only four months to 
receive a block. Under the last several quarterly distributions, nearly 
every request on the list has been fulfilled in each distribution, 
resulting in a consistent distribution schedule of 3-6 months for the 
last several distributions. The oldest request currently on the list is 
from 07/01/2021. I would ask ARIN to please provide some hard data about 
this process for the community to consider when evaluating this policy, 
because I do not believe the current reality of the waiting list agrees 
with your assertions. If and when that changes, I would possibly be open 
to re-considering my position on the matter.

With regards to leasing, I did not assert that there is no market for 
leasing, but rather that alternatives to leasing do exist and you are 
casting them in an a light that I do not believe reflects the reality of 
the situation. Under current policy, your WISP example is free to apply 
to the waiting list for the block it needs to try out the new area, and 
either return or re-purpose it if services in that new area don't work 
out. I don't find a compelling argument here for the necessity of 
leasing addresses.

> Opposing this policy means the only lessors are the lucky incumbents. 
If the lucky incumbents choose to retain their IPv4 space and lease it, 
that is certainly their choice to make. However, under the current 
policy you propose to change, they may not consider leased addresses as 
justification for additional space. I feel the current policy strikes a 
perfectly appropriate balance. If a network has leased space available 
to reclaim when leases expire, it is inappropriate for them to seek 
additional allocations from the RIR. If they have over-leased their 
space such that they cannot operate their network until someone's lease 
expires, then they should not expect the ARIN community to subsidize 
their lack of foresight with additional addresses. Transfers in such a 
situation are a different matter and I would certainly consider this 
policy in a different light if leasing space were to be exempted as 
justification for waiting list request.

> Opposing this policy means a lack of policy is preferred, despite the 
> open practice of leasing.
As I originally stated in my first e-mail, I do not prefer the lack of 
policy or the insufficiency of the current policy. I would instead 
prefer to see the policy explicitly strengthened to disallow off-network 
leasing as justification for additional requests, despite the fact that 
ARIN has made it clear that they consider the current policy to prohibit 
using such addresses as justification.

> Opposing this policy provides incentive for registry-shopping and 
> address outflow.
I agree that RIR-shopping is a concern and there is a real chance that 
strict policy against leasing in the ARIN region may encourage the 
practice. However, I don't believe this should be the concern of the 
ARIN community in deciding how to allocate resources in our corner of 
the world. If other RIR communities want to make other decisions, they 
are endowed with that freedom under the current system. I don't think 
"everyone is jumping off the bridge so we should too" makes for a good 
argument. What would convince me is hard data that shows how the RIPE 
community has benefited from the elimination of the needs-test in the 
transfer process, or data that demonstrates what tangible issue your 
policy proposal would solve in the ARIN region. "Current ARIN policy 
prevents the use of leased-out addresses as evidence of utilization" 
doesn't strike me as a complete problem statement.

> Opposing this policy reduces the lessor pool and drives up lease rates.
This argument cuts both ways. I would argue that supporting the policy 
drives up transfer market prices by increasing speculation by entities 
that have no stake in the shared Internet resource aside from the rights 
to use IPv4 addresses. Basic math tells us that higher prices in the 
transfer markets will result in higher prices in the leasing market, as 
well as resulting in fewer blocks available to networks who wish to 
obtain space directly from the RIR via transfers. I do not see this as a 
benefit to the community. As I have stated before, I am unmotivated by 
the impacts on lessees/lessors of keeping the current policy or 
strengthening the requirement to provision actual services on an 
operational network. If networks choose to lease, they may pay more, 
which is a similar situation for any capital-intensive resource that is 
subject to leasing. Developing policy to keep lease rates low is not the 
concern of the ARIN community or this PDP, but rather developing policy 
that supports efficient and technically competent administration of the 
region's resources.

> Opposing this policy dis-incentivizes accurate registration
If networks choose to report inaccurate or fraudulent SWIP data in order 
to evade the requirements of the current policy, then they are not 
allocating addresses in accordance with ARIN policy and could be subject 
to enforcement actions from ARIN. Although I wish ARIN was more 
aggressive in maintaining an accurate WHOIS database and abuse contacts, 
I would argue that the current situation in the ARIN region is quite 
good compared to other RIRs in this respect, since there has been a 
regular review process to ensure database accuracy for many years. 
Either way, this policy proposal doesn't fundamentally change reporting 
requirements, but simply blesses networks who currently have "something 
to hide" to report their usage accurately. Certainly, I can see how the 
policy benefits the community in this limited sense. Still, I am 
unconvinced that the net effects would be positive and I do not support 
the policy.

- Isaiah

On 9/21/2021 4:29 PM, Mike Burns wrote:
>
> Hi Isaiah,
>
> That RIPE situation is an unfortunate artifact of their reserve pool 
> for new entrants.
>
> Can you share the percent of those /24s that begin with 185?
>
> You didn’t support Noah’s theory that this policy proposal would lead 
> to the demise of RIRs, so let’s address your particular objections.
>
> First you wrote “The onus is not on ARIN to sanctify practices that 
> some are already engaging in, but rather to distribute number 
> resources in accordance with community developed policy.”
>
> My answer is that this policy proposal continues to distribute number 
> resources in accordance with community developed policy.
>
> Second you wrote:” If other RIR communities choose to make other 
> decisions, that doesn't make it the correct decision for the ARIN region.”
>
> I would agree with you, but that doesn’t mean we should ignore 
> relevant data from our sister registry, and I brought up RIPE to deal 
> with Noah’s objection about what will happen should this policy pass”
>
> Third you wrote “There is a waiting list available for legitimate new 
> entrants, and I don't buy the argument that networks with greater than 
> a /20 cannot afford the capital outlay to purchase a block.”
>
> Then you won’t have to worry about leasing, because you claim there is 
> no market for it. The waiting list is not a guaranty, and has an 
> unpredictable schedule for address delivery. I gave an example of a 
> WISP seeking to try out a new area, and why leasing addresses might be 
> quite attractive to that WISP for entirely legitimate reasons.
>
> I feel I have addressed what I see as the objections you have noted.
>
> Now, why not try to actually address even one of my assertions and 
> tell me where it fails?
>
> “Opposing this policy means the only lessors are the lucky incumbents.
>
> Opposing this policy means a lack of policy is preferred, despite the 
> open practice of leasing.
>
> Opposing this policy provides incentive for registry-shopping and 
> address outflow.
>
> Opposing this policy reduces the lessor pool and drives up lease rates.
>
> Opposing this policy dis-incentivizes accurate registration”
>
> Regards,
> Mike
>
> *From:* Isaiah Olson <isaiah at olson-network.com>
> *Sent:* Tuesday, September 21, 2021 5:07 PM
> *To:* Mike Burns <mike at iptrading.com>; 'Noah' <noah at neo.co.tz>
> *Cc:* 'ARIN-PPML List' <arin-ppml at arin.net>
> *Subject:* Draft Policy ARIN-2021-6: Remove Circuit Requirement
>
> Mike,
>
> I would hardly say it's time for a funeral in RIPE, but I would ask, 
> do you think it's a coincidence that roughly 75% of the /24 blocks 
> that I have blackholed on my network for spamming my email server are 
> registered to anonymous hosting companies in the RIPE region? I don't 
> agree that the results of the RIPE policy speak for themselves, and I 
> would love to see more data aggregated by some of the more talented 
> internet sleuths on here regarding the proportion of abuse activity 
> split up by RIR. I also disagree with all five of your assumptions 
> about opposing this policy. The onus is not on ARIN to sanctify 
> practices that some are already engaging in, but rather to distribute 
> number resources in accordance with community developed policy. If 
> other RIR communities choose to make other decisions, that doesn't 
> make it the correct decision for the ARIN region. I don't support any 
> policy that amplifies the practice of leasing because I reject your 
> arguments about the necessity of the practice. There is a waiting list 
> available for legitimate new entrants, and I don't buy the argument 
> that networks with greater than a /20 cannot afford the capital outlay 
> to purchase a block. Please feel free to provide any data you can to 
> back up your five assertions. For my assertion, please consider the 
> following:
>
>     Prefixes exchanged within the RIPE region as sales originate have
>     the highest fraction of blacklisted IPs, which is statistically
>     significant.
>
> Source: 
> https://eprints.lancs.ac.uk/id/eprint/139789/1/VGiotsas_PAM2020_IPv4_Transfers_abuse.pdf 
> <https://eprints.lancs.ac.uk/id/eprint/139789/1/VGiotsas_PAM2020_IPv4_Transfers_abuse.pdf>
>
> - Isaiah
>
> On 9/21/2021 3:24 PM, Mike Burns wrote:
>
>     I am in total agreement with your sentiment and the requirement
>     for a circuit should continue to stand.
>
>     Any policy that removes such a requirement would render the
>     management of Internet Number Resources by the registry useless
>     and thereby essentially lead to no need for the registry after all.
>
>     Noah
>
>     Hi Noah,
>
>     Are you aware that there has been no needs-test for RIPE transfers
>     for many years and the RIR system hasn’t collapsed?
>
>     To make it clear, in RIPE you can purchase address space with the
>     sole purpose of leasing it out. And you have been able to do that
>     for many years now.  Plainly, openly, within all policy. So please
>     let us know where to send the flowers for RIPE’s funeral. That
>     goes for others who predict that bad things will follow from
>     adopting this policy, please keep RIPE’s example in mind to
>     provide a reality check. The experiment has already been performed.
>
>     Owen has already pointed out the futility of the circuit
>     requirement in practice,  yet you think that’s what keeps the RIR
>     system functional?
>
>     Opposing this policy means the only lessors are the lucky incumbents.
>
>     Opposing this policy means a lack of policy is preferred, despite
>     the open practice of leasing.
>
>     Opposing this policy provides incentive for registry-shopping and
>     address outflow.
>
>     Opposing this policy reduces the lessor pool and drives up lease
>     rates.
>
>     Opposing this policy dis-incentivizes accurate registration.
>
>     Let me know if any of these assertions require amplification, I
>     guess some may not be clear but this is already too long.
>
>     Regards,
>     Mike
>