Cooperation Working Group session
24 May 2023
9 a.m.

JULF HELSINGIUS: Good morning, I am here to hand over to Desiree who will actually introduce the programme.

DESIREE MILOSHEVIC: Good morning everyone, thank you for being here, we are waiting for a very exciting programme ahead of us. We have three presentations and the first one is dealing with the Internet standards platform. So if our speakers are in the room, I would kindly ask them to come up to the podium. The second one will be about the Cooperation Working Group small task team and the third agenda is ‑‑ item is on EURALO. So the floor is yours, welcome.

BENJAMIN BROESSMA: Hi. Welcome you all. I am Benjamin Broersma from the Dutch Internet standards platform better known for I was supposed to be here with herben, but unfortunately he was unable to make it due to personal circumstances.

So, who are we? Well, the Dutch Internet standard platform is the organisation behind the test tool And we are a public private cooperation from parties from the Internet community like RIPE NCC, the Internet Society, which gave us our nice domain name. The SIDN of the .nl TLD which does the DNS for us. And the government, so, the ministry of economic affairs and climate policy, the Dutch national cybersecurity centre, and the Dutch standardisation form and some other associations.

So, we were founded in 2015 and our goal is to jointly increase the use of modern Internet standards to make the Internet more accessible, safer and more reliable for everyone.

And the rationale in 2015 was well, the incentive is necessary because adoption is faltering due to market failure and the adoption of multiple standards in the Netherlands is lagging behind various surrounding countries.

This was, this market failure was researched by the central planning Bureau of the Netherlands, and the causes of this market failure were the say symmetrical information, so how do you identify reliable market partners which implement these standards correctly? And coordination failure, how to get a safer Internet standards adopted because of course there are multiple parties involved there? And there is also a first mover disadvantage. If you are the only one who implements certain standards, for example DNSSEC validation you end up with consumers which might say well why isn't this working? Well because you actually complied to standards.

So our product organisation, we had the Internet standards platform and below that is the product team which I'm a member of, and we have two steering committees, one for everything related to Internet dot NL. So that's actually everything with .nl, it's our website, our PI, or dashboard and our question centre which is questions at internet .nl. We have the communications, external appearances we have a toolbox with how to implement these standards correctly, and we did some zero measurements for .nl TLD.

We also have a steering committee for the secure e‑mail coalition, that's a group of a lot of organisations who wants to improve on e‑mail standards.

And we organise meetings for our platform members for the secure e‑mail coalition and for API users.

Last year we went to, for example, the one conference, the Internet Governance Forum. We also applied for, to do it this year.
And we have quite a network of government business, inconsistency, international of organisations we collaborate with.

So, what do we actually do? Well we promote modern Internet standards. Which standards are those? Well, IPv6, we want modern addresses for a further growth of the Internet. DNSSEC we want signed domain of the integrity of the domain data. HTTPS, secure website connection. We also test for security headers and security TXT. We also want anti mail spoofing, so we check for the correct settings of those and secure e‑mail connection, so start TLS and Dwayne and routing security, although it only prevents of course a very limited amount of route hijacks.

And last year, RPKI was added in collaboration with the NCC of the Netherlands, and security TXT was implemented together with DDC, the digital trust centre of the economic affairs of the Netherlands.

So, we have, we call that our single scan version because you enter one domain at a time. It tries to be transparent in what it shows you and gives you guidance in how to configure some settings correctly. We have a Hall of fame. If you score a hundred percent, you can do that for the web test. You can do it for the e‑mail test and if you are in both, we will also put you in a champion Hall of Fame. We also have a Hall of Fame for our hosters which themselves comply and let their clients comply to be a hundred percent. And our test baseline is based on the Internet standards of the comply or explain list of the Dutch standardisation forum, the security describeses of the Dutch NCSC and the relevant RFCs of IETF. And last year in 2022, we almost did 700,000 tests.

How does that look like? We have multiple tests. We have a website test which mainly checks for the web standards. We have an e‑mail test which does the e‑mail part and we have a connection test so you can test your own connection if it's IPv6 compliant.

And we mainly score that on a percentage. And if you score a hundred percent, you comply with all these main tests. But for every test, we also have a sub‑test, and you can click through that and even though sub‑tests you can expand and see the exact configuration of your servers on IPv4, on IPv6, because sometimes those servers differ in settings, and will give you hints on how to improve.

So we also have the Hall of Fame of hosters. If a hoster is scoring 100% of their own website and e‑mail domain, and let their clients also be able to score 100%, well if they ask us we'll put them on this list, also to promote further growth, because we also get users who ask us like which provider should I take? Well we have a list for that.
We also have the API in the dashboard, we have an AI for bug testing. We did almost 3 and a half million tests last year, and we have overall testing where you can do the bug domain but we also have the domain datasets. But most CEOs, CIOs, they want a dashboard, so we also have a GUI for this API and you had add bug domains on that and it will test them monthly or twice a month, and you will ‑‑ you can track the changes over time of the Internet standards. So, maybe something is changing on some of yours domain portfolio. And you can see the adoption statistics of all these separate standards.

And you can export them on a spreadsheet.

We also have the toolbox, which is basically our GitHub read me page, and there are lots of how‑to's for DKIM, Dwayne and also very specific like how should I configure Dwayne correctly on my Postfix or on my MX and how should my SPF or a multiplex record look on my part domain name, so it will advise you to put a new MX and stuff like that. And we will also link to interesting external sources there.

So, all our code is open source, and you can collaborate on that. It's on the GitHub. And it's reused by several other countries at the moment. It's used at the moment by Australia, by Denmark and Brazil and some other countries like Portugal and Singapore, they also have a similar testing service and they took quite some separation from And actually at the moment, there are some other countries who are showing interest, but at the moment it's a bit hard to set up the codes. We are improving on that.

So, for the future, we are implementing some new, to test some new standards and to test more datasets. So, we are expanding on existing tests, for example the testing DNSSEC settings, and we also see quite some specific DNS failures, we want to give back to the user more explicitly.

We are working on an interactive e‑mail test, because at the moment our e‑mail test is passive so we only check the MX server but we also want to check the sending server and the standards, if you can actually send to internationalised domain names or internationalised e‑mail addresses etc. We want to test the presence of the CAA records, that's the record to limit, to restrict the CAs you can use for your TLS certificates. And we want to do RPKI validation in the connection test, so we have the connection test for your own ISP and there are ‑‑ we're looking into combining multiple RPKI validations, for example of CloudFlare and then NLnet Labs, they have a validation for that, to combine them all together because we see at RPKI it really depends on the route you're taking if it's filtered, so if we combine more we might get a better view.

But the main effort at the moment is simplifying the installation primarily based on Docker container registration. So, if you want more, so people here presenting who wanted to have some standards adopted by us, well submit them in our GitHub and we will discuss them in our steering group to see if we can implement them.

So, we're also working with the statistical office of the Netherlands, CBS, and since 2020, they are doing cybersecurity monitoring and part of that is they are investigating the average scores of companies every year. And actually, we see that company's score a lot lower than the Dutch governmental side, so companies at the moment score like 65% of all the Internet standards and the government scores quite a bit higher. So we see more than 20% difference. These percentages are based on the amount of sub‑tests you score correct on, so it's not really scientifically, but we see companies are lagging in these standards. So, since there are quite some companies here, my thing is: Modern Internet standards keep our Internet open, free and secure. So let's use them!
And also for everyone of you, go to and fill in your own e‑mail address or your domain name and see actually which standards at the moment are correctly and not so correctly implemented. And every time we do this on somebody who didn't do this before, every time they see like configuration errors in their setup of DNS or other stuff.

So, with that, I want to conclude. If you want a dashboard or API access, currently we can only do that for a non‑profit. If you are a non‑profit, you can send us an e‑mail. And for everyone else, we're working on the container version so it will be easy to host an instance of yourself pretty soon so you can test your own customers or your own internal network with that.

And if you actually score a double 100% on your e‑mail and your website test, then you can send us an e‑mail and we will send you a T‑shirt, a nice T‑shirt of us and a mug for your coffee.

So, follow us on these platforms and please fill in your own domain name on

Are there any questions? ?

AUDIENCE SPEAKER: Thank you. So that was the threshold for participating in the discussion. Peter Koch, DENIC, thanks for that presentation and I know this is a longstanding effort that has developed over time and it's really good to see ‑‑ cover it more and more and I also think that having a view of the population and the development and the deployment status is very interesting. What made me go to the microphone is that a couple of times you mentioned the correctness of the standards or implementation and then you also talked about configuration errors. Now, we had a discussion yesterday and the gentleman right next to me mentioned that a couple of she is standard configuration options where reasonable people can come to different conclusions and not all of the advice would apply across the Board.

So, my question would be: Who decides in your case who decides what is correct, and how do you deal with competing schools of thought? And also, with more complexity and more complex standards or protocols, I should say rather than standards, protocols that you evaluate, differently good options might actually flourish and develop in different directions so how are you dealing with that inherent ambiguity?

BENJAMIN BROESSMA: Thanks for the question. It's a good one. We try to stick to RFC recommendations. So, part of that we adopt, but then we also have the Internet or the standardisation forum which gives advices in the Netherlands how to implement or set certain things and the Dutch NCC. So we try to stick to the formal settings they recommend and not invent our own. And if there is discussions, we do that in the platform or with the steering committee. But indeed, there are multiple ways to have settings, or have your configurations, and it's very valid point. But we try to stick to common recommendations or guidelines set‑up by, for example, the Dutch NCC.

AUDIENCE SPEAKER: Hi there, Martin butter man. Thanks for the excellent work that you do and the team does, and I know Herman would have talked more about the platform which is really a multistakeholder gathering to talk about what's important, and you're serving that.

My question is specifically about the code, it's been available for a long time, and it's been attractive for a long time. When do you think it will be easier to implement and so you indicated it will happen, what is the change that will happen and by when do you expect this to be easier than it has been so far?

BENJAMIN BROESSMA: The setup in the containerisation, yes, we expect to go live with that at the end of this year. I have it working on my computer at home and I'm not a developer of, but I'm being able to run it and patch it at the moment, and without the Docker setup I wouldn't have been able to patch the code I think. But now I can just run it and test it. And this is also, for example, we have interest from organisations in Spain to run this, and yeah, this is one of the things they are waiting for, to have an easy setup, yes.

AUDIENCE SPEAKER: Excellent, because for sure already gives the opportunity to test, but it's so good to have it in the local settings and I can just testify that in the IANA there is a big interest too. Thanks.

AUDIENCE SPEAKER: Niall O'Reilly. This time wearing my tolerant networks limited hat. It's a small registrar and research development campus company in Dublin and we use these kinds of dashboards from time to time, and I'm very enthusiastic about them, this one and the other one that deserves mention is Zonemaster from AFNIC and IIS. And when trying to use these, there often appears a gap between the helpful messages that come on the dashboard and the toolbox resources that might be linked to those messages. The toolbox is there, the messages are there. It would be nice to have maybe an information button beside the message saying perhaps you need to look at this part of the toolbox because finding the toolbox entries can almost be a bigger challenge than setting up your configuration in the first place.

BENJAMIN BROESSMA: Yes. We're trying to improve on that. So, we have the technical view if you go back to the sub‑test, and in those sub‑tests, if we see we get a lot of questions for example about content security policy, we got quite some questions, so we now have a dataseted split out of especially what sub‑test case in your CSP is not so preferable. And we also try to link to different toolboxes, but that's mainly from our toolbox, because yeah, it's ‑‑ there are lots of linking to implement these standards. And we try to gather them on our GitHub toolbox, yes.

NIALL O'REILLY: I'm looking forward to seeing where you take that.

AUDIENCE SPEAKER: There is an online question which isn't actually a question, it's Carsten Schiefner. Not a question but a comment. Thomas fair bank has set‑up an e‑mail tester at e‑mail ‑‑ security ‑‑ scans ‑‑ org, maybe these two efforts can be combined or linked to each other. In fact Thomas is with the Dutch university but I have forgotten which one.

BENJAMIN BROESSMA: We recently talked with him about implementing this on because we also worked on codes previously and we had some half setup but never put it in production and this really looks properlies, so we probably will integrate this or part of this in our code base, yes.



DESIREE MILOSHEVIC: Right. We're back to the second item in our agenda, which is the Cooperation Working Group small task team response to the EC survey on the future of electronic communications and digital infrastructure. So I will briefly talk about the timeline. You may recall the Cooperation Working Group set‑up a panel in May last year to talk about fair share contribution, and since then, in January, we have formed a small task team of seven volunteers that I'll introduce, and they have prepared and worked on the response on behalf of the Cooperation Working Group community.

So, the timeline, as I wanted to share with you, started in January 2022 when the European Commission had published its declaration on rights and principles, and that particular declaration deals with how the digital transformation will evolve in the EU, and since then we have heard from some telcos and incumbents conversation where they think that in particular, content access providers or caps, should be contributing financially, they should be, towards their businesses and our small task team has focused on the work of the ‑‑ sorry, somebody is clicking the slides and we need to go back.

So, there we are. ‑‑ anyhow, we have worked on this and submitted our response on May 19th, last Friday, and we have shared it with the Cooperation Working Group and to just make this short, I would like to thank all the volunteers that have come forward, and I will introduce the team, that's Patrik Faltstrom who was a previous Cooperation Working Group Chair from NetNod. Fraud Sorenson from N come ‑‑ and Constandina Coamatis also a member of the Working Group, also Thomas online I think goer, Carsten Schiefner, Alex de joode from AMS‑IX, and Christian Dell or ago a. I chaired the work of the Working Group and we had support from RIPE staff, /SPWA*D yen got Linx, so with that I'll pass it on to Alex to take you through the response that we have prepared and take it on from there. Thank you.

ALEX DE JOODE: Good morning one of the main issues we saw with the fair share proposal is that it tries to implement a telecoms termination model on the Internet model. There are three core principles for the working of the Internet model so we could show that the Internet is designed in a very different way and obeys different rules when compared to the traditional telephone network. We felt that attempting to reverse or undermine these principles would potentially disturb collaborative relationships that exist today on the Internet.

Therefore, for us, it was of the utmost importance to ensure that these principles are upheld and maintained, to sustain the future of our digital infrastructure.

The three core principles we distilled are:
If I recall, the core net neutrality principle; in this context it's essential to ensure that Internet traffic is exchanged between autonomous systems without discrimination whether at an IXP or provider level, and is not subject to traffic manipulation, bandwidth throttling or intentional blocking.

The second principle we devised was the network resilience principle. It's a crucial factor in the future of a stable digital infrastructure, only a diverse network of large and small network operators can contribute to achieving network resilience which is necessary for further growth. Local provisions of inter‑connection unhindered by a regime of mandatory contributions can enhance network resilience by ensuring that that can can be routed locally even if there are disruptions in other parts of the network.

Thirdly, the Internet is based on autonomous systems this means that each operator of an autonomous network is responsible for the maintenance, upgrades and policies of its own network.

It's therefore, also responsible for the financial part of this network. And for how it connects to the rest of the Internet.

The only minimum requirement is to be part of the global Internet that you speak IP. This autonomy is what allows the Internet to scale and drives innovation.
It is our concern that where cross subsidies occur for instance for content and application revenues in the lower layer connectivity functions this would create market distortions, unfair competition, user capture and failure to serve innovation.

In our submission, we highlighted that regulatory instruments should be evidence based and developed to support the model where each level pays for itself. The traditional and very successful Internet model.

Thank you.

DESIREE MILOSHEVIC: Welcome Frode we can here you and we can see you so please go ahead.

FRODE SORENSON: You can go back to the previous slide please. The questionnaire consists of many questions, 62 in total, and there are questions related to different aspects of the Internet and we have concentrated on the core questions related to the fair share discussion, and the very core question is question 54, as we have presented on this slide. It goes like this:
The European declaration on digital rights and principles states that all digital players benefiting from the digital transformation should contribute in a fair and proportionate manner to the costs of public goods, services and infrastructures to the benefit of all people living in the EU. Some stakeholders have suggested a mandatory mechanism of direct payments from caps/L T Gs to contribute to finance network deployment. Do you support such suggestion and if so why? If no, why not?
And our answer to this question is: No, and we have provided an explanation which is presented on the next slide.

And it goes like this:
"The quote "Contribute in a fair and proportionate manner to the costs of public goods, services and infrastructures"
‑‑ does not only indicate that caps might contribute to ISPs But also indicates that ISPs might contribute to caps regarding goods and services.
It is necessary to take the whole Internet ecosystem into account.
And both ISPs and caps are mutually dependent on each other.
Caps contribute with content and applications as well as platforms and network infrastructure.
And finally, end users contribute through their Internet access subscriptions.

And in case such a mandatory mechanism for direct payments were introduced, a termination monopoly will emerge which ISPs with end users connected may exploit, and such market development will need regulatory oversight and regulatory intervention may be needed, and we here refer to the termination monopoly which we have seen in the telephony networks. And for these reasons among others, there should be no such mandatory payment mechanism.

And I hand over to the next speaker. Thanks.

DESIREE MILOSHEVIC: Thank you very much.

CARSTEN SCHIEFNER: Thank you. Can somebody flip ‑‑ here we go.

Additionally, to directly answering the question as Frode has just read, we also took the opportunity to go a little bit into deeper matters and also as the space on the web form was limited to I guess 1,000 aracters per question we felt it's not really prudent to ‑‑ it's not really sufficient, to press our answer, our elaboration noose 1,000 characters only. We took the effort to chance, the opportunity also to come up with further elaboration, what we call the tech account perspective on the Internet wholesale interconnection ecosystem. The main points here are and were, were and are, that obviously, as we all know, the Internet architecture is totally different from the traditional telco system. The architecture is layered with a multitude of competing wholesale ‑‑ and obviously so obviously we have a multitude of competing wholesale providers connecting that entity that is ultimately responsible for the providing access to end users is so‑called E IP Internet access provider, connecting those guys, these entities to the Internet as a whole. And it's been always the case, and we don't see any reason why this should actually change that each or both parties is solely responsible as having been let out by roulette do have earlier, the speaker on Monday, for fully funding whatever they are doing. And each of the parties is also entirely free to choose whatever they would like to be implementing, whether they would get the full picture as in getting wholesale services into the umbrella as well as Internet access service or whether they would actually only provide Internet access to end users and would get the upstream on a wholesale basis.

And so, in your name, as in the RIPE community, we stated that the RIPE community is of the opinion that there is no failure in the Internet inter‑connection market and it needs to be recognised that the inter‑connection market is based on a very specific financial model. First of all the Internet works and it works on the basis of a permissionless innovation, as in everybody actually can put on the network what he or she intends to do so. The result of that is a rich diversity of applications. And also, it should rather be seen as a sign of a healthy network instead of like a dysfunctional network somehow, if the share of revenue flows from that is much lower than those of services and application running over it. Yes, I'd like ‑‑ now I'd like to see the next slide please.

And I'm rushing through this as we don't have much time left anyhow. And we state that we also see an anti‑competitive if that one part of the industry, say the Internet access providers, whether they are fixed or cellular based should claim a revenue share from all the other industries and that cross subsidising from application Internet works would increase the damage rest the better connectivity of network networks on a regional basis because they would break current mechanisms for establishing local traffic valuations between the various networks. And the traffic valuations is something Patrik would go into further detail because that's a very crucial implement in any negotiating inter‑connection regimes between connect providers.

It also intervenes in content and service delivery, so adding risk to permissionless innovation.
And looking at the financial incentives and whether established mechanisms for charging access to the Internet, this might be prone to be broken when there is an artificial incentive coming up to the market that is called cross subsidies.
And last but not least, any kind of contributions from the content applications providers towards the business of Internet access providers would likely result that the caps, the content application providers, would have to raise their prices a bit to recoup these costs from the end users who would then actually be participating twice, once directly to the Internet access providers an then indirectly as well because of higher prices to those providing services on the Internet, on the access to the Internet they are actually using.

That is my part. And I hand it over to Patrik. Thank you.

PATRIK FAHLSTROM:: Set of slides will try to do is to explain a little bit how traffic is exchanged between various players. And most people do think and do understand that if it is the case that you want to Internet access from an operator, you actually pay for the connection. So money flows from the end user up to the left to operator one and money flows from the end user down to the right, to operator 2.

The question that, though, is what ‑‑ who pays for the connection between the two operators? So, this portion of the presentation is talking about the various ways operator 1 and operator 2 connect traffic, how they negotiate and who pays whom. And specifically, try to explain a little bit the difference between transit and peering that everyone is actually getting Internet access sort of from someone else because you actually want to, always to be able to access someone far away that you don't have direct connection to.

And now forward to a large bunch of sites ‑‑ go forward and pass all the slides with text, please.

So, what we talk about here is that the operator 1 and operator 2 do get money from their end users. It might also be the case that the end user is a content provider is connected to multiple operators. This might be a picture that sort of looks a little bit weird and the question is: Is actually the user paying to two operators, the discussion that we had that cart ten talked about, explains why money flow between operator 1 and operator 2 the money flow, the direction and the size of money exchanged which can be zero is based on the value of the traffic that operator 1 and operator 2 sees. And what is a value? That could be geographical coverage, is could be the content, it could be eyeballs, it could be whatever. We live in a market economy and pure negotiations between operator 1 and operator 2 ends up with a result that talks about how money is flowing given that traffic is exchanged between operator 1 and operator 2. That is the red line.

At the bottom you see that the RIPE NCC, in this case as the end user S connected to two operators and the question is how can we evaluate that picture? And then you go to slide 38 please.

If it is the case that we view the network that we just created like this, that the end user down to the right actually have two roles. It is a content provider that pays for the Internet access just like the end user up to the left and just like we saw in all the other pictures, and then the end user has another component which is an operator, in this case operator RIPE, or RIPE NCC, and then we suddenly have three different connections here which are red, and all three of them are negotiations between operators, free negotiations regarding transit and peering and the money flow is based on what each one of the operators see as a value of the traffic that is flowing. So, as Carsten said, I'll repeat it once again, we do have a model where the end users pay for connection to the, to be able to send traffic to the rest of the Internet and then between the operators there are pure negotiations on how money will flow if it is the case that money Mr. flow the end result might be zero, and how to implement that with PNIs or using an IX or however they are doing t it's a pure market economy. We have innovation and the conclusion is because of this, nothing has to change and there is no need to have regulation intervene in market economy at this point in time.

Thank you.

DESIREE MILOSHEVIC: Thank you very much, Patrik. Because we are aware of the time, we would like you to send any questions you might have could the Cooperation Working Group mailing list and we'll find out what was happening with the clicker sides the other room had the same problem and we are interfering and not peering well. So, with that, I would like you to give a round of applause for the small task team.
That worked very hard, and I hope you appreciate our submission. I will now ask Sebastian and Nathalia to come to the stage and give their brief presentation. Thank you.

SEBASTIAN BACHOLLET: Thank you very much. I am the Chair of EURALO, representing Internet Society France in the arena. The first November in 2017, European at large regional organisation and the RIPE NCC signed the model of understanding. We are part of ICANN in different bubbles. As you can see on the blue one, the dark blue one, there is the RIPE NCC, and on the red, dark red, we have at large and within at large we are one of the five regions, and we are taking care of gathering the end user about every topics linked with Internet. As we are a member of an AC, that means an adversary committee, compared to the Address Supporting Organisation, we are able to talk, participate, to act on every topic linking with Internet things done within ICANN of course. And I will give now the floor to Nathalia to tell you that we both of us, were re‑elected for an Erik Romijn it of two years as a secretary and Chair of EURALO.

NATALIIA FILINA : Thank you very much. Hello everyone, my name is Natalia Filina. I am secretary of EURALO and thank you for having us here today. Thank you for your explanations, Sebastian. So we're a really unique structure because EURALO consists of 38 IOSes cloaked in 18 countries and territories as well as 72 individual members and five up servers from other regions. And we use the links in this ‑‑ so you can use the links in this presentation and look at attention and our structures and names of participants and I'm sure you will find a lot of useful interesting information for you for your future work, together for our future work together, and part of EURALO members as well work in RIPE community.
Organisations and individuals who are present in the interest of end users and locally work for them, from various aspects not only from technical aspects of Internet governance. At the same time, we have an excellent relationship, as Sebastian already said, and great cross connection with other global region from around the world, and we can reach out to any country, large region and compare end users experience, problems, issues. We may attract expertise and we can find a way to start the common project and we do that successfully. And at large has great linking within the ICANN and all supported organisations.

So, as we know now, the RIPE is already a partner of EURALO, but as the partnership should develop around the community crossing the beneficial effect of interaction.

I think the most effective way to improve reality for us is to understand that we have some, not problem, but issues, and we should break them down and break the barrier to achieve common goals.
In this slide, is a short set but very important set of things we can solve. So we have some misunderstanding of the mission roles and task of the communities, as we can see. Maybe we not always talk that ICANN European region is much larger than Europe only, and we are very diverse in legislation area in our practice, task and end user issues, and we understand that.
So I think it is the same problem for you and for us, we have a small active core of active participants, and as you, we need a strong use voice too. We have divided space and networks and as geopolitics now is an issue for us too.
And so, I think I can talk a lot about our ideas for cooperation and for our opportunities to be more close to each other. We can do capacity building activities together. Please join us as a participant of our workshops, or as a speaker guest, you are very welcome.
We can do a lot related users experience research and doing measurements. We can gather metrics, we can distribute the news and we already do that I think perfectly because we always provide the space for your feedback news for your articles, for your opinions, for your voice, and please ‑‑ so use us, we can be your voice in the community.

But the most simple and most productive way is to join us to take part in ICANN development processes and public comments and broader discussions about Internet governance and of course suggestions from RIPE are very welcome.

So, for what people we can develop our relationship? So, everything is simple, transparent and so when you do think about our benefits from working together. We can get new expertise and contributors, we can initiate together, very important discussions and we can correctly address issues to solve. We can spread information and so we can have a very productive and pleasant networking. And we understand that when we are talking about the level of communication between communities and organisations, we understand that we will work together as volunteers, so that it's good enough not just to spend another 20 or 10 hours per week for work together, but maybe achieve another result together.

Thank you very much for having us. So see you after the session and we will be happy to answer your questions.

SEBASTIAN BACHOLLET: Thank you very much and I would like to take this opportunity to thank particularly Chris Buckridge who is always willing to participate in our meetings and to give his insight on the different topics we are talking about. Thank you for having us here.


JULF HELSINGIUS: Thank you everybody and thanks for having the patience with our technical issues that made us a little bit late. Technology is wonderful when it works. Thanks all for coming. This concludes the session. Thank you.

DESIREE MILOSHEVIC: Thank you so much. The small task team stays dormant in case the fair share thing goes up again.

(Coffee break)