I could be mistaken, but I believe that RIPE NCC provides RPKI services for Legacy without Contract resource holders.
Owen > On Sep 15, 2022, at 15:55 , Rubens Kuhl <rube...@gmail.com> wrote: > > You could try suggesting IANA/PTI/ICANN to have a different RPKI trust > anchor and provide such services to legacy block holders. As you > mentioned, that would probably have a price tag attached to it to > cover the costs for such operations, but a contract could stay away > from ownership issues and not either say the blocks are yours or that > the blocks could be taken from you. Pay for the services, get RPKI; > don't pay them, RPKI ROAs expire. > > I have a feeling that the recurring cost would be higher than using > the scale that the RIR system has in providing those services, and > that doing RIR-shopping (like what was already suggested here, moving > the resources to RIPE) is simpler and more cost effective. But this > would at least expose the real costs without making the RIR-allocated > resource holders subsidize legacy resource holders, which is the good > thing I see in the direction ARIN is going. > > Rubens > > On Fri, Sep 16, 2022 at 5:18 AM Tom Krenn via NANOG <nanog@nanog.org> wrote: >> >> Speaking from the enterprise / end site perspective I would bet there are a >> lot of legacy holders that other than maybe updating their reverse DNS >> records once or twice haven’t looked at ARIN policies or their allocation >> since the late 1980s. In most cases there really is not strong technical >> reason to, the stuff just keeps working. >> >> We are put in kind of an awkward place by the current policies. On one hand >> some of us would like to be good Internet citizens and implement things like >> IRR and RPKI for our resources to help the larger community. But show the >> RSA/LRSA to your lawyers with the justification that "I would like to >> implement RPKI, but everything will keep working even if we don't." You can >> bet they will never jump on board. On one hand there is a push from ARIN and >> the larger community to use these advanced services, but on the other hand >> the fees and risk far outweigh the benefits. (Heck the fees aren’t even that >> big of a deal, just the risk of loosing control of our legacy allocations.) >> >> Tom Krenn >> Network Architect >> Enterprise Architecture - Information Technology >> >> >> >> >> -----Original Message----- >> From: NANOG <nanog-bounces+tom.krenn=hennepin...@nanog.org> On Behalf Of >> John Curran >> Sent: Thursday, September 15, 2022 3:35 PM >> To: John Gilmore <g...@toad.com> >> Cc: North American Network Operators' Group <nanog@nanog.org> >> Subject: [External] Re: Normal ARIN registration service fees for LRSA >> entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the >> Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 2023) >> >> CAUTION: This email was sent from outside of Hennepin County. Unless you >> recognize the sender and know the content, do not click links or open >> attachments. >> >> John - >> >> Your summary is not inaccurate; I will note that ARIN’s approach is the >> result of aiming for a different target – that more specifically being the >> lowest possible fees administered on an equitable basis for _all resource >> holders_ in the region. >> >> For more than two decades legacy resource holders have been provided the >> opportunity to normalize their relations with ARIN by entry into an LRSA - >> thus receiving the same services on the same terms and conditions as all >> others in the region (and also with a favorable fee cap applied to their >> total annual registry fees.) While many folks have taken advantage of that >> offer over the years, it’s quite possible that all of those interested have >> already considered the matter and hence going forward we are returning to >> the refrain of the entire community in seeking the lowest fees applied >> equitably to all in the region. >> >> As we’ve recently added more advanced services that may be of interest to >> many in the community (RPKI and authenticated IRR) and also have just made a >> favorable simplification to the RSA in section 7 (an area that has been >> problematic for some organizations in the past), it is important that ARIN >> not subset availability of the legacy fee cap without significant notice, as >> there many be a few folks out there who were unaware of LRSA with fee cap >> availability and/or haven’t recently taken a look at the various tradeoffs. >> >> In any case, legacy resource holders who don’t care for these advanced >> services (whose development and maintenance is paid for by the ARIN >> community) can simply continue to maintain their legacy resources in the >> ARIN registry. They do not have to do anything, as ARIN is continuing to >> provide basic registration services to the thousands of non-contracted >> legacy resource holders (including online updates to your resources, reverse >> DNS services, >> etc.) without fee or contract. >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> American Registry for Internet Numbers >> >>> On 15 Sep 2022, at 3:41 PM, John Gilmore <g...@toad.com> wrote: >>> >>> John Curran wrote: >>>>> We strongly encourage all legacy resource holders who have not yet >>>>> signed an LRSA to cover their legacy resources to >>> >>> Randy Bush <ra...@psg.com> wrote: >>>> consult a competent lawyer before signing an LRSA >>> >>> Amen to that. ARIN's stance on legacy resources has traditionally >>> been that ARIN would prefer to charge you annually for them, and then >>> "recover" them (take them away from you) if you ever stop paying, or >>> if they ever decide that you are not using them wisely. If you once >>> agree to an ARIN contract, your resources lose their "legacy" status >>> and you become just another sharecropper subject to ARIN's future >>> benevolence or lack thereof. >>> >>> The change recently announced by John Curran will make the situation >>> very slightly worse, by making ARIN's annual fees for legacy resources >>> changeable at their option, instead of being capped by contract. ARIN >>> management could have changed their offer to be better, if they wanted >>> to attract legacy users, but they made an explicit choice to do the >>> opposite. >>> >>> By contrast, RIPE has developed a much more welcoming stance on legacy >>> resources, including: >>> >>> * retaining the legacy status of resources after a transfer or sale >>> * allowing resources to be registered without paying annual fees to RIPE >>> (merely paying a one-time transaction fee), so that later non-payment >>> of annual fees can't be used as an excuse to steal the resources. >>> * agreeing that RIPE members will keep all their legacy resources even if >>> they later cease to be RIPE members >>> >>> You are within the RIPE service area if your network touches Europe, >>> northern Asia, or Greenland. This can be as simple as having a rented >>> or donated server located in Europe, or as complicated as running a >>> worldwide service provider. If you have a presence there, you can >>> transfer your worldwide resources out from under ARIN policies and put >>> them under RIPE's jurisdiction instead. >>> >>> Moving to RIPE is not an unalloyed good; Europeans invented >>> bureaucracy, and RIPE pursues it with vigor. And getting the above >>> treatment may require firmly asserting to RIPE that you want it, >>> rather than accepting the defaults. But their motives are more >>> benevolent than ARIN's toward legacy resource holders; RIPE honestly >>> seems to want to gather in legacy resource holders, either as RIPE >>> members or not, without reducing any of the holders' rights or abilities. >>> I commend them for that. >>> >>> Other RIRs may have other good or bad policies about legacy resource >>> holders. As Randy proposed, consult a lawyer competent in legacy >>> domain registration issues before making any changes. >>> >>> John >> >> >> >> Disclaimer: If you are not the intended recipient of this message, please >> immediately notify the sender of the transmission error and then promptly >> permanently delete this message from your computer system.
