Archives

RIPE 73 Madrid
Plenary session
24 October 2016
3:00pm

CHAIR: Announcement: Please don't sit at the end of the chairs, because then people cannot go in, please fill in all the chairs. This room will be completely full, so don't leave places in the middle. Thank you.

Let's start the meeting. Welcome to Madrid. I would like to ask Hans Petter to address us with a few words. Thank you.

HANS PETTER HOLEN: Thank you very much. And welcome to the RIPE 73 here in Madrid. This is a huge meeting. 654 so far, and 435 registered.

I thought maybe I should introduce myself first, normally I have a slide telling me who I am, but anyway... I am Hans Petter Holen and I am the Chair of RIPE. I am from Norway and I am really excited to be down to sunny Spain, except it wasn't that sunny yesterday, but I hope it will be at the end of the week.

So, welcome to this meeting. The RIPE meetings are open to anyone. Anyone interested in discussing Internet, numbering resources, how to make the Internet in our service region better. We bring people together from different backgrounds, culture, nationalities, beliefs and genders. And we want the RIPE community to be safe, supportive and respectful.

So that means please be nice to each other. This is what we're here for to interact and work together.

In case you feel that that's not the case, we have two trusted contacts, Nick and Mirijam, are you here? If you ‑‑ I can't see any of the audience, because I have this Flash light in my face, but I trust they are out there.

So, approach them if you have any concerns.

We have a pretty full meeting plan. As you can see here, we are starting at the time which is more convenient for some of us adhering customs, starting at the first session at 10 o'clock, we have one one‑and‑a‑half hour sessions as usual, and the programme here is on the website and you can see.

If you look in the evening, there is even something to do there. There is, today, a welcome event and you can also meet the RIPE NCC Executive Board. There are some drinks. There is a party on Tuesday, and on Wednesday, there is no social because the RIPE dinner is on Thursday, so, on Wednesday, it's a do‑it‑yourself social, so that means that you have all of today, tomorrow, and Wednesday in order to get some friends so you can actually get somebody to have dinner with or go partying with on Wednesday.

So, I would like to say thank you to all the Working Group Chairs, because the Working Groups and the sessions on Wednesday and Thursday would not happen without their efforts. You can see all their pictures here. There are normally two or three chairs per Working Group and they are all selected by the individual Working Group. So if you have any questions regarding any of the Working Groups, please approach them.

One thing that was discussed at the last meeting where I actually threw on the table a proposal for how to select my successor, not because I want to step down, but because I promised Rob Blokzijl, who was the previous Chair for 25 years, that I would come up with a procedure for selecting the future Chair. So I presented a proposal that has been discussed there was some other thoughts and concerns and there was sort of a need for more discussion on this. So, we set up a mailing list, RIPE share discuss, and we actually also found sometime on the agenda tomorrow, so there will be someplace where we can actually discuss how to proceed with this process.

We're in a very special auditorium today. This actually brings back the memories of the early days at NIC.AF we were in an auditorium at the national institute of high energy physics in the Netherlands, for nuclear science, and we were sitting in place like this, we didn't have fancy microphones. But, we need to have a bit more discipline that we are used to. There are remote participants watching and all the Plenaries and Working Group sessions are recorded. So, if you want to speak here, you need to raise your hand, so, after a presentation, we will ask for questions. It will be close to impossible to do questions during the presentation, we will ask for questions after the presentation. Then there will be more lights on. And then when you are told you can speak, then he need to press the button so that you have a live microphone, state your name clearly and then be ‑‑ make your comment as brief and concise as possible so that the presenter can answer that. This is kind of very different from what we are used to, but since we are all engineers and open and inclusive and treated well, this should be no problem at all, right?

So, Programme Committee: Benno. This week would not happen and would not have the excellent content it has if it hadn't been for the Programme Committee, so I'll let Benno say a few words.

BENNO OVEREINDER: Welcome, also from all my colleagues in the Programme Committee. As you can see, we are, a lot of faces here, there are 13 PC members, eight elected, I'll come to that later. Four appointed and one local host. From the eight elected PC members, they have a seat for two years, so every RIPE meeting, there's two seats for election. So, this week also. So, I want to announce that, and it will be renounced, that all you, all the attendees here, can nominate themselves, send an e‑mail to the PC and with a biography and a statement why you are interested to join the PC, we all invite you to send this to nominate yourself. And that's possible until 5:30, I guess ‑‑ no, 4:30, the nomination will be closed and at five o'clock Tuesday, you can present yourself. So that's for the elections.

For the other numbers, we have are the number of submissions to the Plenary programme, we have a very good number of submissions; 34, from which we selected 16, so there is all good quality presentations during the week, and we hope you enjoy that. And to express your, well, appreciation or disappreciation, rate the presentations. So, get on RIPE NCC access account. Rate the presentations, it will really help the presenter and us to improve the programming or just say how great it was, we also like that, we like a pat on our shoulders, so, that one ‑‑ and finally, I want to make this clear, that we still have lightning talks and there have been crazy things going on last week, probably will be more crazy ideas this week, submit lightning talks with crazy ideas or good ideas, submit them to the PC submission system for the Friday lightning talk session. That's about it, I guess, and rate, rate the presentations please. Thank you.

HANS PETTER HOLEN: Thank you Benno.

So, I already gave you a teaser about the socials, but to make sure that you don't miss out on this, there is an opportunity to meet the RIPE NCC Executive Board today from 7:30 to 2 p.m.. Then there is the welcome drinks for everybody if you don't want to meet the RIPE NCC Executive Board or how this works out. Anyway... you can continue drinking after meeting the RIPE NCC Executive Board.

Tuesday, there is a party at [Nugarmon] and on Thursday there is the RIPE dinner and the details are on the website.

We are trying something new this time. Trying to be new and innovative. A lot of you have said that you come to these meetings in order to network, that's not IP packets, but to connect and talk so in order to figure out how to connect with other participants in the meeting we are testing a tool called pathable so you can going to this URL and register yourself, everybody has got an e‑mail about this,nd you can use this to book meetings with other parts participants. We are really interested to hear your feedback about this afterwards, so please tell us about your experience with this tool in the feedback survey that will be online on Wednesday.

So, for those of you who remember Rob Blokzijl, you will be pleased to know that the RIPE NCC Executive Board has decided to set up a Rob Blokzijl foundation, so that means that the RIPE NCC has committed to give some money to set up a foundation that will be used to honour Rob and recognise the outstanding achievements in the RIPE community. So, how that will be done and what that will mean will actually be discussed in the RIPE NCC Services Working Group on Wednesday. So, if you are interested in this, make sure you are there.

So, now we have a meeting in front of us and I have talked about being open and inclusive and it's a pleasure for me to be here in this corner of Europe, because RIPE has actually not been to Spain before, as far as I understand ‑‑ we have been been to Barcelona, but that's many years ago ‑‑ but we need to realise that we have a huge service region. RIPE is not only about Europe. As you can see, it's also the Middle East and central Asia. And this means if you look at this map on where we have had the meetings, you will see that they are various centred around, let's say, Amsterdam and short distances from there. We have been fairly good at extending towards eastern Europe, but we have not done a good job yet with going to our eastern parts of our regions, so the process of setting up a future RIPE meeting has been in place for several years. There is a call for proposals posted publicly, where the RIPE NCC will then evaluate these proposals and then eventually they will discuss with me as the RIPE Chair on where to hold future meetings. So, what I'm looking at this map and seeing that we need to make an effort to move even further east. We have a huge community in the Middle East and in the central Asia, Russia, former Soviet republics, where we all should make an effort to bring the RIPE meeting.

So, as you can see here, the next RIPE meeting is planned to be in Budapest, and the meeting following that we have planned to hold in Dubai in the Middle East. So, of course, the Middle East is extremely pleased to see that the RIPE is coming back to their region.

So, with that, I would like to thank the host, ESNOG, and Espanix and all the sponsors who are making sure you get coffee and socials and things like that and I would like to hand back the microphone to Cristobal and Joao.

CRISTOBAL LOPEZ: Thank you for coming. Welcome to Madrid. It's a pleasure for me to have you all around here. Remember that the famous tongue twister, the rain in Spain falls mainly in the plane. It's not true, it only falls in the plane in October and November.

Who we are: Simply we are the largest IXP in the Iberian Peninsula, that includes Spain and Portugal. We have working for more than 20 years since our incorporation back in 1997. We have over 350 gigabits of traffic per second. And plus, 80‑plus members now. We include all relevant ISPs in Spain and the significant Portuguese ones. And we have the best data centres in Spain. They are mainly based in the Madrid area.

We are a few peculiarities. We are non‑profit based. We have a station behind that takes care and controls the running of the node etc. This makes all members out fighted equally in voting and prices, which is something that some members don't like, but most of the members do like. We have a seven member board, they are not paid, we pay for lunch when they come to the meetings. We are only based in Madrid and the Metropolitan area, we have a data centre which is in the north of Madrid, and we have an extremely lean organisation, we have very few people, our costs are very low and prices are also low.

Last, I would like to acknowledge a few things. First of all the RIPE meeting team for helping us doing this. For coming to Madrid, for not using the famous bull, which is used for the logo for brandy trademark, and instead using something more modern and fancy. And also ESNOG for their cooperation, it's coming up next, without their help we wouldn't be here. Okay. Thanks all.

(Applause)

JOAO DAMAS: Hi. So I'll start speaking. Maybe some of you already know me, I tend to do a few things around here. And I am speaking as a local host for the ESNOG part. What is ESNOG?

This is ESNOG. A bunch of people that get together and like to look at the intricacies and internals of things. We don't exist as an association, or organisation of any type. We are much like RIPE, a community of people that want to share experiences, and tinker and so on. So of course with this being the truth, we are always open to have anyone join us that wants. Normally, when we meet, we talk in Spanish because it's a common language for us, but we have plenty of people who speak other languages, so anyone, absolutely anyone is always welcome.

The people who tend to spend more time on ESNOG, we'd like to ask them to stand, Fernando, [Wanpay], Isobel, who is ‑‑ you see them... feel free during the week to ask us if you need any help with having some fun in Madrid, we will be happy to advise you.

There is one organisation I would like to thank for helping us out with our role as hosts, that's cold communications, that's providing the network for this network, they are extremely helpful, very proactive, had things ready very early. If you want to join us ‑‑ or next meeting will be 6 and 7th April in Barcelona, that's two days before EU IRX meeting, if you happen to be attending that, come early and join us.

As you may have noticed, there is a few oddities, as Cristobal already said, people have an image that Spain is a sunny place, except when you are in the planes, as Madrid is. I have ordered some better weather and so we're getting that on Wednesday, I hope they will do their job properly.

You have noticed that the times, the starting times this time are different. We start the meeting at 10 instead of the normal 9. There is a reason for that. It's not that the people in Spain like to sleep more than anywhere else. But if you look at this map, the red vertical line is Greenwich, you will notice that this country is actually west of Greenwich, but we have the same time zone as much of eastern Europe. That's historical, thanks to events that happened around the year 1939, and we haven't gotten around to fixing that yet. So, specifically German people are not allowed to complain about this. !

Finally, and this is more of a request. I have seen quite heated debates lately and one of the things that I heard and I really appreciate of this community is how we will have been working together for so many years, and so I have a special request for everyone during the week, to treat each other well, because this is the way we used to deal with things back in the day in Spain, and it never ended up well.

Thank you very much.

(Applause)

CHAIR: Thank you Joao. Hello again, my name is Jan Zorz and I will co‑chair this session together with Benno and keep the housekeeping. Next one in line is our Spanish IPv6 friend. He spent a lot of time on IPv6. He spent years of practice in IPv6 and he did a lot of work so I would like to welcome to the stage Jordi Palet Martinez.

JORDI PALET: Let me tell you the small history about this survey. Actually, when I deploy and train customers about IPv6, they ask me what other ISPs worldwide are doing, and of course I have the knowledge about some my customers and some others, but I didn't have the real picture about how it's being done in a real way by other ISPs around the world. So I decided to make a small survey, just an e‑mail shot to the IPv6 RIPE Working Group mailing list and then I received many more answers than I expected. So I decided to make it a real survey, and that's the reason it happened.

So, the survey is trying to look only into residential networks, not incorporate IPv6 services. And it's not also trying to look into cellular networks except if you are using a cellular network to provide broadband residential access. Those are the technical questions that I am covering in the survey, and I am going to look into them one by one.

The first interesting question is, looking at the Apache locks, is the people responding to the survey actually using IPv6 well? 31% is doing so. Something I forgot to mention in the first slide, I am doing an update of the survey every month, so probably you can see several versions of the survey, I will always mention the month and the year, so we can also look at the evolution of the responses in the survey.

So, again, 31% of the responses come in IPv6, which means it's not that bad. It's one third of the people working on it actually using it.

Now, the question is who is responding to the survey? The survey is open to be responded by the ISPs, but also to be responded by customers of the ISPs. What I need to do, and this is not an easy attacks, because I got already 1,200 responses, is to try to avoid duplicate responses from the same ISP, which sometimes is easy because the people say what is the name of the ISP, but some other times I need to look into WHOIS and other data to see the IP addresses, both IPv4 and IPv6, and all kinds of responses trying to classify which countries they come, which regions and so on, to avoid as much as possible duplication.

Most of the time is actually the employees of the ISP who are responding, but I also got many, many customers responding and typically I can determine if they don't provide the name, if it's the ISP responding or the employee, because ‑‑ if it's the employee of the ISP responding or the customer because the customers typically have less technical information, so the answer is less complete. One decision I took at the beginning was as much as possible, not make mandatory all the responses because otherwise I know many people will not complete the survey.

Another thing I can realise looking at the responses, is that most of the people have both IPv4 and IPv6 allocation, so it makes sense that they respond to the survey, because if I see a response with no IPv6 allocations, that's really surprising to me obviously.

Other things I can realise, checking of the survey, is many times I see fall backs from IPv6 to IPv4, and I am wondering if this means we are hiding IPv6 errors, deployment errors by using happy eyeball, so I wonder if this is an IETF debate, we need to start thinking in happy eyeballs as not a very good thing for the IPv6 deployment because actually as I said we are hiding many problems with IPv6 deployment.

Regarding who is responding in terms of the regions, well, basically, it's more or less quite balanced distribution, the curious thing is that there is one big country, which is Brazil, which has I think it was 200 responses looking at the responses yesterday night, so that balance, let's say, the number of responses in LACNIC as being much higher than in the other regions compared to the number of countries, right, but it makes sense anyway, because the size of the country.

One interesting question is, I did the survey initially only in English and then I started doing translation to say different languages because I realised that not having some local languages, I didn't get the responses, and that was the case for Brazil, that was the case for China, Japan, South Korea, and of course the Spanish version, which was easy for me as well.

I know you can probably don't see the slide, but you have the slides that you can check later. The thing here is, as I already mentioned, Brazil is probably the one with more responses, followed by other countries like North America, basically US, and then I think Japan, China, and a few others. But more or less, it's quite well distributed in the rest of the countries.

Looking at those responses, what I can extract as information from the responses is, in some countries the deployment of IPv6 is much higher than in others. For example, looking into the regions, in APNIC, there is a very nice penetration of deployment in Australia, China, Japan, Malaysia, New Zealand and we are missing a lot of responses compared to the number of, let's say, IPv4 ISPs from countries like South Korea and India. In ‑‑ obviously it's US and Canada, LACNIC there are a few countries which are responding but, for example, a big country like Mexico is not providing responses, and that makes sense because there is not a lot of IPv6 deployment in Mexico. And the same for the RIPE region, where most of the, let's say, northern countries are responding and less in the south are actually providing responses.

Is this meaning? There is some addition, let's say some regions actually performing better in the IPv6 deployment or not? Well, clearly in AfriNIC there is much less deployment than the rest and LACNIC it depends very much on the country. There is a big difference between some countries and the rest.

Regarding the technology: I think, and probably it's better to go into the summary already, I keep the pie charts because this way you can look at the data. The deployment, it's clearly going faster in newer technologies so there is a bigger percentage of deployment of IPv6 in FTTH or even DSL than other technologies. I think it makes sense because newer technologies probably have newer CPEs, that means they support in a more easier way updates or whatever, IPv6 instead of looking into old DSL deployments which are very cheap DSLs that maybe the vendors are not interested to update. One of the questions I was trying to look at also is, there are some specific deployment problems related to the technology or specific to vendors, and in my opinion, the answer is actually not. Maybe a few years ago, but right now there is deployment in basically all the technologies, all the access technologies, so I don't think there is a problem there.

One of the main questions obviously is, are you already doing IPv6 in a commercial way or is it a trial or a pilot? Well, as you can see, half of the people is not responding, that means probably it's because the customers are responding and they don't actually know if it's commercial or just a trial service. But from the rest, we can see that most of the people responding, it's actual a commercial service. So it's 31% is a commercial service. If we include the people not answering.

So, basically, I set it, I think 52% is the responses not answering. So, most of the responses which probably are more informed because they are the employees of the ISPs responding are actually a commercial service.

I will skip this and go into the conclusions.

How you are deploying the point‑to‑point links. So most of the people, which actually 61% is using a /64 for the point‑to‑point link, for the WAN link and the other responses are a variety of them. So I have people responding 126, 127, 112 and there are some interesting responses I don't really understand and the only explanation is the people is misunderstanding what I mean with the one link and they understand that it's the prefix delegated to the customer, which is actually the net response.

Another question is: Are you making this point‑to‑point link addressing stable? And only 11% of the people is doing that stable. Understanding that 71% is not answering. So, we look at the people really answering. It means a lot. Because it's probably more than half of the people actually having a stable prefixes for the one link.

Another question is: Which kind of addresses you are using? And most of the people, 63%, is using global Unicast addresses. There is another interesting thing is, I submitted a few years ago an Internet draft suggesting that it may be a good idea to use for the point‑to‑point link the first /64 of the customer prefix. So if you delegate the ‑‑ use the first /64 for the point‑to‑point link. But the people didn't like that idea but there is some interesting number of people actually using this. Well, maybe I need to submit that Internet draft again.

Regarding the LAN prefix. I did similar questions for the LAN, or for the WAN or point‑to‑point link addressing. A few people is using things like a /60 and a /62, and there is a surprising response, which is sharing the /64 among different customers, which is obviously totally broken, but the point is that if we correlate the responses with the regions, I can see that mainly in LACNIC people is using, and this is from the total of 33%, a /64, which is also broken, because clearly it means the customers cannot make easily sub‑netting, they cannot, for example, have a guest SSID in their wireless network.

If we look at the RIPE and Asian regions, 35% of the people is using a /56, and regarding a /48, it's 22% of the people, and looking at the specific countries, it looks like more northern countries than more often to use a /48, which is also interesting.

The other question, again is same as for the one link is regarding the prefixes stable, and the point here, by stable I mean if the customer shut down the router even for several days, are they getting the same prefix again? So, for example, if they want to expose some services to outside, for example they want to have some IPv6 cameras and they don't want to use dynamic DNS or anything like that, they can still have the same addressing and so on.

So, basically, again, it seems that in more advanced countries in terms of IPv6 deployment and typically again that means more northern countries, especially in Europe, they are using a stable prefix, but there is a bit of difference between other regions, for example, if it's not stable.

Another question I ask in the survey is, why not allowing a stable even if it means, this means an extra cost for the service? And yes, some people is offering that as an extra cost so it makes sense in that context.

I also make questions about the IPv4 service. And actually ‑‑ let me show it in the previous slide ‑‑ actually, I got 1% of answers, the first pie that you have in the slide, so it means 1%, 14 answers, saying they only provide IPv6 service. It doesn't mean the customer is not able to have IPv4 service. This will be the example if you use map or 464 XLat that you don't have IPv4 in the one link, but the customer is still able to use IPv4 in their local network.

I also ask about which transition mechanics they are using, and I think there is a big mix in what technologies are being used, but, for example, I was surprised that map, Bot T and E are used only by one ISP each one, okay. So, yes, they are newer technologies but it seems that there is not a big support in terms of vendors for CPEs for those technologies.

It's not related to specific regions or countries. So, I don't see one technology more used in one region than another, except, for example, it seems it's being used, not too much, but a little bit more in Europe than the rest of the world.

And another observation I can do checking the surveys that I collect every ‑‑ or the evolution of the surveys I do every month, is that Carrier‑Grade NAT deployment it is still growing.

Regarding DNS, my observation basically is that DNS services like reverse delegation and others, seems to follow the responses regarding the support of a stable IPv6 prefixes, which it makes sense, if you have a stable prefix, you want to have names for your cameras and that means somebody, the ISP, need to provide those services.

I am going too fast I think, so it's good for questions.

So the final slide: In general, I think the deployment is more or less correct, but there is a lot of things that make me believe there is a lot of people doing the IPv6 deployment doing what I call the IPv4 mindset and that means they are getting probably some not very good training or the trainings are not insisting in the need to understand some differences like you don't have just a single address, you have a number of /64s for the customer network and not just the customer can take advantage of that, but also you, as an ISP, can provide new services, add value to your network by providing multiple /64.

So those are the, let's say, the takeaways from the survey, and my idea is not to close the survey. Keep getting answers and look at the evolution of what is going, for example, three months from now, six months from now, so we can see different regions are changing the way they deploy IPv6, maybe raising new questions, maybe doing a new survey, somebody suggested about what are the security features of the
[CEPE] or things like that. Thank you.

(Applause)

JAN ZORZ: I can see you better. So, this is a new setup. And this is the first test now. And let me be really, really clear, okay.

In this room, if you want to ask questions, you raise your hand. Benno and me will keep, try to keep the queue, and when we point to a person, then the person press the button. However, everybody in the room, if anyone else presses the button, he will shut down the mike from the person that is speaking.
Because people will try the buttons and then the mess would start to begin. So, please, don't press the buttons when somebody else is talking. Otherwise, we will have to ask you to state your name and surname and apologise to this person. It is rude, right? It is really rude to interrupt the person and you will do it multiple times, this is breaking the code of conduct and I'm serious, we might have to ask you to leave the room. All right. Let's be civilised please, let's make this work all together. Can you switch on the mikes, please? I see Marco with the mike.

SPEAKER: Thank you for your splendid presentation. One suggestion and one request, I'm greedy this afternoon. A suggestion: As you mentioned, it's not just the responses from certain areas are lacking. Wondering in my mind knowing that I'm part of the group in the IETF that is collecting best practices, we recently launched a survey in relation to that our US colleagues from the NTIA are putting out a request for comments to their market about IPv6 deployment. I wonder, aren't we over surveying our community about IPv6 at the moment, and could that influence your results? Which brings me to the next request. I would be grateful if you would share the results of your survey with the IETF best practices forum on IPv6 so that we can see if there's anything for us to document there in terms of best practices which is trying to document the commercial and economic drivers that lie behind the IPv6. So if anybody else has input there I'm more than welcome to take that with me.

CRISTOBAL LOPEZ: I'm actually in that.

JORDI PALET: I have been too busy to contribute up to now, but I'll make sure that we provide some consideration.

SPEAKER: Hello. Aaron Hughes, 6connect. I was going to make a different comment but first I'll just add to Marco's point because I happen to, a few weeks ago, register the name v6survey.com, more than happy to aggregate them all there and links away to various surveys if that's of interest, find me in the hallway somewhere and we can sort that out.

The comment on the presentation was going to be as someone living in the US, and I won't mention any particular service providers or vendors, there was a fairly well‑known vendor bug in a large cable provider, a large CMTS vendor for deploying static routes that just got resolved and now the, a very large well known cable provider in the US just started providing static prefixes and PTR service, so, I expect you'll see a massive change for all of the 'business customers' versus residential customers in your next round.

SPEAKER: Ruediger Volk, Deutsche Telecom. Jordi, about the question of providing stable addresses. I have been in the IETF for a long time, and my understanding is of course that stable addresses are essential for implementing the original Internet vision of end‑to‑end service and of essentially having the participants in the network being able to do all the same stuff.
However, I also notice that in some countries, civil rights advocates have been asking for confusing the addresses for privacy concerns. And as far as I remember, in some countries civil rights advocates actually have negotiated with major providers that the consumer service should have no stable addresses. And they consider this actually an important feature. I personally find this in conflict with what I see as the Internet vision. On the other hand, well, there are non‑technical concerns that we have to take into account.

JORDI PALET: I totally agree with your view, and in fact, unless I am wrong, I think Europe is the only region, or the main region in the world, where IP addresses are considered as personal data. I did work with the Article 29, if I recall it's the correct name of the European Commission, a long time ago to try to avoid this and they decided it's personal data. And I also read actually this weekend, a sentence, I think the word in English is sentence from one of the European courts saying dynamic addresses are also personal data so it don't make a difference. So, while this is something we, as a technical community, probably need to work with lawyers and the European Commission, but I think we have something really broken there. But in any case, I understand that if... because the regulation of a specific country, and I think that happens actually in Germany, mandates by default to use dynamic addresses, there is also an escape of that if you allow by a web page the customer to opt‑in to a static address and I think some providers are doing this in some countries. I'm not sure if that's Germany or Austria or other countries, but I recall having read something about that.

JAN ZORZ: Now we have time for two questions and it's Benedikt and Jim.

SPEAKER: Benedikt Stockebrand. Just one thing you want to keep in mind. The question should we give users static ordinary addresses is imminently wrong, because it suggests that there is a choice either/or. It doesn't mean we can't give people both, which, IPv6 provides addresses for and then we can actually solve the problem only nobody really wants to touch that and with the politics involved, this gets frequently lost. We can give people dynamic addresses and we can give them static addresses for different purposes, that's perfectly reasonable, but it gets caught up in the discussion.

JORDI PALET: Well... yes, and no. I mean, if you want to provide both dynamic and static addresses at the same time, that means probably some new idea of work. I don't think right now we have the tools to do that, let's say, very easily.

SPEAKER: Jim Reid. Just a couple of quick observations, Jordi. As far as data protection is concerned, it's a lot muckier than you might have presented there. And my advice is if anybody is really concerned about the data protection issues around IPv6 addresses or in fact any IP addresses is to talk to the data protection authority in your country. Working party 29 is a club for the data protection authorities to come together and discuss things. It's very, very unlikely that W P 29 will actually have a unanimous opinion about anything. And also, even if all this stuff is fundamentally underpinned by the same EU directives, how those directives are implemented in national law is down to the data protection authority and what one data protection authority says is illegal or totally impossible, another DPA in another country might say it's perfectly fine by them. You also need to look at the issues around enforcement of it. My advice is, don't take any working party 29 saying as the definitive work on this, talk to your national DPA and see what they have to say about it.

JAN ZORZ: Jordi, thank you very much.

(Applause)

Benno: Next up is a RACI presentation, and it's on how I stop worrying about ‑‑ how I learn to stop worrying and laugh at carrier‑grade networks.

PHILIPP RICHTER: This is my first RIPE meeting so thanks for having me here. Today, I talk about Carrier‑Grade NAT deployment in the Internet. You can download this on this link here.

This is joint work with a lot of people, named here.

I guess, everybody in the room here is aware of the problem of IPv4 address exhaustion so there is no need for a long introduction here. Four out of five registries exhausted the address pools and today we have less than 2% of the global router of IPv4 address space that's still free and usable.

The question is of course what happens now and how can we track what is happening now?

The obvious solution to scarcity problem will be the transition over to IPv6 and there are lots of initiatives to promote IPv6 adoption and there is also lots of measurements and statics available to see if we stand with this.

Another way is the buy IPv4 addresses from address markets and there are address brokers promoting this and also the RIRs ‑‑ transfer statistics. We can track these.

Then there is a third thing that is ISPs use IPv4 Carrier‑Grade NAT to multiply more users behind fewer public IP addresses. If you look at Carrier‑Grade NAT, we realised there are virtually no deployment statistics available, so it's really hard to understand how popular this way of combatting before exhaustion actually is. And also really little is known about CGNAT configured in the world and this will be the focus of this talk.

Now, first, given the there is so little information available, we first wanted to know what ISPs have to say about about it. We also performed a survey, I will spend two minutes talking about it. So we, asked ISPs about IPv4 scarcity and Carrier‑Grade NAT deployment. We have a questionnaire sent over mailing lists and eventually we received more than 75 replies from ISPs, from all over the world. And what was probably the most important question that we asked is, did you or do you plan to deploy v4 Carrier‑Grade NAT and here we were really surprised that 38% of our respondents told us yes, we already do deploy CGNAT for all or some our subscribers, another 12% holders, we are in early trials and we consider deployment in the near future. We found that number higher and asked some more CGNs specific questions.

We asked ISPs what the major operational concerns are when it comes to CGNAT deployment and the most commonly mentioned thing that was subscribers might experience problems with applications that don't work well behind a CGNAT. Secondly the tracing of user and the CGNAT IP addresses getting blacklisted.

We also asked ISPs what they see as major challenges when setting up and configuring Carrier‑Grade NATs. Many ISPs mentioned that trouble‑shooting connectivity issues is really a big problem here but also more generally went considering a CGN how to do the resource allocation, how to distribute IP addresses and ports to subscribers and how to set the right quotas for the subscribers. And also I want to mention that here, because I will return to it later. Three ISPs told us that their problem with CGNAT is that they've ran out of internal address space, meaning that they have used the available RC 1918 ranges already for the management network and they now need to find new ways to find internal IP addresses to assign to subscribers.

We also gave the ISPs free text comment field. I will just show some of the things that ISPs told us. We can say that most ISPs were not really fond with deploying CGNAT, as you can see in the first quote, but also many ISPs told us that IPv6 adoption seems problematic so they prefer to stick to go IPv4 and eventually deploying CGNAT.

Okay. So this survey really motivated us to go deeper and dig into this CGNAT field. So it seems to be widely deployed according to our survey and also ISPs voiced concerns about CGN configuration. At the same time, we don't have broad and systematic studies available here, so our objectives was to develop methods that allow us to detect Carrier‑Grade NAT in the Internet and also to develop methods that allows us to extract some properties of the CGNAT deployments that we identify to finally illuminate what the current status of CGNAT deployment in the Internet is.

Before I start introducing our methods, I just want to quickly introduce some terminology. Here in this figure you see how a typical scenario, like how are regular subscribers connected to the Internet. This is the public IPv4 address space. This ISP assigns a public IPv4 address for each subscriber and then, in turn, a subscriber runs a home net, a CPE net to connect its various devices. That is the typical case. We do not have a Carrier‑Grade NAT. Another ISP might want to deploy a CGNAT. We have an additional NAT box which sits in the ISP and behind that CGNAT box the ISP now hands out internal IT addresses to its subscribers and it gives us two more cases and that is the case of NAT 44 on the carrier side, which is shown in the centre here on this figure and this is the case where the devices of the subscriber are directly connected to the Carrier‑Grade NAT and this is a common scenario for [solo] networks.

We have the last case here, and, in turn, the subscriber runs another Home NAT so here we have the situation of NAT 444.

Okay. Now this is what the CGNAT deployment looks like on the white board. And I will present you now our two methods that we found to be effective to detect CGNAT presence in the Internet.

The first method that we found is what we call detecting CGNAT from the outside using BitTorrent. We call it from the outside because this with methodology we do not need any probing devices within the ASs. Let me walk you through.

You all probably know the classic BitTorrent setup, so, if you want to download a torrent, then you would connect a tracker, and a tracker holds contact information for other peers and then you can ask the tracker please give me contact information because I want to download torrent X, Y, Z, the tracker will reply to you and you can connect to these other peers and start reaching your content.

You can also do that without using a central tracker; you can do so by using the BitTorrent distribution hash table. When you use the BitTorrent DHT, then each BitTorrent node will store a list of peers that it recently interacted with, and if you want to download content you can ask these peers directly and ask them to provide you with contact information of our BitTorrent peers.

And it turns out that we can use these peers in the BitTorrent DHT as mandatory points for our study. So what did we do? We implemented a BitTorrent DHT crawler, which is a machine that continually asks across the Internet and tell us contact information of other peers that they interact with. In turn, these peers reply; for example, this peer tells us I can reach peer X Y Z and we also get the corresponding IP address and port that this peer can speak to. We have this crawler running, and after a while we have peers to tell us that they can reach other BitTorrent peers using other private addresses. For example, we have this guy that sits obviously behind a NAT and it tells us that it can reach another peer, which is also behind the same NAT and it can reach this peer using an internal IP address. So, basically, this peer leaks this internal address space. Once we realise that this is happening, we get as many as possible and we can do it efficiently so within one week of crawling we elect more than, we collect internal IP addresses, collected from more than 700,000 peers in 5,000 networks. Now, the question is, do all these 5,000 networks deploy Carrier‑Grade NAT? Of course not, because this point we know there is some form of NAT but it could be a Home NAT or it could be a Carrier‑Grade NAT.

Now, to better understand this and to also be able to dissect between small home NATs and Carrier‑Grade NATs, we have a closer look at the leakage relationships, and what we do here is, based on all the data we collect with our crawler, we form a graph. Whenever we see peer A, it leaks us the contact information for a peer B, but an internal IP address, we found two vertices in our graph, we had a leaking peer, peer A is a blue, and the private peer, the peer with the internal IP address is the small red one and then we draw an error to show, in this case, peer A leaked to peer B. Then we looked at these relationships on a larger scale; namely, we form a graph.

Let me show you what this looks like.

Now, for most ISs that we crawl this graph looks like the one you see on the left‑hand side. So we do see the BitTorrent peers that leaks the internal IP addresses and internal peers but we see that they only leak as one or two, handful of them, and also these leakage relationships are isolated. These are very likely to be related to small Home NAT deployments. We see other ASs, like the one on the right‑hand side. So in this AS, we see maybe tens or even hundreds of internal peers, if you look closer we also see intersections here meaning in this AS we see different BitTorrent with different public IP addresses leaking the same content information and than leads to the formation of huge clusters in some ASs.

That is the sketch of our BitTorrent methodology, with this methodology we can test more than 2,700 ASs in setting a very conservative threshold we detected more than 250. The benefit of this, we haven't brought coverage and we don't need probing devices.

In order for an AS to show up we need significant BitTorrent activity which is not the case for all networks, of course, and secondly, we will not see all CGNATs here. For it to pop up here, it needs to be configured in a very open way; namely, in the way the BitTorrent is located behind the CGNAT have a way to find each other to learn the internal IP addresses of each other, that is not possible in all CGNAT setups. It also gives us a limited visibility.

We complemented that with a second approach which is what call from the inside using Netalyzer. We called it this because here we have direct control over probing devices their located within the ISP. Let me quickly introduce, Netalyzer. This is a network trouble shooting suite. You can download it as an Android app or as a command line tool and when you don't load this it will run a lot of tests regarding your Internet connection and it will provide you with a detailed report on the health of your connection. At the same time, when running Netalyzer you will support our research with that because we use this data for measurement studies. And in this study, we use data from more than 550,000 sessions, and a session means that a person executed Netalyzer, and these sessions cover more than 1,500 ASs. Now, the benefit of the Netalyzer method is that, here, we have direct access to the device, router, IP address and also the public IP address and it also runs in cellular and non‑cellular networks. Of course, as we have full control over the client here, we can implement more customised test to say learn more about CGNAT behaviour.

Let me quickly sketch how we detect CGNAT with Netalyzer. We have the cellular network case, in this case defection is relatively simple because we know that the device IP address is the address directly assigned by the ISP. So we can compare this one to the IP address that we see on the server side and can reason, okay, there is a Carrier‑Grade NAT here. On residential networks the situation is more complicated because the device IP is always assigned from the home router, what we do is we query the external IP from the home router and compare it with the service side IP. It turns out that this process actually is a little more complicated because, in up to 7% of the sessions, we see that they are executed from home users that have multiple CPE devices in their home meaning that the external IP address of the first CPE device does not show anything about the device.

To sum this up: with Netalyzer, we tested another 1,500 ASs and we detected CGNAT in 194 non‑cellular and also in more than 200 cellular ASs. The benefit is clear: it gives us more control over our measurement point. This is a crowdsource dataset, so we are at the mercy of users using Netalyzer.

Having introduced our two methodologies, I will now present you some CGNAT deployment statistics.

First, how many networks do we cover? We are primarily interested in eyeball networks, we are interested in ISPs that really connect end users to the Internet and so we first wanted to have a set of eyeball networks, and, in order to get that, we rely on two data sources: the spamhaus PBL list and we consider ASs that register address blocks in that list and also we consider a data set provided that gives us an estimation of the subscriber population of ASs, so, with that, we satisfy our eyeball AS population, which is 3,000 ASs, and if you look at how many ASs we cover with our two methods, we see that our coverage is relatively good, covering more than 60% of the eyeball ASs, and now, the percentage of ASs, of eyeball ASs that we detected as CGN positive, is here at 17.1%. Now, if you compare it to our survey, it was like 38%, there might be different reasons for that, so we set conserve stiff thresholds. The really number might be somewhere between 17 and 38. Okay. So this is what an non‑cellular networks. In the cellular networks we covered more than 200 and we see that CGN is everywhere.

Okay. Now this is the network wide view. We wanted to see whether there are any regional characteristics and for that we used our AS population and we dissected it according to the RIR regions. The first blot on the left‑hand side shows you our coverage where we see that we don't have a strong regional bias but we really cover networks from all the five regions but more interesting is that in the second bar plots in the centre, we show for each region the percentage of eyeball networks that are CGNAT positive and here we see that especially the APNIC and the RIPE region, that showed the highest ratio of CGN deployment. We speculated that this is because scarcity in these regions, but I would be also curious to hear your opinion on that.

Okay. Now, our methods also allow us to study some properties of the identified CGNATs, and I will present you some of them. Both our methods allow us to study the internal address ranges that the CGNs that we identify use and what is shown here for all the instances of CGN that we detected, both for the cellular and non‑cellular case, we showed you what internal address ranges we found to be in use here. Here we see that the 10 /8 address block is still the most commonly used and that is relatively newly allocated 164 address block is not yet that popular. Also probably more interesting to see here is that more than 20% of the ASs in which we see CGNAT already use multiple internal ranges to satisfy the internal addressing demands of their subscribers and if your recall that also in this survey, three ISPs mentioned that this is an issue for them. Now, this goes as far as that we see that, for several major cellular networks, that they seem to see the need to use routable address space as internal address space behind the CGNAT deployment. In this figure here, I show you six of the most prominent cases. What we show here is, on the X axis, we show the corresponding routable address block and we draw a blue dot wherever we see using that address space block behind the CGNAT. It's important to know it's not about name‑shaming. We see this for more networks. This is the six networks we have enough data to be confident in our reasoning.

Well, the important takeaway here is that these are blocks that seem to be unused. For example if you have a closer look at the 25 /8 address block, this is currently mostly unrouted but actually we see it, it is internal use by at least four major networks, so, what will happen if somebody wants to start a routing net address block is, it's not entirely clear, so we expect that users of these major networks might have connectivity issues. So it might also be a consideration for address transfer markets, so before you buy an address block you might want to check if it's already in internal use in other networks.

That was one of the most important findings regarding the properties. We did some more tests to extract more out of the CGNATs. I want to sketch our methodology here. What we do is, when we execute by comparing internal and external IP addresses and port numbers, we can reason about how CGNATs allocate IP addresses and ports to its subscribers and for some of them we can estimate how many ports each subscriber receives. We also implemented a custom, a NAT test which uses probes to create states and NATs on the path and to expire it in some hops but to retain it in others, which gives us the possibility to pinpoint the location of NATs and also of course of CGNATs and also to extract time‑out values from NATs.

Lastly, we also implemented a stun test to compare the NAT testing which deployed this and we we can compare that to what typical CPE routers do.

That is our methodology for the sake of time I will just present you a high level overview of the results.

Use these methods we found a stunning variety of configurations and set‑ups, so we see that when comparing different ASs to each other but we also see that within the same AS, so we see that different users in that AS experience very different NAT configurations. We see that a degree of resource sharing vary heavily. The most extreme case that is we found where ISPs who assign 500, 12 ports per customer which lay allows to NAT 128 customers for IP address and we also see that NAT mapping used by deployed CGNs restrict your Internet connectivity more than what your current CPE router does, meaning that, with these tests, we see that CGNs really limit the resources available to the subscriber, and probably more important, that CGN means different things for different users, it depends on how heavily the respective IXP configures their CGNAT.

To sum this up: we brought in a systematic study on CGNAT deployment. We found more than 500 instances of CGNAT using our two detection methodologies, we found in the non‑cellular network to be about 17%, we see it's all over the place for sell remember networks. It is especially pronounced in the RIPE and APNIC region and we also identified some CGNAT issues; for example, the need of some ISPs to use even routable address space internally.

CGNAT deployment has some implication. We see it's a popular way to combat IPv4 exhaustion, so it's a consideration for ISPs to apply this technology or to not apply it. It has direct implications on IP address reputation systems and also geolocation systems. We have seen that the CGNAT directly reduces how much Internet the subscriber receives. Because we have seen the degree of resource sharing is totally different from different CGNATs. So here we wanted to raise the question, what is an acceptable degree of resource sharing? For example, having 512 ports, is that enough? We also wanted to cautiously raise the question, is there a need for more best practices on how to dimension the CGNAT or should there even be some for of regulations, for example, if an ISP deploys Carrier‑Grade NAT, should it have to tell me what resources I really receive as a subscriber of this ISP?

With that, I conclude. I am happy to take your questions.

BENNO OVEREINDER: Thank you. Any questions?

SPEAKER: My name is Philip. I would like to ask you some questions from your research. The question about time‑outs. What was the average time‑out for UDP and TCP connection in different life states, I mean about half open connection like sinwait or established connection, and so on, and how much UDP connection usually live in CGN you found?

PHILIPP RICHTER: Can you tell me where you sit? So, actually, we cannot reason directly about how many concurrent UDP connections we can see. This is not something we can do with our methodology. But we tested CGNAT UDP time‑outs. We didn't do that for TCP here and we see that for most CPE routers the UDP time‑out is 60 seconds, that he is seems to be a really dominant setting here. For CGNATs we see more variability. So we see everything down to 30 seconds for UDP. We didn't implement it yet for TCP so I cannot comment on that.

SPEAKER: I am Chris, from DDWRT. I saw in the field many many problems for CGNAT and services like Microsoft exchange because the 60‑second time‑out because exchange wants 15 minutes, and this really cracks up exchange service ifs you go over CGNAT. And I also saw and I want to know why this is happening and what maybe can be done against it, many, many problems, transferring UDP packages, so we saw sometimes lots of packet loss, even if we want to transfer 15 kilobits per second with UDP, there's some two or three providers in Germany, and so we saw lots of, even with low transfer rate, and even low packet size, you see horrible time‑outs, and do you have any information why this is happening and maybe how to clutch these people to if I can these problems?

PHILIPP RICHTER: I don't know how to solve these problems, but I would assume that the packet loss is related to the Carrier‑Grade NAT, just expiring the state, expiring the mapping in the CGNAT, that would be what I expect.

SPEAKER: Marco, RIPE NCC. I know it's a bit out of scope from your research but did you look at the correlation between IPv6 deployment and the CGNAT, how many of these CGN providers offer a way around?

PHILIPP RICHTER: This is something we asked in our survey and we see, of course it's not only IPv4 Carrier‑Grade NAT, but it is also in use as transition technology. We didn't do that in our measurements and that's mainly because BitTorrent, the BitTorrent IPv6 capabilities are really poor, so this vantage point we can't use this vantage point for that. For Netalyzer, we have some data and we are checking into this.

SPEAKER: My name is Talgat. You did very wide global research of CGN, and I am asking about, did you think about did you do some research in alternative technology for saving IPv4 addresses, its locator ID protocol?

PHILIPP RICHTER: We didn't check into that.

SPEAKER: I probably should catch you after this but I can tell you there is a lot of IPv6 capability in BitTorrent. We use it daily.

BENNO OVEREINDER: Thank you.

(Applause)


JAN ZORZ: This is a lightning talk now. It's Shane.

SHANE KERR: I work for the Bejing Internet Institute. This presentation is not given in the context of my work or anything like that. This is just some results of some discussions that we have been having and some looking that I wanted to do, what's going on with gender of people coming to RIPE meetings.

So, just before I start getting into the actual presentation, I want to give one quick slide about diversity here at the RIPE meeting. And this is just sort of a statement of principles. I think that RIPE needs to be open and inclusive, and I think in order to do that we should have a diverse set of participants.

I'm on the RIPE Programme Committee and I can tell you that, within that group, we have long had many discussions about what to do about increasing the openness and inclusiveness of the RIPE community and specifically in increasing diversity. I would also like to say that we really aren't sure what to do about this and how to address this and encourage this kind of more diverse participation.

Having said all that, this is not a talk that the RIPE PC is giving in order to do anything. This is something that I am personally doing just because I found some interesting statistics and wanted to present them. Hopefully we'll have some useful discussion.

Let's get into it.

This is just an attempt in my mind to get some actual metrics, some numbers attached to how many women come to RIPE meetings and is this different now than it was? How do we do this? We need to figure out who comes to a RIPE meeting. Luckily almost all of the RIPE meetings have a full list of attendees online, visible. There is a lot of basically minor issues there with different formats and URLs and things like that. I wrote a web‑scraping tool that went into each of the web pages and got a list, just a simple variable list of these names. And for each meeting, we got a list of first names, and that is ‑‑ the idea is, once you know someone's name, you can try to make a guess about whether they are a man or a woman.

I also got a list of countries of the attendees, starting from RIPE 29 on, that information is available, and that can give you a better guess as to what gender each person is.

So, we have our list. We can use that to make a guess. I did the normal thing. I Googled this up and there is a lot of different places which have different software to do this. There is never a perfect solution here, so my own name, Shane, can be a man's name or a woman's name. So we just have to do our best. There's no ‑‑ on the public list, there is no information about this. I was contacted later by the RIPE NCC and they have better information, which I'll probably incorporate later, because when you sign up for a meeting you can list whether you are a man or a woman.

Anyway, I ended up settling on this Cloud‑based service to try to figure out what gender people are. It's nice because it gives a probability for each name that it has. So, in the case of Shane, from the US, which is what I am, it would say there is an 85% chance that it's a male and a 15% chance that it's a female.

So what do we do with that? We collect all this data up. I used a simple formula of multiplying the gender times the probability, and I think it works okay. You know, there is other approaches that can be taken. I'm not really good at visualisation and things like that so I didn't do anything fancy. I just graphed it.

What do we see? This is the full list of attendees from every RIPE meeting ever going back to RIPE 1. And even on the far right there, that's the count as of a few hours ago. Now this graph doesn't tell you much, because the numbers change so much and things like that. And you also notice that we have got a number of unknown participants. It turns out that in a lot of cases the software just didn't know what a name meant. Also, there is a lot of crap in the data; people just put funny things in for their names and things like that. But for the most part the non‑yellow bits here is the majority. So most of the data came through.

So, let's try a better way to do that. Let's look at the actual ratios, the number of men versus number of women. So that's what this graph is over time.

And we see here that the diversity was very, very bad at RIPE 1 and has gotten better over time. And then we had quite a dip here and now it seems to be going up again and the current meeting is actually quite good right now. That's about 0.18, that means for ‑‑ a normal ratio which you would expect is one to one because there is about as many women as men in the world. And in the RIPE meetings right now we're about 0.18 women for every man. That is the number.

So what does that mean? Like I said, the data is quite fuzzy. That's okay. I think what we're looking for here is general trends and general information. Also, in this data I didn't put anything about the RIPE leadership. How many Working Group Chairs are women versus men or things like that. I didn't get any information about presenters which could also be done, all the list of agendas are online as well and I could probably do a similar kind of data search.

My own feeling is that the RIPE meeting attendees basically match the Internet industry, roughly, and probably the wider technology world programming and network operations and things like that.

I also think that that doesn't necessarily have to be that way. We can aim to be more diverse than general industry, and a good example of this is PyCon which several years ago realised that they had a problem with not having any women show up, so have taken a very proactive and direct way of trying to get more women presenters, more women on the board and things like that and they have actually taken a close look at what they call the pipeline of how people get into using the language and things like that. I think it's been very successful. You can do better than saying, well, that's how the industry is.

Anyway, in true open‑source fashion, I put all the code for this up on iGDP hub. You can click the link for the slides which are online now. You can send me a pull request if you want me to look at your conference and your meeting. We can try to do that. Anyway, that's it.

(Applause)

JAN ZORZ: I will stand up here to see you better. Jan...

JEN LINKOVA: Two questions. Is this just coincidence that we see in this lightning talk just after two talks about IPv6 deployment you imply that getting women here is almost as hard as getting IPv6 deployed, right?
I have a question: Have you tried to correlate your data with T‑shirt distribution data?

SHANE KERR: No, that's a good point. All data is welcome and we love it all. So...

SPEAKER: Thank you. It was heartening to hear that ‑‑ Malcolm, I walked in off the street. It was heartening to hear that the gender distribution matched the industry. That implies to me that the community is open and inclusive to the broader community that it seeks to serve. I am interested in unpacking your assumptions behind being better than the industry. What are the reasons why you think that RIPE meetings should seek not to match the industry that it seeks to serve?

SHANE KERR: I think that we should, as a civilisation, as a planet, try to give women more positions of responsibility, and take advantage of half of the brain‑power on the planet. So basically, I am a feminist, and I think that ‑‑

SPEAKER: Give a definition of feminism.

SHANE KERR: Sure, I will label myself a feminist.

SPEAKER: So will I.

SHANE KERR: Sure. So ‑‑ and I think we need to figure out how to move in that direction, and rather than saying, well, you know, the industry, what can we do? There's a pipeline and we can only take what we get? I don't think we have to accept that. I think we can try to make it more welcoming in any way that we can, and I think, also, we'll get a better meeting if we have more women than the industry on average, because we'll get more brains working on problems and showing us what they are thinking about, so... that's my personal take on it.

JAN ZORZ: Now we have two last questions, and it's Leslie and Filiz.

SPEAKER: Leslie Carr, Clover Hill. Two comments: One, is that all research has shown that when there is more diversity in a group they tend to have better outcomes and better results. And number two is, I am a woman, and in order to feel more welcome in an industry or a meeting, I need to see other people like me as examples in leadership, and, without that, I would not feel comfortable, I want to make sure that everyone feels comfortable being here.

SPEAKER: Filiz. Thank you, Shane, and despite all the laughter and everything, this is a serious issue. And I really thank you you for raising this up. We are an intelligent bunch, I would like to think, so we should be also ahead of our times. We are often ahead of our times, we are proud to be engineers, technical and everything, so, yeah, why wouldn't we use 50% of the brain power? That would be just smart. So, why this is a lightning talk? I think we need to all think about this more seriously, and think where we can improve things. Things are not that, maybe, prominent at times. Things can be subtle. I very much encourage all my colleagues, female or male, talk to those who would like to talk about this, and let's open our minds. This is really not a joke. This is important for us.

SHANE KERR: Hear, hear.

BENNO OVEREINDER: I have to wrap up this discussion. Marco... sorry, indeed, as Filiz just mentioned, this discussion doesn't stop now. Just before the break. Please, for the next week, or the rest of the week, contact other participants, talk with Shane or me or anyone else in a PC, because we want to continue this discussion and we want to come back on this topic, on diversity at the next RIPE meeting. So, please continue the discussion with us and with each other.

Are there any other things...

JAN ZORZ: Now it's a coffee break, next Plenary will be full of good topic and then just at 7 we meet here for the BCOP Task Force, if you are interested in that doing that we see you here at 7 p.m..

Benno: One final note. Well, I was ‑‑ people ‑‑ I was not very clear about the date of the end of the nomination of PC candidates. It's Tuesday, tomorrow, at 4:30

(Applause)

LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.