Dear colleagues, Today I'd like to talk to you as a co-author of ASPA documents c [1] <https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/> [2] <https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/> which may greatly affect your operations. Of course, changing it for the better. Long story short: ASPA (autonomous system provider authorization) is a proposed RPKI object, that should greatly narrow the gap in routing security by adding the opportunity to verify AS_APTH and detect route leaks and AS_PATH manipulations. To make it work, you will need to create an ASPA record that represents a set of your upstream providers plus non-transparent RS. Now let's jump to the question that has already resulted in a holy war in the IETF mailing list. These days, for some strange reasons, networks may be dual-stacked. One might expect that upstream providers would be the same for v4 and v6, if the corresponding providers were also dual-stack. This statement is true for the majority of networks. However, a significant number of AS have different sets of providers in v4 and v6. I would be very grateful if engineers responsible for operating such a network could share their insights into whether it is just a mistake, whether it was done on purpose, or whether my model of peering relations produces incorrect results. To make life easier, here is a link <https://docs.google.com/spreadsheets/d/1MgoD64dBI-2yZhrz77RIf38osKpRl4e-wRkLOVN_qi0/edit?usp=sharing> to a Google spreadsheet. It shows customer-provider pairs from v4 that don't exist (or at least not visible) in v6. If you find your AS (or AS of your best friend!) in the 'Customer' column please share your story via email or catch me or Job Snijders in person during the RIPE meeting. As a final part of my motivation speech, I would like to remind you that routing security is not a burden of one or two enthusiasts, it always was and always will be a joint success or joint failure. -- Best regards, Alexander Azimov