[arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers
Andrew Bagrin
abagrin at omninet.io
Mon Sep 11 12:54:39 EDT 2017
As long as it is tracked that this block now belongs to a different country
and can *easily *be updated in millions of companies geo-firewall policies
based on IP. I’m okay with it being an “occasional” thing, not a daily
event. From a security perspective, there is benefit of having a solid
“non-fluid” mapping of IP blocks to geo.
Tracking does not mean relying on company to fill in the country field
properly in the who-is db.
I would prefer a transfer of blocks between ARIN, RIPE etc..
On a side note, I’m still a big fan of $100/month per /24 IP block. ISP
etc.. can easily charge their customer 25 cents or eat the cost, but those
hoarding /16 blocks that aren’t being used, will be motivated to release
them back to ARIN.
*From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Mueller,
Milton L
*Sent:* Monday, September 11, 2017 12:39 PM
*To:* Scott Leibrand <scottleibrand at gmail.com>; Chris Woodfield <
chris at semihuman.com>
*Cc:* arin-ppml at arin.net
*Subject:* Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity
Requirement for Inter-RIR Transfers
Correct, Scott.
“The problem is simply that not all companies can get access to the IP
addresses they need to run their businesses.” The current policy is a
restriction on moving numbers to their most desired uses. The idea that we
are protecting a market in IP addresses by NOT allowing trades to take
place because of some imaginary “imbalance” in the flow of IP addresses
across imaginary RIR borders is indeed “overthinking” – or perhaps just not
thinking. Perhaps you’ve all become Trumpian economic nationalists.
Can anyone tell me how a so-called “imbalance” in the flow of transferred
addresses across regions negatively affects anyone on this list in a
tangible way? Remember folks, there is no free pool. So what’s the harm?
Party A transfers N IPv4 addresses to party B. If I am neither party A nor
party B, tell me why I care whether party B is in Africa, Asia, Europe or
wherever? How does it affect me in the slightest? You might say “once the
numbers go to Africa it might never come back.” Well, if the numbers go to
Microsoft or Oracle in North America they almost never come back. At this
stage of the game, almost all legitimate transfers are going to places
where they will be used and not thrown back into the market any time soon.
Why should I care where Party B is geographically?
If you want to buy the addresses in competition with Party B, then outbid
him/her. Are you saying that ARIN should subsidize your acquisition by
eliminating certain buyers from the market?
If I am Party A, then the current policy simply means that I have fewer
options for selling my addresses. How does that benefit me? How does that
benefit the Internet? How does that benefit anyone?
Dr. Milton L. Mueller
Professor, School of Public Policy
Georgia Institute of Technology
*From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net
<arin-ppml-bounces at arin.net>] *On Behalf Of *Scott Leibrand
*Sent:* Thursday, September 7, 2017 8:07 PM
*To:* Chris Woodfield <chris at semihuman.com>
*Cc:* arin-ppml at arin.net
*Subject:* Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity
Requirement for Inter-RIR Transfers
IMO we're overthinking this. The problem is simply that not all companies
can get access to the IP addresses they need to run their businesses. The
fix is to enable transfers from ARIN to all other regions, and between as
many regions as are willing to participate. Only LACNIC and AfriNIC don't
allow such transfers yet, and if we can make it easier for them to allow
transfers at least in the important direction (to their regions) then the
transfer market will take care of making sure everyone who needs addresses
can get them. So any policy, including the draft policy as written, that
allows unidirectional transfers to LACNIC and AfriNIC solves the problem.
-Scott
On Thu, Sep 7, 2017 at 3:19 PM, Chris Woodfield <chris at semihuman.com> wrote:
Replying to myself, I decided to look up the population proportions
mentioned in my last email:
North America - 7.79%
South America - 5.68%
Africa - 16.36%
So if one were to use numbers similar to these - the average formula
doesn’t make much of a difference for LACNIC, and actually qualifies
AFRINIC for a far larger share of space than the straight average.
I’m wondering what, if any, types of metrics might exist for measuring
demand for resources instead of population? Or does that run afoul of the
concept of Internet access as a worldwide human right?
-C
On Sep 7, 2017, at 2:50 PM, Chris Woodfield <chris at semihuman.com> wrote:
Thinking more about the use of an average distribution in the proposal, I’m
wondering if this accurately reflects the issue.
The distribution of IP addresses by IANA to the various RIRs is only
inequitable if it results in a clear difference in the ability of an entity
in different regions to acquire IP address space. We don’t need the same
number of allocations in each region - if nothing else, the allocations
should roughly reflect regional populations - but it should be no more
difficult for a party in Africa or South America to acquire IPv4 resources
than it is for a party in North America, Europe, or Asia to do so. To the
extent that this is not the case, we owe the community action to correct.
The question then becomes - does the lack of a transfer policy from ARIN to
these regions make it substantially more difficult to acquire space on the
transfer market today? I’d argue that to the extent that doing so requires
transferring to the space to the local RIR, then the answer is YES, as from
my point of view, the bulk of transfer market supply is from allocations in
the ARIN region (resellers on the list who are in a position to comment,
please keep me honest and speak up if that isn’t the case).
This is somewhat mitigated by the current case that both LACNIC and AFRINIC
still have space to allocate, while ARIN does not. But shower term
point-in-time facts shouldn’t drive far-reaching policy decisions IMO.
As such, I support the goal of the policy, but I believe that the
calculation used to determine qualifying RIRs could be tweaked. Could we
compare allocation percentages to world population, perhaps?
-C
On Sep 7, 2017, at 2:27 PM, Cj Aronson <cja at daydream.com> wrote:
David.. I agree with your very well written summary. I just feel that the
mathematical formula to determine when the transfers have to start being
reciprocal is not needed.
The reason why I feel that way is that we're computing something that was
said earlier, "To go below the global average, the RIR above the average
and closest to
it would need to lose 81,871,002 more addresses, which at the current rate
(14,592 lost per month) would take 5,620 months (468 years)."
It seems like we're spending time computing something that is not likely to
happen.. I would surely hope we are done with IPv4 within the next 468
years :-)
Thanks!
-----Cathy
{Ô,Ô}
(( ))
◊ ◊
On Thu, Sep 7, 2017 at 2:46 PM, David Farmer <farmer at umn.edu> wrote:
Cathy,
Yes, in some ways it would be more straight forward to just say LACNIC and
AFRINIC are allowed an exception to the reciprocity requirement. However,
that policy would contain only the facts of the situation. Whereas this
policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted
from the reciprocity requirement and why APNIC and RIPE are not.
To be honest, I didn't want the reciprocity requirement in the original
transfer policy to being with, because of the optics of this very situation
with LACNIC and AFRINIC. However, I didn't push the issue with the
original transfer policy because I knew it would be several year before
LACNIC and AFRINIC got to the point of approving a transfer policy of any
kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious
thing to do was to eliminate the reciprocity requirement all together.
However, I really like this compromise as well as the reasoning that comes
with it.
There is absolutely no reason for transfers with APNIC and RIPE to not be
on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should
be room for some nuance. LACNIC and AFRINIC have received the short-end of
the stick, so to speak. There was no conspiracy or wrongdoing that caused
this result, but it is a stark fact when you look at the numbers. I
therefore believe these facts should afford LACNIC and AFRINIC some
latitude to decide for themselves how best to move forward.
In the long-run I totally believe LACNIC and AFRINIC should approve
reciprocal transfer policies. However, we need to give them room to decide
this for themselves, it is arrogant and inconsiderate of the facts for us
to dictate a reciprocal transfer policy to them. If they feel they need to
start with a one-way transfer policy, there is logic to such a strategy,
and the current facts seem to justify at least some caution on their part.
Finally, the numbers show we have more than enough room to be magnanimous
in this situation, I believe we should give LACNIC and AFRINIC room to
maneuver, and choose their own way forward.
Thanks.
On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson <cja at daydream.com> wrote:
Okay so this formula.. does it just give us Afrinic and Lacnic right? So
why don't we just say that? Since there are only 5 RIRs it seems that
maybe a formula isn't needed?
{Ô,Ô}
(( ))
◊ ◊
On Wed, Sep 6, 2017 at 12:35 PM, ARIN <info at arin.net> wrote:
The following has been revised:
* Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR
Transfers
Revised text is below and can be found at:
https://www.arin.net/policy/proposals/2017_4.html
You are encouraged to discuss all Draft Policies on PPML. The AC will
evaluate the discussion in order to assess the conformance of this draft
policy with ARIN's Principles of Internet number resource policy as stated
in the Policy Development Process (PDP). Specifically, these principles are:
* Enabling Fair and Impartial Number Resource Administration
* Technically Sound
* Supported by the Community
The PDP can be found at:
https://www.arin.net/policy/pdp.html
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
Regards,
Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)
Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR
Transfers
Version Date: 6 September 2017
Problem Statement:
AFRINIC and LACNIC are currently considering one-way inter-RIR transfer
proposals. Those RIR communities feel a one-way policy a policy that allows
network operators in their regions to obtain space from another region and
transfer it into AFRINIC and LACNIC may best meet the needs of the
operators in that region.
ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated
that ARINs 8.4 policy language will not allow ARIN to participate in such
one-way transfers. The staff formally indicate to AFRINIC that the word
reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to
transfer directly to AFRINIC (in this context).
ARIN as a community should recognize that other RIR operator communities
have different needs than we do. We should recognize that:
- network operators in AFRINIC in LACNIC have need to obtain space in the
market;
- have reasons they think are important to not allow two-way transfers; and
- we should understand that the history of the RIR system has led to LACNIC
and AFRINIC having multiple orders of magnitude less IPv4 address space
than ARIN does.
Policy statement:
Add the following sentence after the first sentence of NRPM 8.4:
Inter-RIR transfers may take place to an RIR with a non-reciprocal
inter-RIR transfer policy only when the recipient RIR has an IPv4 total
inventory less than the average (mean) of the IPv4 total inventory among
all of the RIRs.
Timetable for implementation: Upon the ratification of any inter-RIR
transfer policy at another RIR that is one-way as described in the problem
statement.
_______________________________________________
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:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
_______________________________________________
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:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
--
===============================================
David Farmer Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
===============================================
_______________________________________________
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:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
_______________________________________________
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:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
_______________________________________________
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:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170911/26abb651/attachment.htm>
More information about the ARIN-PPML
mailing list