IoT Working Group
Wednesday, 18 May 2022
At 9 a.m.:
CONSTANZE DIETRICH: Hi, everyone. It's so good to see you all physically, I basically cannot believe it. Welcome to the IoT Working Group session so if you thought you are at the Address Policy Working Group session, you are wrong, please leave the rhyme now and go to the side room.
Yeah, we have a couple of talks today. Let's see what we got. Hans Petter just said the battery is not included. There we go. Obviously introduction and housekeeping first, and then we have a talk from Leandro Lanzieri, it was from about securing authorised client to client Thorisation. We have Tommy Haga talking about IoT encounters in healthcare networks, he works for the western part of healthcare in Norway. Then we have a discussion to be started, he is going to tell you more about that later. And then we have the co‑chair announcement as I for now am stepping down due too to, you know, time issues.
Okay. Next slide, please.
Housekeeping. We, yeah, tried to get feedback on the Working Group minutes made by Carla Liddle White last time, there were no objections of any sorts so we would like to have those minutes upgraded to final state. Next slide, please.
Right. Now to participate: So I am not going too much into detail here, just because it's the third day; however, it's also the first Working Group session at this RIPE meeting, first one hybrid, so please, if you have any questions or remarks, use the Meetecho queue to queue up, even if you are here. However, I think we can also deal with sudden approaches and sudden hey Hi, I want to say something. We also have a Q&A, if you want to talk or be seen, you can just put in your question and we will read it out loud. We have stenography, which is available at Meetecho, we have a chat, and you can also see who is currently online in Meetecho.
I think that is it for now. Next slide, please, just to check. Next slide. Thanks. Yeah, so this is it for now. And now, I would like Leandro Lanzieri on the stage for the first talk.
LEANDRO LANZIERI: Hello, everyone. I am going to talk today the work we did developing secure and authorised communication, client to client communication for machine to machine, this was joint work with Peter, Thomas and Matthias. So with the increasing development and deployment of IoT devices, many vendors come up with their own solutions which in many cases are not compatible with one another and then devices actually remain in the so‑called incompatibility see lows because they can't communicate and not compatible between each other.
Add to that, as any exposed device on the network, they have to fulfil some security requirements but these mechanisms that they utilise should be lightweight because they IoT devices are most of the times running on constrained devices. You should limited memory, limited processing power, they are running on some tight energy budget, maybe on batteries or energy harvesting systems and usually the network activity is wireless, is glossy and the data packets they can send are really small.
Add to that, as IoT serving a lot of different scenarios and use cases, including distributed obligation logic which means devices should make decisions and add directly Lyon the edge and not go directly in the Cloud. We can see this in industrial close systems where they need low latency times or households where we don't want to talk to Cloud all the time because of privacy issues. This happens when we have remote or mobile deployments where connectivity is intermittent or very expensive.
So, to tackle many of these challenges, there is IoT management protocol called lightweight machine to machine, it so was many of these issues, we are going to see an overview of the protocol but it comes short when we are talking about edge collaboration because it proposes a server centric topology so this is the starting point for our work. We propose, design, implement, you can test it, some extensions to this protocol to actually allow clients to talk with one another and that's the leverage, the existing features of LwM2M without compromising the whole set‑up.
So, let's take an overview of the protocol. The protocol stack looks like this, M to M stands on the application protocols like KOAP or http, the traditional one is on top of CO AP so allow they allow multiple security security options. For our work, we folks on this stack, using DT LS and OS score for security and for transport layer.
The protocol allows or provides between different vendors by defining well‑known interaction model and resource model, that means vendors know how to expose their resources and they also provide features like device boot strapping, few more updates and access control policies.
Not working. If it doesn't work, I can also share from here. So they defined two entity types, mainly the M 2 M client which are running on the IoT devices, air conditioning and for instance temperature sensor and allow LwM2M servers usually running on the Cloud. It's running on the Cloud and to the clients always through servers, the servers need to establish secure communication and require access rights and credentials to talk with the clients, in this example here we see this triangular interaction where you have a sensor, notification that goes all the way up to the server to application and down again to other device. So we can see that this server centric communication prevents edge collaboration because we have to go to the client, it doesn't allow client to client communication.
As I was mentioning, the model they provide to expose information so all the operating information from the clients is exposed as resources and these are grouped in objects. Each of the objects have access rights and these servers can perform operations on the objects, they can make operations like read, write, execute, create, and they access control policies, manage which server can do which operations and which resources.
So, our, as I said, our extensions allow the client to client communication whilst allowing deployment. We see a diagram, we see the same connection but if we allowed a direct communication between both clients we can keep the communication locally which reuses latency and increases the bandwidth because we don't have gone to the server and back to the local network. In this kind of topology the servers remain surf monitors and management for the clients but don't ‑‑ are not involved in the every day operations or the logic so we can move the application logic down to the edge. To achieve this, we propose in our work a couple of new LwM2M objects which would hold the needed credentials and access rights for the clients and we extended the existing interfaces that allow LwM2M that allows client to client interaction. This is the first contribution of our work.
The second contribution is involving this third party authorisisation mechanism that allows for more deployment, the idea is that LwM2M client can dynamically request from servers access rights and credentials to operate on other clients so we don't have to hard code all this information on boot, they can just do it dynamically if they heed to access. This is a second contribution. And we are going to see a sequence diagram of this. The client 1, once you connect to the light switch and observe this resource, get notification when than changes, it doesn't have any credentials or access rights to do so‑so it makes an unauthorised operation on some resource, it gets rejected but hints that indicate client 1 were to go and fetch the required credentials and access rights for this resource. When client one goes and does that if the server accepts the request it goes ahead and installs access rights and credentials on both clients. Using DTLS they will make a handshake over and over the secured channel they can make operations between the resources of both clients. We implemented all these extensions and validated on‑off the shelf hardware. We used the following experimental set‑up so we had to allow M2M clients that were connected with one another. They were part of a multi hop topology with a number of intervening nodes and gateway and we had Cloud running M2M server using a modified version of legend, and the nodes were running the right operating system with allow M2M engine. All these was running the F IT IoT test‑bed which uses nodes we can use to perform these measurements. The hardware on the nodes is this IoT which has a core text micro controller and a 15.4, 2.4 gigahertz transceiver. To see the impact of our extensions we take as a baseline the models are related to the basic clients so no extensions at all and this is the share of the models in the full image, we thought counting like the OS and network stack. We see that when we include the client to client features we see an increment in both flush and RAM and when we add to that the authorisation, there is a slide increment in flash but there is no RAM extra requirements. From this we observed our extensions, the client to client extensions require 3.5% ‑‑ requests only 5% extra R OM because of extra code needed to handle this mechanism.
We perform some measurements notification arrival. In this scenario we had two clients and one send notifications to the other one, in one scenario through the server and back and in the other directly. This is the server centric one with only one HOP and we can see that there is a minimum band of around 80 milliseconds of delay of going back and forth on the network. As we increase the number of intervening hops in the local set‑up we see that the delay increases, but when we send notifications directly as expected this is much faster, this is in the order of 10 milliseconds. When we zoom in, we can see that when we are using oscore security slightly faster than using DTLS. We can conclude that the client to client communication as expected reduces notification arrival and that's by around 90%.
We then run all these experiments on random topologies, it wasn't the set‑up I showed before, we randomise the nodes and the position, the physical position on the test‑bed, the number of hops intervening between the gateway and both nodes and we got the same result so a huge improvement compared to server centric topology.
We then performed timing measurements on the third party authorisation mechanism so how long it takes for a node from the moment it requests a credential until the whole process is done, we can see that for 50% of the times when we are using DTLS the whole process ends before one second, we can also see this staircase kind of shape on the timings and that's due to the transmissions that are happening because of lost packets.
From this we can see also the oscore time is slightly hire allows extra item to be distributed when we are distributing compared to DTLS.
Once the credentials and access rights are distributed we can go ahead and perform the first client to client operation. If we zoom into that, we can see that oscore is in line with the times that we see before but DTLS can go up to 160 milliseconds and that's mainly because of the handshake that has to be done in the beginning of the connection, but afterwards it goes back to the same times as before.
Then we started sending fixed size notifications and increased the frequency of the notifications between both clients, we can see for both DTLS and Oscore when using client to client communication the delivery rate is almost 100 percent and the good put is almost optimal and starts slightly degrading here when it arrives at 10 milliseconds which is at line we saw about the previous measurements about the time at that takes to deliver notifications. Of we we do same thing with server centric we see this starts degrading at 100 millisecond and we can pass this 50 bytes per second good put here of payload. We can conclude that the good put of the client to client is 8 times higher than the server centric topology.
Finally we also performed some energy measurements while we were doing the experiment. We can see the main increase here in the energy consumption throughout the experiment is the highly dependent on the number of intervening hops we have on the set‑up, when we have the client to client it's in line with the server centric one so we don't have any difference but that means we don't have any extra overhead for this new feature but as we are reducing the number of intervening hops because we don't have to go all the way up in multi hop topology and talk between the clients, we reduce the amount of energy spent by the host system.
So, to summarise a bit, we contributed this third party authentication mechanism, we extended the existing to allow M2M to allow client to client communication. And we performed on real hardware and all our implementations are Open Source and available for everyone who wants to use them, take a look, or even improve them hopefully. Our results, they showed the client to client communication reduces the notification arrival by around 90% and yields eight times higher throughput while still having a low impact on the memory footprint. In feature work we would like to analyse how we can apply the ASO security framework M to M and explore the integration of group Oscore will improve on the same recourse Oscore running on the client. Thank you. And so here is where you can find actually all the code and implementations if you want to take a look in GitHub.
(Applause)
SANDOCHE BALAKRICHENAN: Thank you. So, we have time. Do we have questions for Leandro Lanzieri? You can either do it via, you can come to the mic, but there's no mic, I can give you the mic. So, questions?
DANIEL KARRENBERG: I am with the RIPE NCC. My question is to the methodology you use to determine your energy consumption, how did you do that.
LEANDRO LANZIERI: The test‑bed ace louse you to measure the amount of energy per node so it has a sensor and we log and measure the amount of energy that each node was using.
DANIEL KARRENBERG: So that was a real measurement
LEANDRO LANZIERI: Sure, of course, yeah.
DANIEL KARRENBERG: Thank you.
SANDOCHE BALAKRICHENAN: Can I ask one. So you said one of your contributions was authorisation mechanism for the clients. So is it ‑‑ how did you do the key management, is it symmetric or asymmetric?
LEANDRO LANZIERI: That's not part of the mechanism because it's defined by M2M, you can use both so our mechanism is actually independent that have because we still handle everything at the level of LwM2M objects, when the server has to install the new credentials installs on the devices and the way that the credentials are stored is already defined by the protocol so we use that part and there is no new implementation needed, actual.
SANDOCHE BALAKRICHENAN: I don't see any questions, so you are on time, thank you.
LEANDRO LANZIERI: Thank you.
(Applause)
SANDOCHE BALAKRICHENAN: Tommy. The next presentation is from Tommy on IoT encounters in healthcare networks.
TOMMY HAGA: Hello, I work with else vest and as a network engineer, I am going to talk about my experiences with IoT encounters over the years while working there and how to ‑‑ how we have been handling those devices.
Here we go again. Very shortly about my employer, the IT department of all the public hospitals in western Norway, we are organised as a separate unit besides the hospitals which again are organised under health trusts, and we have about 45 hospitals in the public sector and we also have services delivery for some private in the market as well. Exactly about ‑‑ about 680 employees, but mainly across those four cities but also other places, specially since Covid everybody is working from home in their cabin or other places. We have about 60,000 active active end points today and the IoT segment is the fastest growing, but all new buildings and projects and stuff tend to have a lot more sensors than they did when I started 20 years ago. (.
A little bit about the environment computer computer network. It's built pretty much standard, if you takeaway all the redundancy and health specific parts, pretty much like any other enterprise networking. We do some extra encryption and also switchboard authentication and authentication in general and we have in‑house data centres because of privacy laws and policy statements, that's a statement they did. Also as previously mentioned in the last session also a little bit, one of the reasons we also have in‑house data centres is because a lot of the systems both medical and IoT related are incredibly latency sensitive and some of the systems can't tunnel any higher than 10 milliseconds RTT and, yeah. So that's just a bit about the physical region that we are operating in. It's pretty stretched out region, it takes about eleven hours with car from driving northside, access from one side to the other but it's a beautiful drive so I recommend people do that if they ever find themselves in Norway. And there's plenty of hospitals all the way along the way.
A little bit about me. Like I mentioned, I work as a computer network engineer and I am part ‑‑ I am not doing this alone, I am part of a team of 25 wonderful people and and I have been ‑‑ I started working in this region for the hospitals about 20 years ago, but even though I had pretty much the same office space the whole time, I still had three different employers because the government kept organising the healthcare sector all the time, and also every time this happened, also responsibilities grew because when I first started I worked for the provincial department and one hospital, and then a few re‑organisations later things grew and the reason I mention that is because every time we got new devices or network equipment into our network we also got new clients and new IoT devices which nobody knew about previously. So we ended up with a lot of devices, it's connected, we don't disconnect it in case somebody starts screaming down the whole way.
So, when I was approached and wanted to hear about my experiences about this, my first question back to her, what is the definition here of IoT because it's quite widely interpreted and also if you are really sticking to the I, Internet of things, this would probably be a lightning talk and not a longer session, we went into a little bit into the discussion, that she had an IoT survey a year ago where people had to give their definitions of IoT and it was pretty broadly ‑‑ broad range of answers so I went with, after a bit of discussing with Constanze we went with that it's IP connected device made to fulfil a specific task or purpose, like camera, lab equipment, ultrasound machines, etc. You can sort of least the way I can see, it I can mean intranet of things.
So why do we use IoT or do other people use IoT? And that's usually to simplify things. So when we connect something that used to be not connected to the network the usually to gain some sort of benefit in terms of making these more easy, scaleable, automated etc. So one of the examples I have is emergency lighting which isn't necessarily a hospital‑specific issue; many building codes demand that you have these kind of solutions. So before you could ‑‑ before you connect the things to the network these things, emergency lightings have to be inspected manually to see if dead defective battery or light bulbs or other things but get an instant notification of components in need of repair or change out you get a whole new way of reacting to things and generally just making it easier and cheaper. Another thing that's more hospital‑specific is temperature logging, so hospitals have a lot of volatile biological products usually stored in various coolers at various temperatures and they also have to make sure that the temperature is consistent and always there, so pre‑networking, so to say, you would almost have to inspect either the read out on cooler manually or noting the temperature in display and running it down, almost. But yeah, one of the things I have probably worked with most within is all sorts of adapters before connector these temperature measurement devices to the network and exporting that data to the relevant systems. And that has definitely made things more scaleable but also more safe because as soon as you know there's a discrepancy in temperature in a cooler or something you can react to it and you don't risk contaminating samples or destroying something valuable and not knowing about it until much later.
Still IoT is at least when I worked with ‑‑ over the years, it has also a tendency to not work as well as other devices like computers and stuff you plug into the network. That can be many causes of, because the people who buy the devices that are being connected to the network, people who buy and maintain these and operate these devices, they don't really have much knowledge about anything, other than the core function of the device like for example logging temperature and making sure all their products are safe and then the vendor will just tell them you can get this remotely monitored and you plug the cable into the network and it's supposed to work fine and if it doesn't, then blame the local IT department. And also the vendors sometimes have also been very focused on research and development purely on the core function of the device and the network hardware they tend to put into the devices, yeah. Not ‑‑ it's gotten better in the last years but also it has been tending to be of a really old design or something, 10 megabit of duplex or doesn't authority the authentication policies and get this whole sort of stuff you have to deal with and making the devices harder to connect and comply with our security policies.
So, yeah, going back to the ‑‑ are we creating more problems than we solve? And that depends really on how well you manage the extra issues that pop up with these IoT devices, because the first couple of years where I was working at this in the healthcare, I spent a lot of time just reacting to various incidents with IoT devices and whether it was problems with static addresses or devices hijacking IP addresses or flooding the local LAN with the broken packets or something, so you have to do all these sorts of things like do custom config settings all across your network on different ports, you do that one time and that's fine and it's not a problem, but when we have done it 2, 300 times or something, stop to get a technical cost or scalability issue and you have to maintain all this and know what every configuration change is for, etc. We started ‑‑ when we got to that point we started to think a bit different in terms of, we have to start making some demands in terms of when this equipment gets bought, that people have a set of rules to follow, and that is something we do have today and also we have internal document that specifies certain demands in terms of what the clients or the IoT devices or any end device has to support when they do connect to the network but that list didn't happen overnight, it happened gradually, so we sort of like had certain IoT devices that created a couple of these requirements I will go into a couple of them, just to get the lay of it.
So, in 2009, we had a Conficker or malware outbreak in the hospital network and most other public government entities were affected as well in the same region. The virus itself, it was very ‑‑ it was somewhat contained so we managed to make sure it didn't access the Internet and downloads updates to it so it sort of sat around the network trying to infect more and more computers and, yeah, by digging out user information and doing like dictionary attacks on those user accounts. And, yeah, that also of course affected a lot of the IoT devices that random sort of Windows embedded version or something, for some reason those have been really popular in some devices. So, yeah, this one case we had was a freezer that went embedded and just had, just for the touch panel and so you can interact with it and read of temperature and stuff, but after it got infected it used pretty much all of its CPU to try and infect other computers again and just the whole thing just froze and you couldn't do much about it. So, to prevent it from infecting any more computers, first we put on access list that just dropped all the traffic but then we got told by the pathology department that they needed access to the temperature logging still. So, and also the vendor refused to install security patches so that was a problem. So we just opened a small hole to make sure the temperature logging still worked and went it wasn't seeing any more computers because of the access list and it was still usable again but the device has ‑‑ it sort of sat there infected for the rest of its lifespan.
Uniform dispensers. These are really neat machines, I think. The cleaning staff come in the morning, pull the cards and they get their uniforms and they are off to work. This one was also a bit infected in the same Conficker outbreak, we had just with vendor refusing installation of security patches because it would break the system but this one had a slightly different technical solution because there were 40ish of these machines and integrated with servers and such and had to dump all the machines there and the vendor actually came with patches like a year later or something and, again, the machines have since then been replaced with other machines.
Unique X‑ray machines. So, yeah, you go to the dentist and get your picture taken of your teeth and then your dentist is suddenly swearing in the back of the office because the particular picture is not coming up on his computer. That was the case for a long while with these first devices that we were using in dentists' clinics in Norway. These were like really early, like first, second generation or something, so, yeah, you have the imaging unit, it shoots the X‑rays into the sensor which is placed inside your mouth and goes into the box to get sent across the network to the relevant systems. That box in its first generations had each time we got a new batch of boxes they had different speed duplex settings, we had to send a technician out to the site and had to change the settings on the switchboard until they said it worked, fine enough. And that's ‑‑ that can be quite resource draining when you are telling someone to drive two hours into the wilderness to some local dentist's office to test the device.
Classy lab instrument. This is also recurring thing. So, yeah, you have this really critical devices used to analyse all sorts of samples and they don't support any sort of like masking, if you put in our address space which is a /16 be classed and that's what it wants to use. So and this was not a problem in the times when the server was standing right under the desk but when it get moved into the data centres, suddenly it was a problem. We managed to fix that one particular with something called proxy arp where the router was pretending to be ‑‑ answering on behalf of the server those devices support classless addressing, it's amazing you have to put something like that into a requirements document but that's what we have to be dealing with. Some of the vendors just hide be behind a firewall or path or something and that's also fine enough.
Chicken and egg utilities. So a lot of controls are also based on really old like circuit boards and network cards and so on. So this one was ‑‑ became a problem when we started port authentication on our networks because it would only reply to aspects sent to a specific IP address but when you turn it on it doesn't send on a packet, we can't authenticate it on, you get a whole logical loop and/or chicken and egg situation, it won't get authenticated because it's not showing any Mac address and it's not in right VLAN. So, that made us also for support for devices that either ‑‑ so you can solve it two ways, either they do support authentication or at least DHCP support because you will send these requests and at least get Mac address react on.
Not everything has been, like, bad IoT. A lot of devices have been able to make systems that work really well. So especially payment terminals, I don't think I have ever had problems, you plug them in and support all addressing and goes to the Internet and ‑‑ or to the payment servers and everything is fine.
So, going a little bit back to the previous slides, are we creating more problems than we solve with all these devices that do strange things in the network? I would still say the answer is no; I mean, like I explained, the benefits of having something that you had to do manually and you don't get instant monitoring notification and you suddenly have that, the benefits are enormous. So we just had to address the most of the issues regarding why IoT is having problems and, for example, that the folks has to be end‑to‑end and not just on device's core function, that the operator is somewhat aware of the requirements but that's also an organisational issue so you have to make sure that the organisation responsible for purchasing this also connects both the speciality fields like an electrician via UPS systems and also the IT department so they can state network requirements to vendors. You also have to account for standard life cycles, a lot of devices live very long, I talked to medical technician last week who said ultrasound machine can have a lifespan of 20 years and in IT world that's going from T4 to a Mustang. Have law or standard mandated measures. That's a tricky one because laws are ‑‑ there is a slide missing here? Laws are tricky because they, especially with technology, because they tend to be become too specific or outdated. Standard mandated measures, yeah, so we have the internal document now which was going to be on the next slide but it's missing for some reason, it's probably my fault. And we also have law that was passed last year in Norway regarding mandatory IP version 6 support and I am a bit over my time now. I will leave it at that.
SANDOCHE BALAKRICHENAN: Thank you, Tommy.
(Applause)
SANDOCHE BALAKRICHENAN: So we can have one quick question for Tommy.
NIALL O'REILLY: Embedded device wearer. I noticed that there is a separation between the kind of devices you were talking about and the ones that Leandro Lanzieri was talking about and I was wondering if you are yet beginning to see the appearance of that class of device in your networks?
TOMMY HAGA: Yes, a little bit. So that comes from two different paths, both we have internal ‑‑ we have internal development team now that's working with like Open Source sensors that are writing different packages and putting them into certain environments and the other one as we are now starting to put specific requirements towards the vendors they are starting to use more modern equipment as well but it seems if you are not putting forward any requirements they will definitely not update their hardware.
SANDOCHE BALAKRICHENAN: Thank you. So normally we have NCC IoT update, usually Marco used to do that and Marco has left RIPE. So thanks, Marco and we have and thanks Jad for accepting to give you a brief overview and bring some questions to the community.
JAD EL CHAM: Thank you, good morning everyone. I realise I am standing between you and the first break of the day. Plot twist, I am not hear to give you any update, I am here to ask you a question, well four, in reality:
So I will just jump into it. So my name is Jad El Cham and work for the L and D department at the RIPE NCC for the last five years and my main question for you today: Do you see any added value in the NCC providing training material or training courses covering IoT topics? If so, through which format? So we deliver face‑to‑face training courses across our service region, we do custom made workshops for the stakeholders, the governments, the regulators the ISPs, webinars, these one off open houses online events and if we divide to go through it, which topics or aspects in IoT should we cover? Hardware, software, OS, data, visualisation, data processing, data publishing, security? We always hear about securities here and there. And the last and final question, which is most important for me: Who is willing to help? And that's it for me. I'm really interested in getting your feedback on this.
SANDOCHE BALAKRICHENAN: So do we have any feedback for Jad?
JAD EL CHAM: Your answer can also be no and you will make our life way easier.
JIM REID: Private citizen. Short answer: No. I think we have very careful here that the NCC shouldn't get more and more involved in mission creep and I particularly think it's important that the operation of any training services should be constrained to NCC's services only. They shouldn't try to dabble in other market conditions such as offer training in DNS or on IoT or whatever. These things can be perfectly addressed in the market and if the NCC was to engage this those activities it would distort those kind of things and potentially cause other problems for the NCC further down the line because you are acting in a sense like an monopoly organisation to subsidise non‑core activities and I think that's a very bad thing to do.
JAD EL CHAM: All right, thank you.
SANDOCHE BALAKRICHENAN: Any other feedback or you can also respond via the mailing list? Thank you, Jad.
JAD EL CHAM: All right, thank you.
SPEAKER: It's really good that you are trying to do more about what I was going add; people don't necessarily like to say no, but can we have a show of hands‑on who does not want the NCC to get involved in IoT training. Just to get an image of a number. We kind of need to at some point, he is asking a question, he wants to know. Now who wants training? Three, okay, three, not bad. Four. So, generally speaking, no. Sorry, guys. It's not about ‑‑ monopoly is definitely something but it's more a case of with everything that's changing in the world, if one organisation who already has access to so many different potential providers, it's the one providing the training, it's your way of things that becomes the way of things rather than the best way of things, which will find its way, and all the problems that we are facing, we are discussing them and things evolve from here. Plus, you do have subsidised employment, you should not be doing these things, it's ‑‑ it's out of scope, it brings in new people doing new things, new management structures, you don't folks on your core activities because you are focused on other things. We both come from a region that could use a lot more training and I'm still saying no, so ‑‑
JAD EL CHAM: The NCC, we are not working on such trainings, we just evaluate feedback from the community and you know when we do our training courses, we ask for surveys and feed backs and on what topics would you like us to discuss? We always have securities, we sometimes have these five G, these kind of technologies but also IoT is on the table. And it's not new, you know, it's been for a few years. But we did have, like, a good collaboration with the Anti‑Abuse Working Group where we are actively discussing with them ways of developer training material so I thought I would also ask for your opinion if the community is interested in it, and, again, no is a valid answer.
SANDOCHE BALAKRICHENAN: Thanks, Jad, I think we will discuss it on the mailing list.
JAD EL CHAM: Thank you.
SANDOCHE BALAKRICHENAN: Now we will go to the co‑chair announcement.
CONSTANZE DIETRICH: So, we have a new co‑chair starting basically from now, who is it going to be? We had fortunately NAT one person who stepped tried and he has tried for the third time now and it's fourth time now, and I think he is going to do a very, very good job, and it's going to be Peter Steinhauser.
(Applause)
And we had a short chat yesterday during the social, I think one of the first tasks you should get involved to, involved in would be to get a different slot for the IoT Working Group session at the RIPE meetings because 9:00 in the morning, it's just not working. Okay. I think you also have a few words to say, if I'm not entirely wrong. And we also have two minutes, right.
SANDOCHE BALAKRICHENAN: Before giving to Daniel, I would like to thank Constanze because...
(Applause)
SANDOCHE BALAKRICHENAN: So it was a very pleasant working with Constanze and I think the IoT Working Group will miss her. Thank you, Constanze.
CONSTANZE DIETRICH: Thank you. I am not entirely gone, right; it's just the hat is now on Peter's head.
SANDOCHE BALAKRICHENAN: I would like Peter to give ‑‑
PETER STEINHAUSER: Thank you very much and spell Constanze, thank you so much for your work for the Working Group, real great, we had amazing conversations. I don't want to talk too much. I would love to have have this Working Group getting a little bit more folks, I mean IoT is a huge field, he have many, many topics we could discuss and I would like to get this a little bit more in the folks of the core field RIPE is working at and also seeking out connection with other Working Groups and topics and especially getting a little bit more activity in the Working Group, that would be great. And I ‑‑ the last thing I wanted to do is also thanking all the people who were supporting my running for co‑chair, I hope you will not get disappointed. So thank you so much.
(Applause)
SANDOCHE BALAKRICHENAN: Thank you,Peter, and I think we are on time. If there are ‑‑ there are two more minutes if you have anything else to talk ‑‑ give feedback, ask questions.
DANIEL KARRENBERG: I am an IoT user for this purpose. Giving feedback to what Peter just said about the folks for the Working Group, in the days when we started this Working Group, I remember somewhat that we saw this IoT thing coming at the ISPs, basically saying, hey, that's going to be millions of devices, how is it going to affect the traditional ISPs? And I think that should be a folks that you might want to regain, just feedback from me personally.
SANDOCHE BALAKRICHENAN: Just to respond to that. We did a BCOP and Peter was also involved, I think we will do a second round of that in the coming days. We would not like to stop between the break, so it's 10:00, thank you for joining.
