.
RIPE 86
Closing Plenary
26 May 2023
11 a.m.
BRIAN NISBET: Good morning. It's still morning. And welcome to the Closing Plenary session of RIPE 86. Thank you all for joining us.
So, I'm Brian Nisbet, with Franziska, we'll be chairing this session, and remember it's Franziska's last chairing of a session.
More about that later.
So, just first off, I want to give you the results of the PC elections, and thank you for those, first of all, thank you for everyone who voted, it's very important to get the feedback from the community. Primarily, thank you to all of you who stood. It really is necessary to get new people in and move along, get new ideas, we had a really good number of candidates on this occasion but the two people who have been elected are: Doris Hauser and Clara Wade.
Onwards. Now we have our one presentation this morning, so here we go.
MORITZ FRENZEL: Good morning. Thank you. Thank you all for coming after last night's social. A friend of mine recently called this session the feel good session and what feels better than having a resilient out of band network. I'd like to share a story. It's inspired by the talk NTT gave about their OOB network. This is a show and tell.
First, I, as Brian mentioned, I am the CEO of Globalways, I am also the Vice Chairman of the Board at DENOG, and network architecture at Stuttgart‑IX. Most of this, the concept, my implementation is by my colleague who wouldn't take it to RIPE this time but most of the credits belong to him.
So a quick slide says, just to give you a perspective of what it is we're talking about. Globalways is more or less city network, even though we have 360 kilometres of our own fibre, we operate even more devices all over Germany, and the main focus of this presentation is our 19 POPs, 15 of which are in Stuttgart, seven in Frankfurt and one in Munich and our core routers and PE routers which we operate.
An important fact here is everything in there is one IGP domain, if that goes down we go down. This is something we had to keep in mind when redesigning that OOB network.
So, in general, our OOB network obviously would be favourable to just buy a circuit from a random provider that is available nearby. But when operating a city network, you're most of the time alone in your POPs, and so in the old OOB network what we did is we had this OOB stack, which basically connected serial ports to our routers, and then had a Layer3 uplink that was going over or DWDM infrastructure and was then connected just to the next adjacent POP to how at least achieve redundancy in case something in that POP breaks. And then obviously also in a more or less full mesh all around the network to chief connectivity.
The second shelf consisted of a Juniper switch which was in place to convert copper to fiber, and then very modern Cisco 2509s with more than 10 megabits half duplex adapters. Who still runs these? Good, old resilient stuff, but it's maybe time for an upgrade. And then to kind of give some Smarts to the old stack, we just put a PC engine APU in there running a custom Debian build.
As mentioned, we used the waves and where feasible circuits from other providers to connect them to the Internet. And then used OpenVPN to a virtual and redundant concentrator.
The issues: 3 are used especially in crammed city carrier cages where you are most of the time can't grow beyond the rack is a bit problematic. The power over 100 watts is a conservative approach. And since most of those POPs run on 84 volts, we also had to assign one fuse per device which was also taking up quite some infrastructure.
Then, I guess everyone who already, who has once tried to OpenVPN in a doesn't way knows that failing over is not always reliable, quite a hassle to maintain especially also to orchestrate. And if the VPN concentrator, even though being redundant somehow fails, everything goes dark. The other issue we had was that the links to the other POPs also required working ED FAs which can also fail and as mentioned in the introduction, whenever we have a catastrophic iBGP failure, which should never happen, we lose all of our bandwidth network which is the worse‑case scenario. This is the most pressing issue we wanted to fix.
So, we wanted to obviously reduce the footprint. We wanted to reduce the operational toll, and mainly get rid of the VPN concentrator. We wanted to add multiple layers of resilience and for that we choose to go via 3G, 4G or 5G, for sites where we couldn't get a second provider. As mentioned, this is the majority of the sites. We were looking into perimeter security because those are not tier‑3 data centres we're in but rather tier‑1 or a better room somewhere in the train station.
We came up ‑‑ they then picked a device, we came up this small open gear box, I won't go into dataset about, but it has four serial ports and 4 USB ports and you can use those to add even for more serial links where success. It has digital IO ports we could use for the perimeter security. It's Linux‑based with full CLI access and you can install persistant binaries on that with just 11 and a half watts of power consumption. We were in good shape and I'll come to what that means in terms of money and CO2 saved.
Then for cellular connectivity we had the issue that as most of our POPs are in train stations, therefore underground, not all POPs were available with these same mobile carry areas so we wouldn't go with, for example, Deutsche Telekom. We then found after referral from the community, wherever SIM, which is available over Europe, you can buy one SIM that goes into whatever network is the strongest there, you have power in controlling it and it also offers data pooling since most of our POPs are always available and we only need the cellular connectivity when it fails. It would be not feasible to buy big data plan in case something breaks but rather buy one big data plain for the whole network and hope that we never have to use it.
If necessary, it would offer IP Sec and private APN but this is nothing we wanted to go with.
And then for the VPN. So we were generally in the market for evaluating a new VPN solution for us because after all we are an ISP and not a VPN operator and so we would rather focus our, especially personal resources, on running the network rather than running a VPN. And so, given the current industry trends where we were evaluating this WireGuard, especially in a full measure configuration sounded perfect. By having that full mesh with point‑to‑point connections we removed the need for a concentrator, especially with the real fast speeds of kernel 5.6, this seemed like a solution that could not only help us with the OOB network but with our overall server fleet and it has quite reduced complexity compared to OpenVPN.
But even though key management is still a thing, commercial support at the time we were evaluating was not that present. We still need some sort of IP tables to ACL everything and to configure the full mesh quite a lot of sever automation is required. Then again we're an ISP so we wanted to focus on not becoming a VPN operator.
For us the solution was tailscale which basically uses WireGuard at a data plane plane tailscale becomes the control plane. It builds the full mesh between devices that need to communicate together. Completely handles DQ rotation for us. It removes the need for a firewall as it just has a simple JSON‑based ACLs that are manageable via GIT and it's audit compliant, which is a necessity especially when you have to comply with multiple regulations.
Obviously, yes, it does cost money. But ever since we switched to tailscale for the entire company we never had to worry about VPN since, and I can just recommend everyone just running a small network for themselves, give it a try, it's free for three users and 100 devices and it will be so boring because you just install it and then everything just works and it's great.
.
Obviously, yes, we rely on some Cloud software but it's very resilient for the two‑plus years we have been using it now and they have great articles on their website explaining how they achieve that.
The only main issue we face is with RFC 6598, it's the CGNAT 100.64/10 prefixe, which is used internally in tailscale and which may cause some conflicts. And just last but not least, most of it is open source and actually also been audited by the community. So, we do put quite some trust into that software.
So, then, putting it all together.
Installing tailscale on the opengear devices was fairly easy. It doesn't have kernel support, it's still returning 3.something kernel, but we don't need speed for out of band, 9,600 bouts doesn't require gigabit throughput on the kernel side. We had to add a random APN for whatever seemed to work and we threw some Python provisions together and this is one the few cases where zero touch actually just means taking out of of the box, plugging in and everything is installed which also various from hardware vendor to hardware vendor.
And then obviously we wanted to build some monitoring for it. Sadly, it's still only an SNMP and I'm of the opinion that it has served its time and we should be able to move on, but we have implemented everything in SNMP exporter and we will add our configuration to the publicly available to the generator in JAML so you don't have to in the future.
And there was a tweak by Freddie last night about RFC 3021, that should be supported by everything by now. Sadly, for Open GIT, that wasn't the case until a few months ago when we found a bug and now you can also just use a /31 as a transfer network there.
So, you can see one of our deployments in Berlin there, it's just a very small device that can be mounted at the back of a rack unit and throw in some cables and you're good to go.
So, we have also a lot of insights with Grafana to see especially which radio selected what signal strength we have there, and also to see what changes and it was cool to see the green bar at the very top which just is currently closed for the front and the back door. You can actually see when the door gets opened and for how long it was opened. So this is a very great way to verify your remote hands bills and they don't like it if you do it.
So, this was one of the few IT projects that just worked, tailscale is amazing. Installing opengear just worked, and wherever SIM just worked.
Also, having this fully meshed VPN is really amazing if especially you shoot yourself in the knee and your IGP goes down, don't ask me how I know but it helps. The door contacts are very great for verifying your remote hands bills.
Also, lesson learned that is an SAR 9001 can crash when the remote hands serial cable and produce a short so please don't produce a short on your zero ports it will crash multiple devices.
And then ‑‑ I am going to be completely honest, this was nothing we had in focus at the time first but reducing the power draw by 88 .5 watts, very conservatively, really adds up over time. So, with roughly 1.7 kilowatts less, we saved 6.2 cents of CO2 per year and this is also the 420 grammes per kilowatt hours, a very conservative number. I don't want to push any green washing here but just giving you an idea of what replacing old and dated equipment, even though it works, can have of environmental impact.
But not only environmental but also financial, with over €7,000 a year saved, the hardware break‑even for that project was in less than three years, so if everyone is looking for an argument to redo their OOB network, it basically pays for itself by the time, or by three years time.
For us, this mainly concludes the project for now. Even though we still have some work to do we are currently at 7 POPs rolled out so we have 12 more to go. We want to open source the documentation for tailscale and opengear and this will be available in our GitHub. We're currently cleaning up the SNMP exporter configuration, so it will be available. And maybe because we have written a consul tool that allows us to type consul device name and it will look it up in a NAT box and put a random SSH string together. If that's of interest to you, feel tree to reach out and we'll think about open‑sourcing it as well.
So, that's mainly it for the content. I am a bit quick here.
That gives us more time. If you want to join us at DENOG in Berlin, feel free to come over and, with that, I'll yield the floor to questions, and sorry for being so quick.
(Applause)
FRANZISKA LICHTBLAU: Thank you. Let's start with the front mic.
AUDIENCE SPEAKER: Hello. I am Will. I am wondering because you were having APUs in your POPs, you know you can put SIMs there and you can also put USB serials there, why didn't you just use them as improvement device and so on for your setup?
MORITZ FRENZEL: That's a really good remark. Mainly in the interest of time because this requires a lot of implementation especially getting LTE to work reliably on the Linuxes is an issue.
AUDIENCE SPEAKER: Hello. Does each of those devices connect to a single mobile carrier or multiple mobile carriers? Do you need to have carrier redundancy?
MORITZ FRENZEL: The SIM card switches to whatever signal is best but you can change those settings in the interface.
AUDIENCE SPEAKER: Have you ever had any problems with signal stretch and reachability being unstable?
MORITZ FRENZEL: Not at all. They have all been available on the LTE band since we have installed them but as mentioned, our initial site survey determined that this would have been a really bad issue would we have gone with just one carrier.
AUDIENCE SPEAKER: You have had better luck than I have. Thank you.
FRANZISKA LICHTBLAU: Okay. Anyone else? I assume we don't have questions in the chat? Then, thank you.
(Applause)
.
And next up, the RIPE 86 technical report.
ROB DE MEESTER: Hello everyone, I am presenting you with the RIPE 86 technical report.
So first, let me introduce the team. I found out this morning that the morning after the RIPE dinner is not a great time to take a group photo. So, Menno and Xavier are missing here. We spent three days setting up this meeting. The truck arrived on Friday and we loaded the truck on Friday in Amsterdam and one‑and‑a‑half hours later we started unpacking here. This is a small selection of the stuff we bring with us every meeting.
And it took us three days to set up and we hope to have everything packed three hours after this session.
So first, a little something about the network. Looking at the logical topology, it looks a little like this, or rather like this. On the left you can see all the networks that we operate. There is the main firewall, the DNS cluster, main router, all our servers are virtualised on two small super micro servers running VMware, ESXS 8 and we are employed using Ansible. Physically right behind that wall over there we have XXLNet providing us with an uplink this time. We have a 10 big backbone to various rooms and on the picture you can see that two super micros and the microtech switch on top of the cabinet.
So throughout this floor alone, we placed 35 access points to guarantee a good connection everywhere. And there is a couple more on the second floor as well.
As for the wi‑fi network, we ran through different networks this time with four SSIDs, we ran the main network on IPv6 mostly. And if you would like to know more about that, my colleague Ondrej wrote a very good RIPE Labs article about it and he did a presentation about it last meeting, so the RIPE MTG uses a U, which is a translation tool between IPv4 and IPv6 and we have 256 IPv4 addresses available at this meeting.
Last meeting we became aware we had some issues with, for example, nos.nl which is a Dutch news broadcaster, and some other video on‑demand platforms and many sleepless nights we found that the problem was with JOOL default allocation strategy and he contacted the developer and the developer implement add new allocation strategy over one weekend, and he called it the Ondrej Caletca [phonetic] allocation strategy, which is nice.
We have had reports this meeting that ‑‑ of problems with Cisco AnyConnect. We don't know why yet but we'll try and figure it out between meetings, like we tried to improve the network between every meeting.
So, with the main network running on IPv6 mostly there is a little elephant in the room. So I mentioned the NAT64 network also as a separate network this time, and that takes us back exactly ten years into the past in Dublin at RIPE 66, Marco Hogewoning who was then the Chair of the IPv6 Working Group he asked after the tech report, this presentation, when ‑‑ well, first of all, when are we running out of IPv4? And also he proposed the IPv6‑only wi‑fi network during the meetings. And it happened. The meeting afterwards, RIPE 67 in Athens we had an IPv6‑only network. Back then it had a very different technology behind it and a different SSID. Since the last meeting in Belgrade, we run most of the main meeting network as IPv6‑only, with a v4 only serve to legacy devices. So this means that the NAT64 network has become a little bit redundant as it office basically the same functionality as the meeting network and here is an open question, should we turn off the NAT64 network for the next meeting and only keep the main network and the legacy network? Something to think about.
Then, a little something. Someone asked me this week how the presentation system we use works. And I realised it's been a while since we presented on it so I'll do a short summary. We use two Mac minis connected to an HDMI switcher, so it's a seamless switcher so the signal doesn't drop when we switch and this is important so that the projector doesn't start looking for a signal when we are switching. So we prepare the slides of the next presentation on the decks on one the Mac minis there and when the next presentation is up we just switch the preset. We use a limit timer to show the clock to a presenter, it's on the stage here, it shows me I have four minutes left so I'll hurry.
We have an HDMI grabber which Meetecho uses to grab the output from the main screen to show it in the Meetecho interface, and that way there's no delay on the clicker while Meetecho also gets the live displays directly from HDMI. To progress the slides we use this clicker, which brings us to Wednesday, and the slides in both the main and side rooms looked like they were progressing by themselves, started living their own live a little and we quickly realise that had we bring two sets of clickers and the spare one of the main two we use one of them is set to a custom channel one of them is set to a default but parental we used the spare one and the one that's on the default, so they were interfering with each other, so, we quickly unplugged the clicker in the side room and from the test desk we progressed the slides, and during the break we set all the clickers to a different channel so it doesn't matter now which one we use any more.
So, if you are wondering how many engineers does it take to change the channel on a clicker, that's the answer is six.
So, on Thursday morning, we had another little incident, the fire alarm went off and luckily it turned out to be a technical malfunction in the building. But here is a nice graph where you can see the number of connections on our wi‑fi dropping when people left the building and slowly getting back up again.
Some quick statistics. This is a graph of the network traffic throughout the week. The first small peak you see is just the tech team setting up and then the second one is the Monday, all the way to today you can see a little bit of this morning.
Compared to the last meeting, we can see a big increase in devices that connect to our network are using IPv6‑only on the main network. And we think this is mostly to do with the fact that older devices are just slowly being replaced with newer phones and laptops.
Coffee statistics. Also very important. As you might remember, we had no barista in Belgrade due to Covid. And looking at this statistic, it might look like the numbers are up compared to Berlin, but if you divide it by the number of participants, it's actually less coffee per person was consumed during this meeting.
Some statistics of the online participation. Operating system usage seen in Meetecho, interesting that almost half of Meetecho participants joined up over IPv6, and then there is a graph of the number of online participants on YouTube and Meetecho. Of course we don't have today's stats yet.
And that was it. I'd like to thank you the web team, the Meetecho team sitting behind the desk there, and, of course, the stenographers who did great work again. So thank you very much.
JIM REID: All I want to say is thank you very much to you and your colleagues for all the great work you have done because a lot of this stuff takes a huge amount of effort behind the scenes and we tall just take it for granted. You have delivered an excellent network as usual, thank you very much.
(Applause)
BRIAN NISBET: I am going to go with the question we have in chat next.
From Sam van de Grubb: "What is the consideration for choosing ubiquity for wi‑fi APs?"
ROB DE MEESTER: We used to use Aerohive and at some point a couple of meetings ago, we did half the network on Aerohive, half the network on Ubiquiti and we asked people which gave you less problems and well the answer was then Ubiquiti, so I think that's how it grew a little. Once they are up for replacement, we'll have another look at what we'll use, but for now, these have just been working really well for us.
AUDIENCE SPEAKER: Hi. Thank you so much for an amazing network. I would just like to comment about the NAT64 network. I think it's really nice that when I'm here, I can test how it actually works. I think there is ‑‑ I am an IPv6 enthusiast but I don't have a chance to be in a NAT64 network only. And I think being at RIPE meetings gives me a chance to build trust in it and say hey, we can implement this somewhere else. I have another request, it's an IPv6‑only network without NAT64. Why? Because I want to see how things break. And maybe ‑‑ so I think that maybe there would be other people interested here to see how that works. And I think that this is a great test bed to see in practice how things are and build trust or ask questions. Thank you.
ROB DE MEESTER: That's good feedback. This is what we're looking for. So thank you.
AUDIENCE SPEAKER: Peter Hessler. Your question earlier about should we keep the NAT64 network? I think it was a great for us to build up experience in testing and get it ready and now that the main network is IPv6 mostly and is essentially doing the same service, I think we could retire the NAT64 network and then the suggestion from the commenter just before me of turning into potentially an IPv6‑only network would be fantastic and very interesting. As a comment, I occasionally do v6 only network deployments, and weird stuff breaks in very weird ways.
ROB DE MEESTER: That's what we are noticing as well sometimes. Thank you.
BRIAN NISBET: We have just a couple of other comments.
Okay, so Elvis saying that everything was perfect from the online thing apart from there was an echo for some remote participants. I'm not sure if that was their end or our end, but the comment was, there was some echo.
ROB DE MEESTER: Thank you.
BRIAN NISBET: And as he says everything else was perfect, no loss, etc., etc., all very good.
So, yes, thank you to you and the team and everybody for again another super smooth week. It's greatly appreciated. Thank you very much.
(Applause)
.
So, now I am not going to introduce Franziska, no, random switch at the last moment. I am going to introduce Cynthia to give the update from, I think this is the first ever update from the Code of Conduct team. Thank you.
CYNTHIA REVSTROM: So, as Brian just mentioned, this is indeed the first ever report from the Code of Conduct team. It was set‑up just before this meeting.
So, we received four reports in total so far. Two by e‑mail and two in person. Three of them were resolved. One is still ongoing.
And for each case, we formed assessment groups, considered if there were any conflict of interest and if there were, different people recused themselves. For each report we also discussed the report with the reporting party, and if needed, we took further actions. We delivered like what we needed to be done.
So the outcomes were that one case was outside of the our jurisdiction or responsibility. One case was passed to the PC, and they will remind the reported person about discipline during the microphone sessions.
One case legacy holder will be resolved between the two parties personally. And one case will be ‑‑ well one case was discussed and it was decided that no further action was needed.
So, just some more information about how to report.
Sop you can report to the whole team by using the form, or e‑mail. And you can also report to team members individually either in person or by e‑mail individually, I think you can probably find our e‑mail addresses somewhere. If not, I guess maybe ask us.
I don't have that many slides today. But the call for volunteers is still hope, and the Chair team I think welcomes more people to nominate themselves, and there is a link there, we can't fit it on the slide. But you can find the slides and click the link. Otherwise I think you can probably find it in another session.
I do also want to point out, even if if I don't have slides for it, that we did learn some lessons regarding that we really need to get some better tooling for next time to keep track of cases and, well, how to also produce this transparent report and such.
So, it has been a good learning experience and like of course we were never going to get everything right the first time. It's ‑‑ although I think personally it went pretty well for having never done this before and a lot of it was because we got good training from Valerie /RAOURBG who do it the training for us, and I don't think there is that much more me to say.
But I'm happy to take questions if there are any.
FRANZISKA LICHTBLAU: Thank you Cynthia.
(Applause)
And maybe also a comment from my side. We also learned a lot about the whole process, we will give probably (learned) an update over the next few meetings on what we want to change about the process, what we want to improve and we also welcome your feedback on that.
So, we have one question in the chat.
Carsten Schiefner: "What was the one outside the jurisdiction?"
CYNTHIA REVSTROM: Well, we can't really report on ‑‑ or give that many datasets, but ‑‑
FRANZISKA LICHTBLAU: He says no datasets, just how and why. I think what we can say about this is it was basically nothing on any RIPE medium, it was somewhere else on social media and this is just not covered by the Code of Conduct.
CYNTHIA REVSTROM: Yes, that's correct. Daniel?
AUDIENCE SPEAKER: Daniel Karrenberg, I think you guys do something that is not fun and you do it for the community and I think you deserve a big round of an applause for doing that.
(Big round of applause!)
AUDIENCE SPEAKER: Sander Steffann. What Daniel said.
(Another big round of applause!)
FRANZISKA LICHTBLAU: And I don't think we have any more questions, and with that, I hand over this session to the Chair team.
MIRJAM KUHNE: Thank you. And I am super proud we have this team in place. I think this is a great achievement by the community to have this process and to see it now and thank you very much for the transparency report I think that's very useful for the community. I think we're going to do this at the end of every meeting now, so fantastic.
Right. Just now to the last part of the meeting, the Closing Plenary, there are some members and prizes and. I have just found out we had the biggest on site attendance ever, which also explains the barrist a statistics because you actually had more people here than ever before and more than in Berlin. So that's fantastic. You can see some numbers there. 863 attendees on site and over 200 attendees online. And only four children in childcare but I think they were very happy from what I heard and the parents were very happy that they could participate. So it's gate. We also had almost 260 newcomers, which is I have seen a lot of newcomers here during the week and also there were also many online.
By country. You see the onsite attendance by country, it's 60 people were 63 countries here represented. Obviously most of them came from the Netherlands, which is not great because that's why we are moving the RIPE meetings around, to allow people to participate that maybe can't travel otherwise. And here are the same statistics for online participation and there you seem more distribution and more countries from, a number of more countries participated.
I have another slide here to thank the Code of Conduct team just so we get used to their faces also and that you know how to contact next time.
Thanks again.
Also, thank you to the outgoing Working Group Chairs. We had Job Snijders and Sandoche from Routing Working Group and IoT Working Group respectively who served a long time as co‑chairs for their respective Working Groups. So I thank them for their work.
(Applause)
And here are the two new Working Group Chairs. Ben and for the Routing Working Group and Peter for the IoT Working Group. So welcome to the team. Now this makes the whole Working Group Chairs team here, all the faces on one page, and thank you all the Working Group Chairs for providing such a good content and discussions during the Working Group sessions in the last two days.
(Applause)
AUDIENCE SPEAKER:
MARTIN WINTER: You forgot to mention that Ondrej Filip was also an outgoing Working Group Chair on the Open Source Working Group?
MIRJAM KUHNE: I thought he was going to step down next time but he announced it this time and ‑‑ because your terms I think say ‑‑ but fair enough, Ondrej announced that he will step down from the Open Source Working Group and the announcement, or the call for nominations will be issued before the next meeting, so, he'll still keep an eye on things in the meantime but thank you Ondrej. You'll be on the slides next time.
That brings me to the Programme Committee. This is the ‑‑ or this was the set of Programme Committee members that were responsible for this week's agenda for the Plenary. You just heard, you know, the elections for the new PC members. So thank you very much for the fantastic content.
(Applause)
.
As usual, we actually have some gifts for you. Do you want to come up and get your gifts? Alex is approaching the stage. While you are handing out the gifts I want to give a special thanks to the outgoing PC members and especially Franziska who has been a fantastic Chair of the PC over the last three terms so her terms end here and she has run a tight ship with the Programme Committee, I think. It's great to see there are so many new submissions came in, and the working well of the PC has been great under Franziska's leadership, so to speak. So, thanks, Franziska.
(Applause)
And we are very lucky that she found another important role in the community to fulfil, so thee we will be on board and we will have enough interaction with her in the future I'm sure. Also of course thanks to Milad, who is also stepping down from the PC whose term ends this time. Thank you. And welcome the two new elected PC members, Clara and Doris, they have been announced earlier in the session, so they will be part of the team in front ‑‑ before the next meeting.
And more prizes and winners and so there is a prize for the writing the presentations during the week. So we have two winners, we are not going to ‑‑ you don't have to come up on stage this time. We'll ‑‑ you can come to the registration desk to pick up your presents. So Olivier and Kerson who has won prizes for rating the talks. It's worth rating the talks, not just to provide GAC but also to possibly win a prize.
There are more prizes, there a registration raffle prize and the newcomers on‑site registration prize goes to Sam van de Groep, and the newcomer's registration prize goes to Cliff.
And you can also win a prize for filling in the feedback form so we really try to bribe you to give us, rate the talks, give us feedback, you can win something.
But even if you you are not interested in the prizes we are really grateful if you could fill in the feedback form so that will give us something to go on for next time.
And more prizes to come.
The RIPE NCC survey has been announced and during the week the survey for 2023, and there were two prizes that were announced, one is for the first, the people who filled in the survey during the first week it was issued. That goes to... There is also a prize to the person who filled in the survey during this week and that goes to Kurt Kayser, and he is here.
To promote filling in the survey, you can still do that of course.
In case you missed anything, the presentations because you were, you know, engaging with your colleagues here in the hallways maybe, there is of course the archives of preparations and the recordings are already uploaded, you can find them online. And there is also a daily meeting blog that the colleagues from the RIPE NCC are keeping up to date everyday and that's actually quite a fun read and a nice summary of what's happening.
You might have noticed if you encrypted all the way to the end of your badge there was this RIPE 86 bingo which was great fun and a number of you handed it in and if you flip that around it says please recycle your badge, please do that when you head out. There are some jars at the registration desk where you can drop in your badge and you can properly recycle them.
Now, of course this wouldn't be possible without our sponsors. So thanks again for everybody who sponsored the meeting and made it possible for all of us to cover the costs for the meetings here.
(Applause)
And if you want to be on the slides for the next few meetings, one the next few meetings we have issued a call for hosts for the meeting 89, 90 and 91 and we already had some interest during the week which is fantastic and that's the whole point of having a call issue just before the meeting so we can talk to you while you are here, but obviously this is still open so mid‑June you can still, you know, contact us if you are interested to host one of those future meetings. We haven't made any decisions yet so it's still very much open.
And the next meeting has actually been agreed and announced and we have a wonderful picture here, that we took last night on the boat, Flavio Luciani from NaMeX and Hans Petter Holen from the RIPE NCC who have agreed, NaMeX has agreed to host the meeting in Rome next time.
(Applause)
Thank you very much NaMeX, I'm really looking forward going back to roam. We have been there some time ago and unfortunately Flavio couldn't be here so I just put him on the slide in the picture.
See you next time in Rome and that ends the meeting. So, bye, everyone!
.
STENOGRAPHER: See you in Rome!
.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
