Legacy holders can also easily transfer to RIPE without a contract. Owen
> On Apr 26, 2022, at 15:19, Andrew Dul <[email protected]> wrote: > > Legacy holders have the option to add records to ARIN’s authenticated irr. It > only requires them to sign an lrsa or rsa. In my opinion it is time for the > free ride for legacy holders to end. > > I have no problem with a sunset date say 2-5 years from now but we need to > move in that direction. > > Speaking only for myself and not for any organization or in any position. > > Andrew > > >> On Apr 26, 2022, at 14:39, Scott Leibrand <[email protected]> wrote: >> >> IMO there is a need for number resource holders to be able to attest >> (solely) that a given origin ASN is (solely) authorized to announce route(s) >> for those number resources. >> >> Most forms of RPKI, like DNSSEC, are really easy to screw up in such a way >> that you knock your own services off the Internet. As long as that remains >> true, it will likely never get to 100% adoption. If it does, it will be >> because it allows number resource holders to make attestations via the RIRs >> as to who is authorized to announce their route(s), without requiring the >> resource holders to sign their route announcements in such a way that >> screwing up key rotation will cause them to be rejected. >> >> Fully authenticated IRR solutions can provide all the same services that >> putting an origin ASN into whois provides, but only for non-legacy >> resources. Until ARIN is willing to provide basic authenticated IRR services >> to legacy resource holders, it seems we still need the origin ASN field as >> long as it continues to be used. >> >> Scott >> >>> On Apr 26, 2022, at 9:07 PM, James Hulce via ARIN-PPML <[email protected]> >>> wrote: >>> >>> snipped, with inline comments >>>> On Tue, Apr 26, 2022 at 1:07 PM Job Snijders via ARIN-PPML >>>> <[email protected]> wrote: >>>> I'm the one who initiated the process towards ARIN-2021-8. I've put in >>>> considerable effort to find a purpose and use for the ARIN Originations >>>> field in automated tool chains, and ultimately concluded the field has >>>> so many apparent challenges it might be better to get rid of it, >>>> especially since IRR and RPKI nowadays exist. >>> Job, thanks for coming here to explain your perspective. I, for one, >>> was surprised to see your name attached to the original policy >>> proposal given all of your past work in this space. >>> >>>>>> On Tue, Apr 26, 2022 at 11:53:58AM -0500, David Farmer via ARIN-PPML >>>>>> wrote: >>>>>> While I do not support the deprecation of the 'Autonomous System >>>>>> Originations' Field from the database at this time for many of the >>>>>> reasons >>>>>> discussed at the microphone at ARIN 49. >>>> >>>> Unfortunatey, I wasn't there. Would you be so kind to outline the many >>>> reasons in an email? >>> My comment: Oppose this proposal at this time. The Autonomous System >>> Origination field in ARIN Whois occupies a peculiar yet potentially >>> valuable place in the routing information landscape. It provides an >>> easy and authenticated way for everyone, including legacy resource >>> holders, to communicate their routing intentions. OriginAS does not >>> suffer from other problems associated with IRR, such as proxy records >>> or multiple disparate databases. Several organizations, networks, and >>> exchanges report using the OriginAS field to generate filters and >>> perform other operational tasks despite consumption issues. Without >>> much known about its uptake, usage, accuracy, and role, deprecation >>> would be premature. (generally summarized my PPML post from last >>> week) >>> >>> Attempting to outline what others said: >>> There was general agreement around the point that ARIN Whois OriginAS >>> is a unique, weird legacy thing and should go away eventually. There >>> is a desire to eventually reach RPKI's promised land and retire all of >>> the earlier outmoded and problematic routing information sources. >>> However, we are not there yet. People from several organizations, >>> including Lumen (nee CenturyLink & Level 3) and Internet2, expressed >>> current operational dependencies. It has notable LOA use cases. >>> Several commentators floated a three-year wind-down period as part of >>> a broader transition to RPKI and authenticated IRR. I agree with that. >>> OriginAS is intertwined with other ongoing ARIN discussions, including >>> handling legacy resources and a la carte/standalone vs bundled >>> registry services. Right now, there's a vast ocean of legacy resource >>> holders locked out of ARIN's IRR and RPKI because they can't or won't >>> sign an LRSA. This pool is gradually decreasing, but will be a >>> consideration for a while yet. How do legacy resource holders proceed >>> if/when OriginAS goes away? >>> Those who were in attendance or watching: did I miss anything? >>> >>>>> Nevertheless, as discussed in the problem statement this field has >>>>> several problems and it eventually needs to be deprecated. However, >>>>> since this is an optional field within the ARIN database, without any >>>>> enforcement actions required by policy, it seems possible to remove >>>>> section 3.5 from the NRPM at this time, without also deprecating the >>>>> field at this time. >>>>> >>>>> Further, this would set things up for the future deprecation of the >>>>> 'Autonomous System Originations' Field from the database to proceed when >>>>> the community feels that is appropriate, as expressed through a separate >>>>> ARIN Consultation Process, without necessitating additional policy >>>>> actions. >>>>> >>>>> If this policy proposal were modified to only remove section 3.5 from the >>>>> NRPM at this time, with the deprecation of the 'Autonomous System >>>>> Originations' Field from the database occurring at some future date, to be >>>>> determined at a later time by the ARIN community, I would support this >>>>> policy proposal proceeding forward. >>>> >>>> Why do you favor a separate consultation? >>> >>> So, this is kind of a weird one. Technically, ARIN services are out of >>> the PDP scope [1]. However, ARIN's collection and distribution of AS >>> origination information is enshrined in the NRPM. Whether or not the >>> existence of Whois OriginAS and NRPM 3.5 are necessarily coupled is >>> not fully clear to me. I interpreted them as one and the same and I >>> think much of the community did as well. Notably, some other >>> informational services have no NRPM mention at all. There's zero >>> mention of RPKI, for example. Someone from ARIN or the AC could >>> clarify this point. >>> >>> All in all, I could support a future/revised proposal eventually >>> getting rid of OriginAS. Here's what needs to happen, from my view: >>> First, we need usage info to quantify what's at stake here. What is >>> the real usage and impact of OriginAS? Who would be most impacted by >>> deprecation? >>> Second, everyone must have viable alternatives. >>> Third, the wind-down should take lessons from ARIN-Nonauth. Publicize >>> it well, offer support, and take it slow. This policy proposal was >>> flying under the radar and proposed an overly fast timeline. >>> >>> - James >>> >>> [1] >>> https://www.arin.net/participate/policy/pdp/#3-1-policies-not-processes-fees-or-services >>> _______________________________________________ >>> ARIN-PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List ([email protected]). >>> Unsubscribe or manage your mailing list subscription at: >>> https://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact [email protected] if you experience any issues. >> _______________________________________________ >> ARIN-PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ([email protected]). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] if you experience any issues. > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
