<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Glen -
<div class=""><br class="">
</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"></span>Great feedback - thanks for taking the time to write this up!</div>
<div class=""><br class="">
</div>
<div class="">/John</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">John Curran</div>
<div class="">President and CEO</div>
<div class="">American Registry for Internet Numbers</div>
<div class=""><br class="">
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 15 Apr 2021, at 9:40 AM, Glen A. Pearce <<a href="mailto:arin-consult@ve4.ca" class="">arin-consult@ve4.ca</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">I'm a 3x-Small organization (literally "the smallest end users" to <br class="">
borrow Owen DeLong's terminology) chiming in. <br class="">
<br class="">
After a few years of reading NANOG I came to the conclusion that the <br class="">
IPv4 to IPv6 transition was going to be long, slow and potentially <br class="">
ugly. So this is why I chose to get my own resources directly from <br class="">
ARIN to cover both bases. <br class="">
<br class="">
-My own IPv4 space so I can go to any ISP that can provision <br class="">
connectivity to my location whether they have IP space of their <br class="">
own available or not. If one or both of the big guys in my <br class="">
market ends up doing carrier grade NAT badly (especially by <br class="">
surprise) or just starts price gouging for IP addresses the <br class="">
independents will probably have a hard time getting enough <br class="">
IPv4 space to take the exodus of customers at that point. <br class="">
(It's even possible the transfer market could at some point <br class="">
lock up with no blocks offered for stretches of time.) A guy <br class="">
that's bringing his own space and just needs bandwidth will <br class="">
be a lot easier to take on. <br class="">
<br class="">
-Getting IPv6 before my local cable company gets around to <br class="">
implementing it. Much easier to get dual stacked and slowly <br class="">
transitioning stuff on my network and have time to get used <br class="">
to everything than having to scramble to do it all at once <br class="">
when/if things finally tip from glacial movement to rapid change. <br class="">
<br class="">
On Fri, Apr 9, 2021 at 3:38 PM ARIN <info at <a href="http://arin.net" class="">arin.net</a>> wrote:
<br class="">
<br class="">
<blockquote type="cite" style="color: #007cff;" class="">We are consulting with the community regarding changes to the
<br class="">
ARIN Fee Schedule that are intended for implementation in January <br class="">
of 2022. These changes are: <br class="">
<br class="">
* Transitioning End Users from annual per-resource maintenance <br class="">
fees to the RSP (Registration Services Plan) Fee Schedule <br class="">
</blockquote>
<br class="">
Largely I'm OK with this as I recently converted to a registration <br class="">
services plan myself as I was wanting to get IPv6 space as well so <br class="">
it made more sense to have both and full voting membership under a <br class="">
single $250 fee. (I just submitted a ticket asking about getting <br class="">
a /40 yesterday morning,) <br class="">
<br class="">
As one of "the smallest end users" I don't need more than a /24 of IPv4 <br class="">
space and a /40 of IPv6 space. If the nature of what I do changed <br class="">
enough that I needed more space than that I would probably by that <br class="">
point be a big enough organization that I could handle the higher <br class="">
fees for the larger chunks of IP space under the Registration <br class="">
services plan. <br class="">
<br class="">
Really this will only raise costs for end user organizations with <br class="">
very large singular chunks of space. Generally an organization big <br class="">
enough to actually need even a /22 is big enough it can afford to <br class="">
pay the Registration Services Plan fees for it. <br class="">
<br class="">
It won't impact us "smallest end users" with the possible exception <br class="">
of holders of a single IP block. This could maybe be addressed by <br class="">
making the "ASN-only" category in the proposed new fee structure a <br class="">
"single resource only" category which would apply whether that single <br class="">
resource was an AS, a /24 of IPv4 or a /40 or smaller of IPv6. <br class="">
<br class="">
The IPv4 only holders will eventually realize one day that they <br class="">
need IPv6 as well to be visible to the whole internet and they <br class="">
will upgrade then at their own pace. I'm pretty sure that anyone <br class="">
that at this point has their own IPv6 space and no IPv4 space is <br class="">
either running a hobby/experimental network or is thinking very <br class="">
very long term about larger plans and is thinking it's easier to <br class="">
get their resources now than down the road, either way they <br class="">
probably aren't generating revenue with that IPv6 block right <br class="">
now so for them every penny counts. <br class="">
<br class="">
Finally having everyone under the registration services plan will <br class="">
be simpler for new sign ups than having 2 different fee schedules. <br class="">
<br class="">
<blockquote type="cite" style="color: #007cff;" class=""> * Transitioning Legacy resource holders from annual per-resource
<br class="">
maintenance fees to the RSP Fee Schedule while maintaining the <br class="">
annual cap of total maintenance fees (which will increase $25 <br class="">
per year) <br class="">
</blockquote>
<br class="">
As long as the fee cap on LRSA holders remains (which I agree it <br class="">
should for all of them and not just the early signers) that would <br class="">
override the difference between the 2 current fee schedules anyways <br class="">
which makes this change immaterial to them. <br class="">
<br class="">
Legacy holders (including those that never signed an LRSA) will all <br class="">
at some point need IPv6, so either they'll have to get it through <br class="">
their ISPs or they'll have to pay RIR fees on those when the point <br class="">
comes that they decide they need it. <br class="">
<br class="">
<blockquote type="cite" style="color: #007cff;" class=""> * Providing a temporary IPv6 fee waiver for organizations in
<br class="">
the 3X-Small category that desire a larger address block <br class="">
</blockquote>
<br class="">
Generally I think this is a gimmick, it expires at the end of 2026. <br class="">
Really if I needed more than a /40 of IPv6 space between now and <br class="">
the end of 2026 I'd probably also need more IPv4 space and have <br class="">
to move up size categories anyways. It almost looks like a trap <br class="">
as anyone who takes the bigger space now but doesn't really need <br class="">
it is baking in a doubling of fees when they renew in 2027 but if <br class="">
their organization is still a very small one that doubling of fees <br class="">
could be a strain on them. I myself did hold out for the 2020-3 <br class="">
to be implemented before requesting IPv6 space as $250/year I can <br class="">
handle but $500 per year would be a strain. <br class="">
<br class="">
<blockquote type="cite" style="color: #007cff;" class=""> * Implementing a $100 fee for OrgCreate and OrgRecovery
<br class="">
transactions <br class="">
</blockquote>
<br class="">
Although I see this maybe being a thing for OrgRecovery as I imagine <br class="">
most of these are for Orgs with legacy resources where there is a <br class="">
strong incentive for someone to try hijacking the Org so an extra <br class="">
level of scrutiny is probably needed.... <br class="">
<br class="">
However I'm thinking for OrgCreate for an entirely new Org if it's <br class="">
taking $100 of labor to do this something is wrong with the process <br class="">
and it needs to be streamlined somehow. <br class="">
<br class="">
I mean for my .ca names I have to be Canadian to hold them but if <br class="">
people had to start paying CIRA $100 to verify their Canadianness <br class="">
before they could get a .ca name that wouldn't go over well. ^_- <br class="">
<br class="">
So I would tend to oppose this fee at least fora brand new OrgCeate. <br class="">
<br class="">
<blockquote type="cite" style="color: #007cff;" class=""> * Increasing the transfer processing fee to $500
<br class="">
</blockquote>
<br class="">
This seems reasonable. <br class="">
<br class="">
<span class="moz-txt-tag">-- <br class="">
</span>Glen A. Pearce <br class="">
<a class="moz-txt-link-abbreviated" href="mailto:gap@ve4.ca">gap@ve4.ca</a> <br class="">
Network Manager, Webmaster, Bookkeeper, Fashion Model and Shipping Clerk. <br class="">
Very Eager 4 Tees <br class="">
<a class="moz-txt-link-freetext" href="http://www.ve4.ca/">http://www.ve4.ca</a> <br class="">
ARIN Handle VET-17 <br class="">
<pre class="moz-signature" cols="72">--
Glen A. Pearce
<a class="moz-txt-link-abbreviated" href="mailto:gap@ve4.ca">gap@ve4.ca</a>
Network Manager, Webmaster, Bookkeeper, Fashion Model and Shipping Clerk.
Very Eager 4 Tees
<a class="moz-txt-link-freetext" href="http://www.ve4.ca/">http://www.ve4.ca</a>
ARIN Handle VET-17</pre>
</div>
_______________________________________________<br class="">
ARIN-Consult<br class="">
You are receiving this message because you are subscribed to the ARIN Consult Mailing<br class="">
List (<a href="mailto:ARIN-consult@arin.net" class="">ARIN-consult@arin.net</a>).<br class="">
Unsubscribe or manage your mailing list subscription at:<br class="">
<a href="https://lists.arin.net/mailman/listinfo/arin-consult" class="">https://lists.arin.net/mailman/listinfo/arin-consult</a> Please contact the ARIN Member Services<br class="">
Help Desk at <a href="mailto:info@arin.net" class="">info@arin.net</a> if you experience any issues.<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>