RIPE 92 Daily Meeting Blog

Choose RIPE. Choose A Job. Choose RPKI. Choose not putting <marquee> tags anywhere near your trust infrastructure. Choose tutorials, newcomer sessions, Plenary presentations, WGs, BoFs and the hallway track. Choose coffee strong enough to get you through the week. Choose Edinburgh, where RIPE 92 opened on Monday. And of course, choose to follow this Daily Meeting Blog, where we’ll do our best to report on what happened at this meeting and what mattered, and where no pun is too bad, no joke too lame, and no reference too obscura.

Opening plenary

Mirjam Kühne, RIPE Chair, opened the meeting and welcomed us all to Edinburgh, noting that the last time the RIPE community came together in Auld Reekie was back in 1998, whereupon a new LIR WG was formed with somebody named Hans Petter Holen as its chair.

The Lord Provost of Edinburgh, Councillor Robert Aldridge, then followed to extend us all a warm welcome to this unique and historic city of Edinburgh. He urged us to try Scotland’s national drinks by way of a dilemma: Whiskey will tax your liver, while Irn Bru wll evntuly cost yu yur teeth.

Linda Shannon then welcomed us on behalf of IPv4.Global by Hilco Global, our fantastic local hosts who have helped us to make all of this possible. Hans Petter Holen, RIPE NCC Managing Director, ran through the usual meeting logistics and reminded members to register for Wednesday’s GM.

Sasha Romijn, Reliably Coded (IRRD, IRRexplorer, internet.nl), delivered an excellent opening presentation together with a few servings of humble pie when she shared her adventures in seeing how just far her favourite html tag <marquee> could take her on various websites and platforms. This turns out to be pretty far indeed! The RIPE NCC was also not immune, and she showed how this exploit could be used to gain access to the RPKI dashboard among other RIPE NCC platforms and tools. She also shared her experiences in reporting bugs to us and other affected companies, and dealing with the third-party companies who are tasked with assessing reports and awarding bounties. Overall, we might say this was ‘slightly less than optimal.’ A few lessons to learn here and a recurring pattern centred around low-sensitivity tools existing within the same trust scope as high-sensitivity tools. Eleonora Petridou, RIPE NCC, thanked Sasha for her excellent work and said we will be publishing more details here on RIPE Labs in response.

Maria Matejka, BIRD | CZ.NIC, presented on ASPA and why it still a draft technology. Her practical advice was to sign your ASPA records, cover all BGP sessions, and don't forget backup providers or failover traffic may appear invalid elsewhere. The good news: the spec is finally nearly done.

Afternoon session

The second plenary session was split between presentations on BGP and communities (communities in a strictly non-BGP sense, that is). The session opened with a presentation by Ebrima Jaw from University of Twente about noisy routers and patterns in route collector data. The volume of data (RIPE RIS, routeviews) is computationally challenging for most researchers, and Ebrima has been investigating what’s creating this volume. One idea could be that the volume of a route collector is determined by the number of peers. This feels logical, but in practice the BGP update volume per time period, per collector, is heavily skewed, and spikes in data volume come from a low number of peers. Overall, the volume of BGP messages is very unevenly distributed across BGP sessions, prefixes, and AS-paths. This impacts more than just datasets, it also affects routers and the stability of routes. In the end, the solution is to monitor for this issue and talk to the people operating the networks involved. In the Q&A, people called out that nothing gets fixed until someone complains loudly, and that the pain is not felt by the network creating the noise. This might be yet another collective action problem in BGP, where individual operators don’t have much of an incentive to fix the underlying issue.

In the second presentation, Fedor Vompe and Sebastian Becker explained how Deutsche Telekom applies route filtering at scale, and how the content of AS-sets matters. They view AS-sets as documentation – which is often incomplete, outdated, or inaccurate. Yet, they are one of the most important data sources to use to create route filters. They explained various problems in the data, with the most important being outdated or too-broad AS-sets. ASPA (the RPKI object which is still undergoing standardisation) will be another data source for this filtering. The Q&A line was split on the impact that ASPA will have. Will it improve data quality or will the benefits only be temporary and things degrade again over time?

The session ended with three lightning talks:

• Matthew Jepp introduced NetUK, a new non-profit NOG founded by LINX, LONAP, Nominet, and PTX. They’ve already held two events and seem to be off to a great start. Their next event, NetUK 3, will be held in London on 6-7 July 2026. In response to a question about how this would be governed, Matthew said this was still something of an open question. They had asked participants and for now the majority just wanted to see how it goes. Likely this will be discussed further at the upcoming meeting.
• Then back to BGP, with Remi Hendriks from University of Twente looking at anycast in under-served regions. There were cases where traffic for a user in Senegal - a former French colony, might be routed via Paris rather than Nigeria, because of limited terrestrial connectivity. Historical colonial structures played a part here. He observed that users in a former French colony could still be routed via Paris rather than a nearby PoP in a former British colony because Internet connections could mirror historical links. In the Q&A, people pointed out that issues of political control also affected the level of service in Africa, and that good people tend to move around a lot, which affected long-term maintenance.
• The final lighting talk by Niall O'Reilly, our former RIPE Vice-Chair, described how EU funding is probably more accessible to open source communities than you think. While the EU funding agency may have requirements that don’t suit your organisation (timeline, proposal overhead, budget), cascade funding allowed for an umbrella organisation to be funded which could then coordinate concrete work projects. Projects should have a “European dimension”, but this didn’t necessarily mean they had to be within an EU member state. Find Niall or his colleague Stephen Strowes at this meeting, or follow the links in his presentation, if you want to know more.

BoF: bridging IETF and RIPE - from standards to operations and back

The aim of the Monday BoF was about bridging the gap between the IETF and RIPE communities. Both share very similar ethos – no membership, participation as individuals, ideas judged on their technical merits, and so on. In many ways, the two communities are like different sides of the same coin - with the IETF focused on defining technical documents and protocols and the RIPE community deploying them (or not). Everyone seems to agree that both communities would benefit from more network operators participating within the IETF (and more of the IETF within RIPE), so what’s stopping us, exactly?

A few ideas that were floated:

More data is needed about the overlap between the communities and who is participating. A show of hands indicated that about a third of the room participate within the IETF, though somebody suggested the results could be a little skewed considering we were at an after-hours BoF discussing IETF participation(!). The number of hands also dropped precipitously when asked how many also identified as network operators. Not necessarily a bad thing, considering a wider group of stakeholders are interested in Internet matters these days. One idea could be to co-locate parts of IETF WG sessions within RIPE Meetings, or other venues, since ultimately it is about getting the right people together at the right time.

Barriers to entry on the IETF side can take many different forms. Smaller operators might struggle to justify their attendance, especially if even making it to RIPE Meetings can be difficult. There’s the time needed to follow so many mailing lists, and spending a lot of time shooting down bad ideas might not be such a drawcard for many.

It was noted that many IETF presentation submissions at RIPE Meetings were often the “high-level info-dump” variety, while those that tended to do well were often more specific presentations about how a specific topic within the IETF might be relevant to the audience. And indeed, much of this BoF had been such an info-dump, which meant there wasn’t quite as much time available to actually share ideas around addressing the core issue. All the same time, Jim Reid said the IETF was now doing a much better job at education and outreach. Even being at the RIPE Meeting and asking for feedback was positive and they should keep it up!

Thus ended day one, and attendees found their way to the welcome reception.