RIPE Community Plenary session
RIPE 87
30 November 2023
4 p.m.
MIRJAM KUHNE: Hello everyone. This is the Community Plenary at RIPE 87. Please find a seat. We're going to start shortly.
For those of I am Mirjam Kuhne. Niall O' Reilly the RIPE Vice‑Chair is unfortunately not here in person, but he is following online, and Brian Nisbet of the Programme Committee has kindly agreed to help out with questions, moderations and time keeping.
Thanks, Brian.
So this is the agenda. I'll give you a traditional update. It's going to be short this time. Give you an update on what we have been doing. We as the Chair team and also community since last time. Then Herve Clement, the Chair of the ASO Address Council will give you an update of what they have been doing since last time and some outlook into the next year. Then we have an interesting talk by the RIPE NCC, Mastodon or Mastodon't and they actually want feedback from the community. This is a follow‑up from what we had last time. We had a discussion that Leo Vergoda had kicked off about pros and cons of mailing lists, other communication channels, what do we want as a community, so the NCC thought about that and have a proposal. Then at the end we have a bit of an unusual topic here in the Community Plenary, we actually have a lightning talk that had been approved by the Programme Committee and we swapped some things around because we had the Rob Blokzijl award on Monday, usually you would have that here in the community Plenary but because the awardee wasn't able to stay during the week, we swapped some things around so I have the privilege to have Valerie Aurora as the lightning talk speaker here in this session and we already had the Rob Blokzijl Foundation Award on Monday. We will probably have sometime for open questions at the end. So if you have any other topics you would like to talk about, think about them now, bring them up then.
Anything I forgot to mention? I don't think so.
Just a quick update of what we have been doing.
This was last time slide so we had a few things that we wanted to get done, and we have managed to do this. We actually have reviewed the NRO NC election process and published as a RIPE‑813 just in time for this meeting. We had ‑‑ we are now having the NRO numbers Council election at this meeting following the new process and the new criteria, I am grateful for the RIPE NCC to make that happen because they had to do some groundwork to adjust the process internally and also thanks for the good discussion we had on the RIPE list to update the process. And so that we had consensus in the end and we published it as a RIPE document.
I also wanted to announce last time, I wanted to provide some extra training material for Working Group Chairs and maybe more importantly, for new or potential future RIPE Working Group Chairs, and I'm happy to announce that we have the first modules ready. I will send the announcement to the RIPE list after the meeting. The RIPE NCC did a great job so I worked together there with the learning and development team and also some of the Working Group Chairs that helped out and reviewed the modules and the trainings, it's quite nice interactive kind of visual training modules, so I'll send them out later and I think that will help the existing Working Group Chairs, with their jobs and also clarify a bit to new attendees and participants what the role is.
And there's one thing that's still yellow that I'm working on is a bit of a long term activity, I want to review the RIPE document store, the metadata, what's the RIPE document, how is it produced, what are the ingredients of a RIPE document and clarify that a bit more, make it a bit more accessible.
One thing that the community has done also since last time, was the DNS resolver best current practices task force, there was an initiative that started at RIPE 85, a collaboration between the DNS and the Cooperation Working Group, and Shane Kerr kindly agreed to be the Chair of this task force. There were many task force members and it was an active discussion, and Shane has presented the outcome at the DNS Working Group this week, and there will be a final document in a few weeks I guess. And there is sometime for feedback, I think the discussion is taking place on the DNS Working Group if you are interested in that. Then we are also going to update the page that this link leads to, that's the more information about the task force and the Charter and then the reports will also be published there.
We had a few other things we had to follow‑up with from the last RIPE Chair Nominating Committee. It's seems like a long time ago, but they had some recommendations in their final report and one was still outstanding at the last meeting and we have also finished that, and that's the, a document that describes the principles for RIPE NCC staff participation in RIPE. So that's a community document that we, as a community, you know, welcome the RIPE NCC and the RIPE NCC staff in the RIPE community, and that has also reached consensus and is published at RIPE‑810.
This is just, a new thing I have mentioned, it's the Opening Plenary, we had some local hubs following the RIPE meeting this week, in six locations. You can see the cities there on the side and they were just some impressions here from some of the local hubs and maybe some more information I would like to present to you in the Closing Plenary, see how many people have participated and how they experienced this. And we will evaluate that also after the meeting and see how we can continue this or improve it or, you know, if people felt this was a worthwhile pilot.
We usually, we always kind of during the meetings, we kind of working to continue to promote RIPE and go and speak to people and there was another student session online session before the RIPE meeting, the RIPE NCC is actually actively helping, I am kind of showing up and talking about RIPE, they are organising the whole session. There were some interesting speakers, and many students participating and some also here at the meeting. So we continued, we are going to continue to do this to attract new participants also to RIPE.
And then also we are going to continue to participate in other industry events. I was at the ICANN meeting and participated on a panel there, they invited me on a panel that they had to celebrate the 25th anniversary of ICANN, I was able to talk a bit about what happened before ICANN and the RIPE community and how it started and how the ASO started and so that was a worthwhile promotion for our community I think.
We are also working with some of the Working Group Chairs, all the Working Group Chairs to review the Working Group Chair selection processes. There were a number of Working Groups this week that had new Chairs selected. I was really happy to see quite a number of candidates stepped forward to, as volunteers to step in Working Group Chair roles, as well as the PC also had many candidates for their elections this time. I I think that's a really good sign and I hope that also means that we are becoming more open and accessible also for new people to participate and to step up to leadership roles.
So we'll continue to work on that to make the process fair and accessible.
Be and also part of promoting RIPE and a bit of PR, we have actually looked at the RIPE kind of visuals and the RIPE logo and have a separate ‑‑ have a kind of gift for you, a Christmas gift, we are going to have a new logo for RIPE. It's going to look a bit different. The slides, because it's going to be refreshing, the RIPE community and the RIPE visuals. So, if we just go through it and we can have some impressions afterwards.
So this is the RIPE logo. It's been the RIPE logo ever since, since day one I suppose, very early on. Then I am sure he is going to correct me if I say anything wrong about the initial logo, but it's been the RIPE logo and it had some reasons why it's there, it's the interconnection of people and also of the networks at the time that kind of represents the RIPE logo. So then the RIPE NCC logo used to look like this at the beginning. So it was a little NCC as part of the RIPE logo to show we are one, we are working together, the NCC is the secretariat of the community, and, you know, shows a close connection between the RIPE and the RIPE NCC. Over the years, the RIPE NCC logo has changed to this, and then to this, and then a little bit more, to that and then slightly different again, and then some new font, changed again and then to this finally.
So it kind of moved on. The RIPE logo stayed as it was and if you look at the two logos now they are very different and I don't see any relations between the two. Except for the name RIPE in there.
So, we thought okay, well let's look at this if we can maybe merge them together again.
So the goals was, my ultimate task for the design team was well, show that they are independent but still together. They are like, how are we going to do that? That was my really difficult task for the design team and the comes team at the RIPE NCC. So, but I really wanted to show, because as we know it's hard to explain what the RIPE community is and what the NCC and so, and if you don't see any ‑‑ I mean you might think a logo is not important but people look at the website and, you know, our visuals and they just ‑‑ I wanted to have a bit more of connection there again.
Also, to express, you know, the RIPE values, maybe a bit more. Kind of update it a bit, re‑energise it but still be able to keep the connection to the old logo that we are not completely losing our history.
We played around with some iterations with the cross, somehow it didn't really work. It still looks a bit like a funeral home or a hashtag ‑‑ doesn't it? That's what many people told me. So, then okay, this doesn't really work. Let's take a step back and look at the values, you know, the RIPE values, but also the RIPE NCC values because the process that went into the current RIPE NCC logo was really a well thought through process, and our designer at the time, who was actually still the RIPE NCC designer, was thinking about this very hard and he came up with this, or we together at the time came up with this values of transparency and inclusiveness, engagement, coordination, they are also the RIPE values. So we thought okay we have this logo for the RIPE NCC and these values. And so, if we look at the RIPE NCC logo, this hexagon still represented network of course and the stability and the hexagon is a really kind of a strong element, and the hexagon in the middle looks a bit like a cube, always recommended the community. You might not notice but that was the reason to put the hexagon in the middle.
And so I thought why don't we just pull that out and we have just kind of agreed that the RIPE NCC is part of the community and so we could also maybe show that in a visual way, and so then I thought we have to change the colours of course because you still want to have the relation to the old logo, so, we thought okay, let's pull out the inner hexagon and make it surround the RIPE NCC and so it looks similar but different.
And so there we are, we have the ‑‑ we had the RIPE logo like this, it's going to look like this now and the RIPE NCC logo is also going to have a little makeover and so it's going to look like this without the letters underneath. So, if you look at it, I think it still shows the relationship to the history of the RIPE, but if you look at the new RIPE and the RIPE NCC logos, they look as if they are one family right, we kind of belong together and we are one community, if you want, of the RIPE NCC as our Network Coordination Centre.
So, this is going to be the layout of the website. You might have seen yesterday in the RIPE NCC Services Working Group, fill has shown the new RIPE NCC layout, so they have the RIPE NCC colours in the background, the orange colours and the RIPE NCC logo on top and so this is going to be the RIPE pages of the RIPE website. So if you move around the website, you kind of know where you are. You see the logo on top, you see the colours in the background.
And here we are, RIPE, connecting people and networks since 1989.
Well, I am really glad you like it. I was a little bit nervous. But, no, thanks a lot also mostly to the RIPE NCC for going ‑‑ being patient with me and in feedback that we had, and coming up with this wonderful solution and this new logo. From then on ‑‑ from now on this is what you are going to see.
That's actually concludes my presentation, maybe I want to go back to the agenda. Next we'll have I think Herve.
HERVE CLEMENT: Hello everybody. So I don't know, perhaps so the idea is to go this way. So the Address Supporting Organisation, so good afternoon everybody. The presentation I think you are accustomed to , there was such a presentation from Sander yesterday during the policy Working Group, so it won't be really different from that, but it's front of a wider community. Today and so I will add very few 2024 perspective.
Okay. So, the ICANN addressing supporting organisation Address Council, very simple to understand. So the addressing support ‑‑ so Address Council is part of the Address Supporting Organisation, so they were part of the NRO AC comprising of four directors of the region, not five because there is no AFRINIC CO at that time. The ASO AC comprises of meme from the NRO Council. There is still an election ongoing to fill James Kennedy's seat would join the RIPE NCC.
15 members, so we'll see three from each region but as no election is possible currently within the AFRINIC, there will be only 12 from the beginning of 2024. So, two elected by the community in each region and one by appointing regional Internet registry on the Executive Board. Term of office is different from every region. Some function, we have to fulfil in the council is to advise the ICANN Board, there could be some questions during the ICANN meeting, they are a joint meeting with the ICANN Board of Directors.
Oversee the global policy development process. When there is a global policy connected with the IANA and in common are the region, so the ASO AC is there to see if the process is following followed in a good way.
We appoint two Board, so two directors of the ICANN Board, seat 9 and seat 10. And we appoint somebody not ICANN nomination committee.
One meeting every month remotely, and generally one face‑to‑face meeting per year.
So, composition, the current composition of the Council. So Saul Stein, the term of Saul will terminate in this December. So, no one in 2024. I am the Chair, two Vice‑Chair, Nicole Chan, who is present there, and Ricardo Patara, so for RIPE Sander Steffann from the community, and so we will know tomorrow who will be, so 2024 and 25, because it was the end of James Kennedy's term.
So, global development policy. We had a survey of how it is developed. Some interesting link you can go, the global development policy policy, we have the first link and the current global policy was in 2012. And there is in the Council, a sub‑group, a policy proposal facilitator team composed of one person from each region. So if there is a track, so the policy development and if there is a policy which can potentially be global, so they report to the ASO AC and so we can have a conversation. If yes, it could be a global policy or not.
Transparency for us is very important. There were two face‑to‑face meetings this year because we are doing important work to update our operational procedure. Why it was important because there will be only twelve people in the Council, and to be sure to reach a quorum regarding the different appointments, election, etc., so we had to carefully review that, etc., so that the reason why there was also an APNIC meeting in Kyoto in September and we saw that being face‑to‑face is very, very useful in terms of interaction and so to continue our work.
There is a mailing list active, so you can go and see on which subject we talk about.
Monthly teleconference meeting, open to everybody, so you can participate, or you can go to the link, etc., so no problem for that. And we write an an all transparency review, so it's a thing we will do in December.
So, we appoint some people as we say, so the current one for the seat 9 is Alan Barrett. So, his term terminates in 2024, that's the reason why there is an ongoing election for seat 9. CK, everybody knows, so he is seat 10, and Ron De Silva from the ARIN is the ICANN NomCom representative. So there is the election process, so we are still in the time of the nomination process till the mid‑of so I recall that there is a possibility to participate in that election, but as CK from the RIPE region is on the seat 10, it's impossible for ‑‑ so somebody from the RIPE region to participate for the seat 9 because we cannot have two people from the same region. So, if somebody here in the room from the other regions that is interested, it can participate in that election.
And so you have all the information here. Here is the link here.
As I said, so we have a very important work, more than one year, to update our review. There was some link was related to a website etc. There was a something of the voting or the quorum of a lot of things etc. So we met in Belgrade, we met in Kyoto etc., and so we ‑‑ finally we agreed on a text. So, it was proposed to the vote within the Council and it was unanimously approved, and then I went to Hamburg in the last RIPE meeting, presented it to the four directors and they kindly approved that text, so this new text, this new procedure is the one we use, so to fulfil our functions.
.
So, it's orange, so ‑‑ it's a perspective, so it's okay. So in 2024, and I say we, because so thank you to the effect I have Board to have appointed me again. So we will be only 12. And so to fulfil our day to day business, of course. There will be the ongoing seat 9 election process. So we will have to do. Randy, at the beginning of this week, spoke about the ICP 2, we saw his document, so approved at the time and Hans Petter was the charity of the AC OC, so it set criteria for the question of regional registry, but nothing for the outgoing or something etc., etc. So, there will be discussion about ICP 2, so we, at this stage, we don't know how exactly, etc., but what we are sure is it will be open and it will be a multistakeholder process, so everybody, every community etc., etc., will participate in the discussion. So no problem for that.
And we will define our 2024 work plan in December. So we will have, and you will have more information about our work next year.
And I think that ends that. So if you have any questions, don't hesitate.
SHANE KERR: Shane Kerr. So, there is not any AFRINIC representation.
HERVE CLEMENT: No. There will be not have 2024, so it's something ‑‑ so we try to very pay attention, so where the reason why, so we update the procedures, and so we try our best. So for the ‑‑ I would say for the African voice to be heard but it's something so we have to deal with because... as the ASO OC we cannot do anything about that.
SHANE KERR: Are there any thoughts of reorganising the charter? I mean to me it just seems tragic that there is a huge area of the world with literally no representation, if this body is important at all, then I think it's terrible basically, so...
HERVE CLEMENT: Yes. I tend to agree. Hans Petter.
HANS PETTER HOLEN: If I may comment on that, Shane. Yes, this body is important, and the way it's set up is that each region selects members to this body at a process of its own choosing. In the RIPE region, the process is so that the RIPE community select two of these bodies, so even if the RIPE NCC were to go away, you, as the community, could select these people. In I think maybe all the other regions, the Executive Board of the RIR actually is the last step in this to endorse the community election. In this case with AFRINIC, preventing the community to appoint anybody.
So it could, in theory, be so that the AFRINIC community could come together and figure out that, you know, we have an extraordinary situation, let's appoint, elect two people to this Board. And then, you know, I would be surprised if we wouldn't welcome them, but unfortunately that hasn't happened, so if you know people in the community and have a chat with them and see if there is anything you can do to help them move forward with the community work, because I think the AFRINIC situation is bad but it's still a way to actually activate the community to find unity and move forward again. I think that would be interesting for the RIPE community to figure out that.
MIRJAM KUHNE: Any other questions? Comments? I didn't ask for questions after my talk but I said we are going to have some time tend, so we can still talk about stuff then.
Thank you very much Herve for the update.
(Applause)
The next speaker will be Ulka Athele, the senior ‑‑ a senior ‑‑ the senior communication officers at the RIPE NCC. And she is going to talk about Mastodon or Mastodon't?
ULKA ATHALE: Good afternoon everyone, I am here to present on Mastodon or Mastodon't, a title that my colleague Fergal Cunningham is very proud of. He came up with it, he gets full credit. He can't be here today, but I am going to present on his behalf.
So, before we come to the specifics of Mastodon, I just want to remind us a little bit of the bigger picture. As the RIPE NCC, we see our role as the secretariat to the community involves providing a space for the community to come together. We want to not only have ‑‑ of course we have our own website, we are on many social media channels but we also want to bring those interested in RIPEstat and relevant topics to us. So we want to go where the conversations are happening.
At the last community session, Leo already brought up the topic of e‑mail, and reducing our reliance on e‑mail alone and the mailing list as a channel of communication. I don't want to go into that in this talk, I don't have the time, but just to say that this is one of the suggestions that we have in mind.
If you are not familiar with Mastodon, it is a self hosted decentralised micro blogging platform, basically an open source version of something like Twitter. You toot instead of tweet. But it works quite similarly in many ways. But the interesting thing about Mastodon is rather than having your content on somebody else's server, we can host our own server.
So some of the things we like about Mastodon is, we can run our own server and have greater control, which means we can set the rules of behaviour in there. For instance, just, you know, be nice, follow the RIPE Code of Conduct. We can offer a service to the community, federation and open source are values that we see resonating with the RIPE community. If you read the newspaper headlines, even today's headlines, you can see that we maybe don't want to be at the mercy of erratic billionaires, we have 20,000 followers on the platform managed by one of them.
Just to be very clear, we have our official social media channels on the main platforms. We are not talking about changing those, they will continue to run. But as someone who does work with the RIPE NCC social media extensively, we have noticed a big change in the level of user engagement on some of these platforms.
So, what is Mastodon not about? This presentation is not about talking about the RIPE NCC just launching yet another handle on yet another social media platform. It's not about having a one way stream of conversation from our side and sending administrative reminders about registering and checking in and such like. And it's not about replicating the mailing lists.
This is not my area of expertise. But my tech colleagues, thank you. Have a test instance running. They have deployed it using Argo CD but something we need to figure out is how much work this would be for the IT team if we get a certain volume of users up there.
And before we dive straight into saying let's go for this, here are some caveats. If we run a public server, if we are providing a content platform on which users can create accounts and check content, we need to have the right legal framework.
We need the right community spirit to make it a welcoming space. We are also learning about Mastodon, so any Mastodon experts in the community please come and talk to me, I would love to hear from you.
And, you know, I said that we could do this at a relatively lower cost. That doesn't make it free and we would need to look into this in more details.
Which brings me to the last slide that I have. And this talk it really more about hearing from the community about what do you think about Mastodon? Would you be interested in joining us overrun by the RIPE NCC? Do you think this is something that the community would like us to do? And if we were to do this, would we have enough community members willing to take on moderation in a manner similar to which the Working Group Chairs manage mailing lists? And with that, I don't have any ‑‑ my last slide is not questions, but do you have answers?
.
(Applause)
BRIAN NISBET: So, it feels slightly rude to go first, but I am going to. Brian Nisbet speaking as myself. May I just say that I know you are talking about keeping the social media channels you have open, open, but I absolutely firmly believe that like many sensible people, the NCC and the community should move as far away from fascist social media platforms as far as possible, while the Twitter account may stay open, I think posting should stop, and I think Mastodon or other options are there.
I think there is a question actually that I had myself which is you could just open a server federate and just have RIPE there. There is a much bigger question of the community piece.
But, this is I think the right direction. There is a couple of implementation questions to have there.
So, there are some questions on this, but I think ‑‑ I don't know how you want to run the queue Mirjam.
So, Michael Richardson from Sandelman: "What are the costs if we do not run a public server but just one for staff and other approved people like Working Group Chairs?"
ULKA ATHALE: I don't have the numbers with me so I can't tell you costs straight away. Obviously the costs depend on the number of users you have and the volume of data and how many pictures and capita they share. I think it's tricky to get into proved users versus not approved users. So our thinking at this moment. But of course we're still figuring this out. Is either we open it to the community or we keep it NCC only.
BRIAN NISBET: Also, Peter on the queue. So I can give permissions there.
PETER HESSLER: Peter Hessler, I administer a fairly old Mastodon instance. We currently have 300 average weekly users, and I think it's been around for six or seven years. I love this initiative. I love ‑‑ would love to see RIPE come to the federers. My major comment is please don't use the Mastodon software. It is trash. Like, I regret choosing it. However, migration away is quite difficult.
As far as who should get accounts or not? I think an easy way to think about it is like, who would get a ripe.net e‑mail address. You would do this primarily for RIPE NCC staff, possibly have some that are for the Working Groups, that Working Group Chairs can post themselves. And as far as moderation goes, there's two major types of moderation that you'll have to deal with. One is who your server federates with. There is a lot of let's just say extremely badly behaved people in the federers that you will definitely want to block and prevent access to. There is a lot of content that is extremely illegal in Europe, so you want to definitely make sure that's not there. And then also a lot of people that are rather abusive in general towards anyone communicating. That will need to be ran by somebody who has an administrator privileges on the server. So I'm not sure how you want to deploy that.
The other one is blocking who is basically per account. How you moderate and how you block and respond to people. But I'm happy to talk with you offline about more of my experiences with this.
ULKA ATHALE: Thank you. We have only one minute left on the timer. So...
MIRJAM KUHNE: It's okay. We'll have some time at the end. We have some slack built in there. I think it's important to get some feedback from the community. I want to go to the back mic first.
HARRY CROSS: Harry Cross here. I will admit the concept of RIPE having an open Mastodon that people can sign up should be quite frankly terrifying. The digital markets act, or the Digital Services Act is going to have huge implications on Mastodon and I think that needs to be understood, and I really think also, especially with federation, you are going to have potentially people with RIPE accounts seeing content that they are not going to want to see and associating it with RIPE. So I think that also has a potential reputational issue.
I think Mastodon can be done well, and I think I'm just going to echo what Peter said where it needs to be treated like a ripe.net e‑mail account and the communications treated like that.
ULKA ATHALE: Thank you. No, this is all good feedback and we're going to be making notes and thinking really hard about this.
JIM REID: Jim Reid. Member of the community and an antisocial member of the community. I don't do Facebook, Twitter, Mastodon, any of that stuff. I have got two comments to make. First of all, I welcome the fact we're having this discussion, I think it's great that we do this in this kind of forum and we think about these things.
One of the initial slides mentioned reducing the reliance on e‑mail. And that rings alarm bells for me because e‑mail is the prime thing that we do to try to make decisions and consensus in our Working Groups. I think maybe the emphasis of trying to move into other communications media is fine but I don't think we should be saying that we are trying to diminish the significance of e‑mail, it to be complementary to that. The mood music doesn't sit right with me from what you have putting up on the slide.
The other point I want to make is perhaps a more significant one from my point of view is that we need some metrics around this if you are going to set this up as a service or even as an experiment, we need to have some understanding of the rules by which we decide whether it's going to be a success or failure or what we mean by success or what we mean by failure. Some of us might remember we had this experiment with a new web based forum to get into the e‑mail systems before, and it turned out to be a disaster, it was mostly used for spam. But then nobody was ever in a position to say can we switch this off because nobody had been setting any metrics for it or gathering statistics on its value. So when we are talking about the costs for Mastodon or whatever, I really don't care what these other things might be, we need to have some clearly understood basis for reviewing it and understanding if it's a success or failure, and that's not just about cost. Thank you.
ULKA ATHALE: Thanks, Jim.
AUDIENCE SPEAKER: Will, Mastodon user. So I'm totally with Peter on what he said. I think the ripe.net, who gets a ripe.net account could get an account on the Mastodon server of the NCC and I think all the users here in this room of Mastodon, raise your hands. We have got a bunch. We probably already have an account and we can, as either go and request an account on friend servers and so on and I think that RIPE server could be a platform to communicate but it does not necessarily need to be something for the community because we geeks built our own server probably. But I still think it's a good initiative, but let's keep it as like a source of information really and do not replace e‑mail please.
ULKA ATHALE: Thank you, Will.
AUDIENCE SPEAKER: Ondrej, RIPE NCC, speaking as a regular visitor of RIPE meetings. One thing I really liked about RIPE meetings like eight years ago, or so, was that there were Twitter walls either on the screen when the stenography was not running or in the hallways on the TVs, and it sort of like worked very well for networking. There is this video of handing over Internet and there is my tweet in the background because it accidentally went there. So I really liked that. And of course this is gone because Twitter made it hard to create Twitter walls but maybe if we go through this Mastodon way, it would be nice to try to arrange this thing and do some Mastodon walls instead of Twitter walls during RIPE meetings. I think this would really make the networking easier for people and also read short messages from other attendees on some like public display channel. Of course moderation is an issue.
ULKA ATHALE: Thanks for that. So we had a Twitter wall and we also used to be show tweets with the hashtag of the latest RIPE meeting, that would have been RIPE 87 for this one on the RIPE meeting website and we woke up one morning and the algorithm had changed and we could no longer connect the API to us and our feed had gone blank. So the arbitrary decision making is something we're not happy about. Just so that you know why the Twitter wall has disappeared.
MIRJAM KUHNE: Thank you. And thanks for all the feedback, I was going to close ‑‑ go on. You are the last.
DANIEL KARRENBERG: Daniel Karrenberg, one of the RIPE founders, RIPE NCC staff member.
In the past, I heard you say sort of we need a legal review and we need to see what it costs and then, how it scales. That's all nice and dandy. In the past we have just called something that we wanted to try a pilot, and got around a lot of these kind of friction, initial friction to get something off the ground so it would be really nice if you could find ways to just try it, and try it with the community, and with the understanding that it might go away again if it doesn't work.
ULKA ATHALE: Thanks Daniel, I take that you are volunteering to test our test instance.
Thank you.
BRIAN NISBET: Herman Lienstromberg speaking as themself. "As a regular Mastodon user I support RIPE NCC and community efforts to get a presence on the fediverse, I would propose to start off with RIPE official accounts the ones that would get ripe.net e‑mail addresses only and would potentially extend to RIPE members in the future."
MIRJAM KUHNE: I had closed the mics.
ULKA ATHALE: I am at the meeting, please find me and talk to me after the session. Thanks everyone.
(Applause)
MIRJAM KUHNE: And we are going to continue this on the mailing list. I mean I know Fergal wanted to be here and present this and he couldn't be here, but you'll have have an opportunity to contribute to that discussion on the mailing list, so this is not ‑‑ we haven't made any decision yet. Thanks for the NCC taking this initiative to provide another communication channel for us.
Next up, is Valerie Aurora, with a lightning talk called so you think you understand IP fragmentation.
VALERIE AURORA: Hello. Just a quick note. My husband is a lawyer who has ‑‑ is available to give talks on the legal issues involving Mastodon instances.
Hello. I thought I understood IP fragmentation, and then I tried to implement PathMTU discovery.
So, what I found out is my co‑workers didn't understand either. They were also network engineers. And I discovered a tonne of people on the Internet also had different ideas.
So my question here was how to teach people something that they think they already know. I came up with frag quiz, a game to test your IP fragmentation knowledge, and I am going to tell you that. Some of the challenges and solutions in implementing it and then we're going to play it together. This means you are going to have to raise your hands or something.
At the end I'll tell you my apacketisation layer, PathMTU discovery implementation which I think has the lowest possible latency PathMTU search algorithm. But maybe I'm wrong.
A little about me. I am Valerie Aurora. I am a freelance software consultant. I specialise in operating systems, file systems and networking. He have worked on a bunch of network drivers, TCIP, ZFX, EXT 4, Union mounts and most recently a VPN.
I was implementing PLPMTUD, layer, so below something like TCP. So your job is to find the largest packet that be be send over the network to the host without IP fragmentation occurring.
So the other programmers told me that our software already never sent fragmented packets. And that don't fragment bit was set on all of our IPv4 packets. That was not true. We were all surprised when he looked things up a bunch of other people had very confident opinions about this.
So, I thought about how can ‑‑ I would love to tell people I learned something about this, how can I tell other people? I thought about replying on stack overflow, I'm like no they'll just down vote me. I saw that happening to some right answers. I thought about writing a blog post. I thought people will tell me I'm wrong. I thought about writing a programme to demonstrate it, and I thought people will be like no, I already knew that.
And nobody needs to write this programme. And I'm the one who is an idiot.
Okay. This reminded me of something I did many many years ago, a lot of years, like 20 years ago. The TCP IP drinking game. So the drinking part is optional. It was a session at early DefCon conference, I missed it, I was at the conference, I didn't go to the event we're talking like 1995. There was no videos. So I just made something up and it was literally just questions about TCP IP. I printed them out, played the first game with Alun Cox and a bunch of other people who were in Linux networking. Had some really good questions to add. Yes, the tea pot is in there. Everyone thought it was super fun and we all learned a lot for things about networking. And I just want to say the real TCP IP drinking game I finally found out was just answering questions with the largest number of acronyms possible. Mine's better.
So, I decided to write frag quiz. This makes you guess what will happen when a particular kind of packet is sent, it records that guess and then it actually sends the packet and compares it to your guess. At the end it tells you your score and then it encourages you to send it to someone else, kind of like Wordle.
Here are my implementation goals. I wanted to have minimal setup. So people would ‑‑ this is supposed to just be fun. I don't need to you configure things all day long. I didn't want to to require super user privileges. I didn't want to write any packet tracing code. I didn't want to get fooled by segmentation off load to the NIC or virtualisation or loop back. I found so many bugs in things that I was not trying to find. I am like I'm not emulating this in any way. I I didn't want to one a require running a separate server programme. I hate that. And I wanted to be able to test IPv6 with only link local addresses. More on that.
.
So, the thing that solved most of these things, which I am sure half of you thought of just now, you lower the TTL or the hop limit on the packet. And use an unprivileged ICMP listener. So, a few operating systems allow to you open an ICMP listener for ICMP packets without super user privileges. Then you can set the fragment socket option to what the user requested on the socket that you open. You connect to any open TCP port on any server, that's at least one hop away, although it ended up being more than one hop. Same thing for UDP. It doesn't need to be running any particular thing because the packets never get thereafter the handshake.
So you set the TTL or the hop limit to a low value, send the packet, listen for the TTL hop limit exceeded message and then you parse the IP header to find what did it send.
This sounds easy in practice, and in theory, in practice I found a lot of other bugs.
In particular, this isn't a bug it's just a lack of feature that Linux should consider if they want people to develop on their platforms as a macOS first developer I say. So, macOS allows all kinds of, a bunch of different kinds of ICMP messages, including time to live exceeded, but Linux only allows echo request or reply. I was like play this game, run it as root. You can do it on macOS without running it as root but not for Linux.
So yes, there is a kernel patch in mind to make this happen.
Many networks don't generate the TTL or hop limit exceeded correctly or at all. Thank you, for the ‑‑ I had to go to the RIPE meeting to get a network that did this correctly for both IPv4 and IPv6. But it's only the legacy network. I'll tell you exactly which one here.
So, I did ‑ lots of people don't have IPv6 connection at home. I don't. I didn't check, what was I thinking? I tried to make it work with a link local addresses. I wrote a little tiny baby port scanner to be like is anybody listening? And sometimes somebody is. It doesn't work yet. I think I need to force the hop through the router. So fortunately we're here. This is the legacy 87 network if you want to run this. I'm not getting IPv4 TTL from the RIPE meeting one.
This actually kind of doubles as a check to see what your network does.
Just a few implementation details. You may have noticed if a router, if the router reassembles the packet before it sends the time to live exceeded, you are not going to be able to tell if it was fragmented or not. Who would bother doing that? Well actually, a lot, including my home access point. So what I do is the programme automatically probes until it gets back the fragmented version of the time to live exceeded. So, it's gone up to six on some of the networks. I think the RIPE one is three for both IPv4 and IPv6. My home is only two.
So, and one of the fun parts about this is that the MTU cache in the OS changes the behaviour ‑‑ the PathMTU, sorry. And I'm still working on the code to clear that. For now I just reboot. That's part of the fun.
I guess we're here. I am so nervous. You know what demos are like and I have been finding bugs all day long. So, including one about 15 minutes ago. In fact I just kind of left it in there and called it a feature. All right. So we're going to vote and all that good stuff. Are you ready to play?
Yeah!!!!
We are probing. We are getting three, okay. If we send a packet 2000 bytes long on a TCP 4 socket with the do frag socket option, will the don't fragment bit be set? We're going to vote yes over here and then no over here. Put your hands up. Yes? The don't fragment bit will be set on the packet?
No, the don't fragment bit will not be set on the packet? Okay, we're getting no. Let's see what happens. Will the packet be fragmented? This is kind of a gimme. No, it's not. It's not going to. Okay. It's TCP. What's happened? Don't fragment bit is set. So, there we go. That's next run. If we send a packet 2,000 bytes long on a TCP 4 socket with the do frag ‑‑ let's see, it's ‑‑ the default is to run the default socket option, then the do fragment socket option, then the don't fragment socket option. We'll do it again. We'll say yes. And this time it's right. Okay. Let's see. Now we're doing don't fragment. So, this is an interesting thing. What does it even mean for a TCP socket to have the don't fragment option set? Whatever it is, you can only do it once on macOS. Linux actually does define it because it's all about PathMTU discovery not about fragment or don't fragment.
So, will the don't fragment bit be set on the packet? Yes? And then no? All right, we'll say yes. I honestly don't know. I have no idea. I have been playing this all day. I am all right, we got one. Let's see. Now we're doing UDP 6. 2,000 bytes long, UDP 6 do fragment, will it be rejected because it's too big? Yes? No?
No. Okay. Will the packet be fragmented? Yes? No? All right, I just want to point out, no matter what's happening because I am wrong constantly about these things, people disagree. Yeah. Okay. Really it's so rare that I get this right.
Well of course half the time it's a bug in my code. So, you know... it's not the existence of the next header it's the type of the next header. That that was really hard to figure out because it was reassembling it.
2,000 bytes, UDP do frag will be rejected because it's too big? Yes? No? It's the same. Let's just do it again because of the three things. So, on Linux, there is more than two values. And the default is like weird and it's not don't fragment or do fragment. So that's part of why if you run this on Linux you are going to get one PMTUD, then you are going to get do frag and don't frag. Guess what, there is a fourth one: Probe.
We'll do the same thing again. Now, we're doing don't fragment. Will it be rejected because it's too big? Yes? No? All right. I think that one is actually right.
For once!
I understood that. All right TCP 6. What does do fragment even mean? Does anyone care? Will the packet be fragmented? No. I think this one is a gimme. This was the one that was like this is a bug because of course.
So, do frag again, same thing, and then we have don't frag. What does it even mean? We'll say no. Okay, we're doing better. Final, I think this is we're getting very close. UDP 4. This is old school. We have got don't fragment that actually means something. What do you think? 2,000 bytes long, do frag? Will it be rejected because it's too big, yes or no? No? Okay, yes. I agree it will be no. Will the don't fragment bit be set? Okay. Will the don't fragment bit be set? Yes or no? We're getting more nos. Will the packet be fragmented? Yes? No? We're getting there. This is familiar, more familiar. This is the same thing again. Sorry about running it with the duplication.
All right, and now we have got don't fragment. Will it be rejected because it's too big? Yes? No?
Okay. It will. I do know that part. Ta‑da! All right we played the whole game. We got 15 of 19, which is better than I have ever scored. You got the whole summary here, which is way too long to post on social media or something like this. This is the secret version of it that you can put on your Mastodon post.
So, I think we have got a little more time. I'll just show you on Linux one time. Which I just rebooted because I wanted to clear the PathMTU, the cache.
One PMTUD is the at all times and it does surprising things constantly. So I recommend running it with udp 4 or TCP 4. Let's see what happened here.
Okay. With ‑‑ so everybody, what is the default setting on Linux mean? It's never talked to this host before, it has no idea there is no state. What does PathMTU discovery want mean? We're sending a packet that's too big for the socket, we have what ‑‑ will it be rejected because it's too big? Yes? No?
I think it's slightly more no. Will the don't fragment bit be set? Yes? No? Okay. We have got yes. That's a combination. Let's see. The packet was not too big. And the don't fragment bit was not set. Let's see if that keeps happening. Let's say no again, and then we'll say no again. Will the packet be fragmented? Yes.
All right, so what I always end up running these a few times with the answers from the last time and then being like oh, no. It's not the same.
Let's do TCP 4. At this point does it know about PathMTU or not? I don't know. Will the don't fragment bit be set if we're sending a packet with the path discovery want? Yeah? No? Now we're getting to the like what? I don't even know. We have got one hand for yes, let's go for it. Yes. I don't know. And let me see if UDP the same thing. We said no. Before it had no don't fragment bit. It's different now. Welcome to the PathMTU cache.
I think we have got three minutes left so I'm going to tell you about my packetisation layer search algorithm.
All right. So credit where credit is due. I co‑implemented this on a packetisation layer similar to WireGuard with Salman and James Tucker.
RFC 8899 says "implementations could optimise the search procedure by selecting step sizes from a table of common PathMTU sizes." I use some research published at RIPE meetings actually to be well these are the PathMTUs that are out there. Importantly, different than MSS.
So, we just sent all packets of all of the sizes all at the same time, and the biggest one that came back is the PathMTU. So, to keep it up to date every ten minutes you have a timer, you send your current PathMTU plus one byte size packet to see if the MTU increased, if it did you send them all again. It's got one round‑trip latency. There is only the timer that you have to have to reexplore the PathMTU. It worked. Surely somebody has implemented this before? I couldn't find anything written down anywhere on the Internet. If you know someone who implemented that, please let me know. I would love for this to be part of things.
All right. I guess we can have questions.
(Applause)
AUDIENCE SPEAKER: Shane Kerr, how big is that table? How many packets resending?
VALERIE AURORA: It was like, it was less than ten and we were trying to get jumbo packets. That was the whole point of it was to automatically detect. It wasn't like every single one but all of the binary search algorithms described are like stop looking when you get this close. So it's like within ten, 20 bytes of pretty much everything you ever see.
ANDRE: Andrei, RIPE meeting tech team. Would I first of all ‑‑ I'm not very happy for you promoting the legacy network because we don't want people to use it. We want people not to use it. And also, I would like to ask, did you by any chance did this testing on the main meeting network today around 12:08?
VALERIE AURORA: Okay, so what I have been doing is like doing everything I can do on my phone's IPv4 network and then whenever I have to test it with real Internet, I come and sit in the back hall there. So ‑‑
AUDIENCE SPEAKER: Why I'm asking is that we see a weird anomaly on NAT64 it it has basically 100 kilopackets in and 200 kilopackets out which means that incoming traffic is probably not fragmented and outgoing is fragmented which happens usually when you send in 1,500 bytes into IPv4 and IPv6 because it's 20 bytes more bigger header it had to emit two fragmented IPv6 packet therefore we have double packet rate on the one direction which is very strange for a translator.
VALERIE AURORA: Wouldn't it be nice if the PathMTU was detected correctly because one the things I find over and over again is that the tunnels are not generating packet too big correctly.
AUDIENCE SPEAKER: That's a very common issue.
VALERIE AURORA: That's why you should do it.
BLAKE WILLIS: Blake Willis, Zayo. Just curious, I don't know if you can disclose it or not, but do you have a specific use case for needing a larger MTU versus just setting it to like whatever the lowest common denominator that most of the VPN junk out there uses. This is cool, don't get me wrong.
VALERIE AURORA: Here is my take, that the future of Internet ‑‑ of the Internet involves a lot of, even on ‑‑ even inside of one organisation's network, they often have to send a lot of data encrypted, and they want to just have that happen. And so, that also to go very fast. So yes, I have been surprised to discover there are people who want automatic, highest bandwidth possible transfer of tunnelled traffic. So yes.
I would like to know I started out my networking career working on Hippi, H‑I‑P‑P‑I, which has about a 64k packet size, sorry, you know, on that layer. So physical layer size.
MIRJAM KUHNE: Have we any other questions, comments? Nothing online. Thanks again.
(Applause)
.
This concludes the formal agenda, are there any other questions or comments for me, the RIPE Chair team or any other things you want to have discussed during the Community Plenary maybe next time or you still have sometime now, please, Rudiger?
RUDIGER VOLK: I have been attending all the RIPE and IETF meetings in person since it was possible again, so, kind of my understanding of the remote part of our hybrid meetings actually works.
What I observe is that in IETF, actually the really nice Meetecho is quite strictly used, and the remote participation in many of the Working Group sessions is pretty heavy, and I would guess that the strict use of the Meetecho queue is a part of making this possible.
Looking at how we are operating in RIPE hybrid meetings, I am seeing that Chairs or helpers are checking the question and answer thing, and the queue is essentially at least not used for people in presence. And once in a while I observe that the Meetecho queue was actually present and the requests there were almost overlooked.
Again, I have essentially only done presence in the hybrid meetings since they are around and I have no personal experience on the remote end. I think we should collect experience from there and I would guess that actually making more use of the Meetecho technology would help to be more inclusive towards the remote participants.
MIRJAM KUHNE: Thanks for that comment, Rudiger, yeah I have seen that also at the IETF and we can discuss this further, also with the Meetecho team but also I noticed that yeah, since we started here with the hybrid meetings we were a lot less disciplined as a community to use the Meetecho queue to manage the queue. The IETF is surprisingly kind of disciplined to even people in the room they use the Meetecho queue to answer questions, but no we are definitely going to look into how to continue to make it more inclusive and I am really curious to see what the local hubs think about their experience participating in this meeting.
NIALL O'REILLY: It's working now? I just wanted to confirm what Rudiger was describing from my experience earlier today. It's difficult to get in and it's easy to be overlooked. So it's something to put on the checklist for the next one. But what I really wanted to say was also something that may ring some bells with Rudiger. When I came to the first, my first RIPE meeting, it was RIPE 3 and I was working for an organisation called Earn which was founded in 1984, and I wanted to let people know that I'll be saying more on the RIPE list in due course, that there will be some kind of anniversary event in the new year, and if anybody who is present at this RIPE meeting is interested and wants to get in touch with me, this is a shout out.
MIRJAM KUHNE: Thanks, Niall. Rudiger, do you want to respond?
RUDIGER VOLK: Just one remark. I had a couple of tries going to the mic in presence or remote and yes, there is a learning curve and kind of the contributions from Niall kind of confirmed that. But the learning curve is short and it should be used.
MIRJAM KUHNE: Yeah, thanks for that. We really need to make sure that we include remote participants, that's like a reminder for myself and all other session Chairs and Working Group Chairs I think for the future. Thanks for that.
AUDIENCE SPEAKER: Andrei from the RIPE NCC, RIPE meeting tech team. Regarding Meetecho, I also had a chance to visit an IETF meeting and I would point out some differences from what we have here. First of all, with IETF, you are mandatory to use a single sign on and you basically single sign on to authenticate yourself for a Meetecho. In RIPE meeting, so far, we haven't had this requirement. So attendees of RIPE meeting don't have to have RIPE NCC access account. We don't enforce it. Maybe if we enforce it, and it's a question for the community, then we could make it much easier because the other that I think that the IETF sort of requires, because it replaces this famous blue sheet, is that basically everybody who enters the room has to scan the QR code in front of the room and enter the mobile client and therefore everybody has their mobile client with Meetecho and everybody can raise hands in the mobile app and this makes the hybrid process much more straightforward. Whereas here, again we don't enforce to give floor only to people who who are raised hand in their mobile application, because it's quite struggling for to pick up the link for the mobile application from your e‑mail that they received on Monday. So, my point here is, we, as the RIPE NCC, can replicate what IETF has, so we can put Meetecho behind single sign on and require every RIPE meeting participant to do a single sign on which will make it ease we're no log on from their mobile. The question is whether you participants, or we participants actually want this.
MIRJAM KUHNE: Thanks for that.
BRIAN NISBET: Peter. You are muted or you need to request audio again.
PETER HESSLER: Peter Hessler, remote participant. I have to say that having used the IETF system and the RIPE system for using Meetecho, I find the RIPE system far, far easier. I generally do not have my RIPE credentials on my phone. What would I have to do to edit my LIR from my phone? And so I find the link from the e‑mail far easier to deal with, I just keep that e‑mail on my phone, click it, it does the thing and I'm happy camper. If there is a better app that would save credentials and save access, especially in the web interface, then that would make my life easier because I could just authenticate once, keep a bookmark, use it for the week and then delete it.
MIRJAM KUHNE: Thanks Peter. Niall, are you in the queue? Could you mute please? And then is Harry in the queue?
HARRY CROSS: Harry Cross, speaking on behalf of myself. I just wanted to come off ‑‑ the back of Ondrej's point and kind of give a bit of experience from what I have seen this week. I have spoken to a number of sort of people my age here, and I have actually been told I don't have a RIPE account. And A) I kind of wanted to figure out why that's that the case. I think that's more people who are here on behalf of an employer who don't necessarily interact with the RIPE community other than being here. But B) I think that's just goes back to the meeting point of do we want to put a wall to interaction in there?
MIRJAM KUHNE: Can you clarify what you mean when you say a RIPE account?.
HARRY CROSS: They don't have an account on RIPE.net at all.
MIRJAM KUHNE: Oh the RIPE NCC access account. Just to clarify. Exactly. I think there was Andrei's point that not everybody has that and therefore we have a different system
RUDIGER VOLK: As far as I understand it, and I use the stuff, I think just the URLs for the Meetecho that are distributed are sufficient to actually join.
MIRJAM KUHNE: Because you just joined on the Meetecho queue and now you are at the queue.
We'll look into this.
AUDIENCE SPEAKER: Ed Lewis. Having gone to the IETF a few weeks ago and here, in terms of the in‑room experience, I find it a lot easier to manage the Meetecho for myself off the phone and at the IETF when you go to the room you scan the QR code, you get the credentials and it works that way. Here, I didn't have that option. I used the laptop one time and I found it bulky to have my laptop open and trying to balance that. I think for in person, making the meeting queue management off a mobile device is much easier. I don't have remote attendees, I can see why the laptop is better. I want to add that experience for in‑person.
MIRJAM KUHNE: Thank you. I think Andrei has another comment.
AUDIENCE SPEAKER: I have to react to this because I wonder whether people here were present on previous meetings. The previous three meetings that happened after Covid, every time we put ‑‑ we used to put this QR code into your badge that was meant for to be scanned as a personal link that opened the mobile app. Well it was a lot of work for us because we personalised the QR code and we had to stick to to every single badge and we haven't really seen people using it so we stopped doing it. And ‑‑ but that was the way how we could like get you on to mobile app. So well we were thinking about how to get people to use Meetecho. It would be really nice from our point of view to make everybody in the room on the Meetecho mobile client so they could join the queue. But, at the same time, like it has to have some kind of realistic expectations around it.
MIRJAM KUHNE: Thanks for that.
BRIAN NISBET: Speaking of people who joined the queue by the way, Hans Petter is in the queue.
MIRJAM KUHNE: Was going to say thanks for that and maybe we we didn't do a good enough job to advertise that or make people aware how it works.
HANS PETTER HOLEN: Just to make the point it's really easy to click the link in the e‑mail. It's not a technical barrier for the participants. If it wants to do this we start at that time Chairs that gives priority to the queue and tell other people sorry you don't get to speak in the microphone unless you are in the queue. It's that simple. We can make it easier technically but it's the human behaviour that needs to change here and I think it's a really great idea to give the remote participants easy access. I wanted to prove a point.
JEN LINKOVA: Jen Linkova, Working Group Chair who could not join the queue because my phone is dead and there is no power to charge it. But besides that I actually totally agree, as a Chair do I prefer people to join the virtual queue even if they are in the room it's much easier for the Chairs to know which order to call people. You also can see their names. If you don't know someone, it's much nicer to see the names, and you, over there on that microphone, yeah. But on the other hand it's always another hat because you need to remind people to do this and people tend to forget about that when they go to the mic. But in general I agree, using the queue would be much nicer as long as you have power. Thank you.
MIRJAM KUHNE: We'll see how we can change human behaviour before the next RIPE meeting. As I said it's also a lot on the Chair, me, the RIPE Chair and also Working Group Chairs to encourage people to do that. Right.
BRIAN NISBET: Nothing else in the queue.
MIRJAM KUHNE: I thought you were disagreeing with me. Thank you, Brian.
BRIAN NISBET: I would never.
MIRJAM KUHNE: Is there any other topic you would like to bring up. Any other comments, last call? If not, there is a bit of an early coffee break, or ‑‑ we are done early but there is still a coffee break and there is another session afterwards which is the diversity and inclusion session which is unfortunately in the other room, which is not very accessible but we'll talk about that when we get there hopefully. It's in the side room because unfortunately we have to empty this room, it's because the hotel needs it for something else tomorrow and they need to set it up. That's why all sessions tomorrow will take place in the side room and today also the last session will take place in the side room.
And then of course we have the dinner after this. So, hopefully we'll see you all at the dinner, all the information are online. I don't really know. There is shuttles, I suppose, but I haven't checked the times so please look that up.
(Applause)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
