- iot-wg - mailman.ripe.net

re-rebooting the co-chair appointment process
by Jim Reid 26 Feb '19

26 Feb '19

Colleagues, we're still missing a co-chair. The last attempt to find one didn't work out. Although a couple of names were mentioned, there were very few voices of support for any of them - certainly not enough to make a sound consensus decision. It's time for one more heave. I suggest a call for nominations/volunteers/stuckees which ends on April 5th. That gives us 6 weeks for potential co-chairs to be identified and hopefully someone to emerge as the new co-chair. If the results by then are still inconclusive, I'll talk to Hans-Petter about how best to invoke article 5 of our appointment process. Let's hope it doesn't come to that. Please limit your comments on this thread to the proposed time-line and how to solve the problem of lack of WG consensus if this happens this time. I'll post another article for would be co-chairs.

1 0

Proposed Updates to EU RED Directive to increase IoT security
by Marco Hogewoning 14 Feb '19

14 Feb '19

Dear Colleagues, As I mentioned in my presentation to the Working Group during RIPE 77, the European Commission is thinking about updating the Radio Equipment Directive with the aim of improving IoT security. As a quick refresher, the RED applies to all equipment that has a radio on board. The legislation has a few broadly-defined terms regarding security and safety, which can be filled in on a later date. Last year, a number of member states floated the idea of using this option to increase security for a number of IoT devices, mostly toys and 'smart wearables’, for e.g. smart watches and step-counters. The European Commission has now opened a four week ‘feedback’ period on what is called an ‘Inception Impact Assessment’. This means the process is at an early stage and not very specific, and they are seeking feedback from stakeholders on their thoughts so far. As expected, the proposal currently does indeed target toys and wearables. Of course, this could change or be expanded later. Here are the key questions in the Inception document: - The overall objective of this initiative is to ensure an adequate level of security for internet-connected radio equipment and wearable radio equipment at the moment of placing on the market. - The following policy options and their effects for potentially affected parties (e.g. manufacturers, consumers, National Authorities) will be analysed: - Option 0, baseline scenario: a situation in which manufacturers are not obliged to implement any specific measures as it is currently the case. - Option 1, a situation whereby the industry self-regulates to implement the existing legislation which protects personal data, the confidentiality of telecommunications, security and protection against fraud. - Option 2, adoption of a delegated act pursuant Article 3(3)(e). This will require that radio equipment incorporate safeguards to ensure that the personal data and privacy of the user and of the subscriber are protected, also as a tool to enhance the cybersecurity of these products, and this requirement will have to be demonstrated for the purposes of market access. - Option 3, adoption of a delegated act pursuant Article 3(3)(f). This will require that radio equipment incorporates certain features ensuring protection from fraud, also as a tool to enhance the cybersecurity of these products, and this requirement will have to be demonstrated for the purposes of market access. - Option 4, adoption of a delegated act pursuant both Articles 3(3)(e) and (f). In this case, both requirements in Options 2 and 3 will have to be demonstrated for the purposes of market access. More information about the process and the Inception Impact Assessment is available from https://ec.europa.eu/info/law/better-regulation/initiatives/ares-2018-64269… The deadline to submit feedback is Monday, 4 March 2019. This is the very early stage of the development. If a more formal proposal is drafted based on one of these policy options, there will be another 12-week consultation period. At the same time, please be aware that this process could result in a so-called ‘Delegated Act’, which does not require the formal approval of the European Parliament or Council and can come into effect very quickly. Regards, Marco Hogewoning Senior External Relations Officer RIPE NCC ------------------ Summary ------------------ RED security Inception Impact Assessment Feedback period: 4 weeks ending on 4 March 2019 Possibly followed by a 12 week consultation period

3 3

algorithm agility for IoT
by Jim Reid 24 Jan '19

24 Jan '19

I’m working on a document at ITU Study Group 20 on algorithm agility. [So you don’t have to! :-)] The aim is to produce a Recommendation which essentially says “don’t hard-wire crypto algorithms into IoT stuff because what’s secure today could be insecure tomorrow”. For instance, building or deploying an IoT solution that can’t use anything but MD5 or DES (say) would be bad. Similarly, it would be undesirable to install a sensor network today that can’t handle tomorrow's devices because they might well use new crypto which isn’t around today. At the moment, the document cites the mechanisms used in TLS and DNSSEC as frameworks that those deploying and designing IoT infrastructure should consider. ie Continuously updated registries which add new algorithms when these become available and drop old ones which are considered unsafe or whatever. Please note that the document isn’t going to say everyone *must* use TLS and/or DNSSEC since that clearly depends on specific (unique?) use cases and requirements. Instead the document will say that people should take account of those sorts of frameworks when they are designing, procuring or operating IoT infrastructure. SG20 has said the document needs more examples of these kinds of frameworks. So I’m asking the list if they can suggest some. I’d particularly like to about potential examples from those developing IoT firmware or operating systems. Or authentication schemes for IoT. What sort of mechanisms and frameworks are available? What’s done in RIOT or the stripped down BSD/Linux stuff that underpins some IoT platforms? Anything else? The obvious example that springs to mind are dynamic SSL libraries - for instance the package managers that supply the latest version(s) of OpenSSL. Or the replacements for that which sprung up after the Heartbleed incident. However that’s a bit fuzzy. I suppose CAB Forum advice on X.509 certificates might be another. But there must be more. Any suggestions or pointers?

5 5

Re: [iot-wg] algorithm agility for IoT
by Jim Reid 21 Jan '19

21 Jan '19

> On 21 Jan 2019, at 12:36, Andrei Kolesnikov <andrei(a)rol.ru> wrote: > > Consider this problem of "hard wired crypto" only for specific class of IoT devices: power hungry, long-live, manageable, internet connected. The similarity must be with any user premises equipment, such as wifi routers, cameras, etc. I’m not sure that’s true Andrei. If an IoT device is on the Internet, it shouldn’t have hard-wired crypto. Just like how it shouldn’t have a factory-set password of 0000 or whatever. This should not be a subject for debate. It’s basic common sense.* Whether that device is a node in a sensor network or some piece of CPE is irrelevant from that perspective. Of course there are lots of trade-offs to be made when selecting crypto solutions for IoT: device lifetime, power, key lengths & rotation capabilities, memory & CPU capacity, bandwidth, costs, etc, prevailing policy & legislation, etc. But that’s an entirely different discussion which is orthogonal to the matter at hand. * It’s such basic common sense it isn’t written down anywhere. As least I’ve not been able to find it in a standards document yet. Which means that common sense can’t get baked into equipment procurements, RFPs and so on. So if there’s an RFC or ITU Recommendation or whatever along those lines...

3 4

Fwd: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues
by Töma Gavrichenkov 11 Jan '19

11 Jan '19

Hello WG, Here's a today's announcement from the NANOG mailing list. Some of the RIPE IoT working group members may want to take a look. -- Töma ---------- Forwarded message --------- From: Rich Kulawiec <rsk(a)gsp.org> Date: 10 Jan. 2019 г., 19:23 Subject: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues To: <nanog(a)nanog.org> The "dumpsterfire" mailing list is for the discussion of security and privacy issues related to the IoT (Internet of Things). Arguably, the entire IoT *is* a security and privacy issue, but we'll get to that in good time. If you want to join, you can either use the list's web page: http://www.firemountain.net/mailman/listinfo/dumpsterfire or the list's subscription/unsubscription address: dumpsterfire-request(a)firemountain.net The list is public and so is its archive. ---rsk

1 0

Re: [iot-wg] Trendmicro's "The Fragility of Industrial IoT’s Data Backbone"
by Jayden Rowley 17 Dec '18

17 Dec '18

Thanks for all the help and explanation regarding - https://1921681254.xyz/ Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Trendmicro's "The Fragility of Industrial IoT’s Data Backbone"
by Töma Gavrichenkov 06 Dec '18

06 Dec '18

Hello dear WG, Did anyone miss IoT DDoS attacks? They are back. And, this time it's not those nice Smart Home appliances everybody's so keen to talk about. It's industrial IoT nowadays. "...with this simple picture in mind, an attacker already knows which product is worth targeting in terms of exposed hosts. For example, by inspecting Kepware messages, an attacker can learn that this product is popular for the management of solar panel plants". https://documents.trendmicro.com/assets/white_papers/wp-the-fragility-of-in… | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera(a)gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58

2 2

IRTF SMART WG
by Peter Steinhäuser 13 Nov '18

13 Nov '18

Dear Collegues, on the latest IETF meeting the SMART WG of the IRTF was created: https://www.ietf.org/mail-archive/web/smart/current/msg00003.html Researching ways to identify malicious encrypted traffic might also be interesting for projects working on detecting unusual IoT device behaviour (i.e. SPIN or the project of the IETF home networking group presented by CERA on the latest RIPE meeting). If this research project succeeds it will raise a couple of other questions about encrypted traffic - to be honest I’m not sure if I like a positive outcome in terms of privacy and data protection… Best regards, Peter

4 5

Re: [iot-wg] iot-wg Digest, Vol 21, Issue 1
by Avetik Yessayan 09 Nov '18

09 Nov '18

Dear Jim, Congratulations to pass through this important milestone. Dear colleagues, I like to put forward my candidacy on WG co-chair. I bring an extensive experience in IOT system development from the industry and would like to take efforts in coordination and liaising between the RIPE and industry. I like to focus on standards being developed by different actors, and on compilation of those developments to bring it back to the community, to facilitate the ISPs, integrators and solution providers with recommended guidlines developed by those of the Parties. My background is in Microelectronics (undergrad) and Computer Engineering (graduate degree) from University of Southern California, having 30 more years industry experience working in Silicon Valley based high-tech companies, currently based in Armenia. Looking forward to work with you all with a common goal to make IOT more trustful and reliable infrastructure in the world. Thank you very much, Avetik ________________________________________ From: iot-wg <iot-wg-bounces(a)ripe.net> on behalf of iot-wg-request(a)ripe.net <iot-wg-request(a)ripe.net> Sent: Monday, November 05, 2018 3:00 PM To: iot-wg(a)ripe.net Subject: iot-wg Digest, Vol 21, Issue 1 Send iot-wg mailing list submissions to iot-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/iot-wg or, via email, send a message with subject or body 'help' to iot-wg-request(a)ripe.net You can reach the person managing the list at iot-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of iot-wg digest..." Today's Topics: 1. Consensus on WG Chair Selection process (Jim Reid) 2. appointing a co-chair (Jim Reid) 3. Re: appointing a co-chair (Peter Steinh?user) 4. Re: appointing a co-chair (T?ma Gavrichenkov) ---------------------------------------------------------------------- Message: 1 Date: Mon, 5 Nov 2018 06:19:52 +0000 From: Jim Reid <jim(a)rfc1035.com> To: RIPE IoT WG <iot-wg(a)ripe.net> Subject: [iot-wg] Consensus on WG Chair Selection process Message-ID: <2083A05E-DB01-4E77-93B9-415F13054466(a)rfc1035.com> Content-Type: text/plain; charset=us-ascii It's time to declare victory. So that's what I am doing. :-) IMO we have consensus and enough support for the selection process. My thanks to everyone who contributed to the discussion. There is one small tweak to the original text. Peter Koch suggested a clarification which got rid of an ambiguity: replacing "longest-serving co-chair" with "co-chair whose term is up". That's reflected in the text below. I will ask the NCC to put this on the WG's home page and also turn it into a RIPE document. (1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the co-chair whose term is up will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final. ------------------------------ Message: 2 Date: Mon, 5 Nov 2018 06:43:02 +0000 From: Jim Reid <jim(a)rfc1035.com> To: RIPE IoT WG <iot-wg(a)ripe.net> Subject: [iot-wg] appointing a co-chair Message-ID: <10A90F2C-F56B-4FA2-8047-F444B181CCD0(a)rfc1035.com> Content-Type: text/plain; charset=us-ascii Ladies and gentlemen, boys and girls, start your engines! :-) Since the WG now has an appointment process in place, it's time to use it. Anyone interested in volunteering as a co-chair is encouraged to step forward. It would be helpful if potential candidates could post on the list what their vision is for the WG and what they would/wouldn't do if appointed. I would also urge volunteers to consult RIPE692: "RIPE Working Group Chair Job Description and Procedures" to get an appreciation for what this role entails. I'll also be happy to provide advice and guidance to anyone thinking about volunteering, either in private or on the list. The tentative schedule would be to finalise a list of potential candidates by early next year and run the selection process in March or theresabouts so the new co-chair can be in place in good time for RIPE78. Please speak up if you think this schedule is unreasonable or impractical. Although I have no say in who the WG chooses -- I just make the consensus determination -- I would very much like to see someone new in the role. It would be a pity if one of the usual suspects got the job. Not that I have any criticisms of them. A fresh face, new thinking and a break from the same old routine is both healthy and desirable IMO. However that will of course ultimately be a decision for the WG to make. Over to you... ------------------------------ Message: 3 Date: Mon, 5 Nov 2018 09:53:53 +0100 From: Peter Steinh?user <ps(a)embedd.com> To: Jim Reid <jim(a)rfc1035.com> Cc: RIPE IoT WG <iot-wg(a)ripe.net> Subject: Re: [iot-wg] appointing a co-chair Message-ID: <E101EFDF-6C63-440D-9CD6-0BF2B43A091B(a)embedd.com> Content-Type: text/plain; charset=utf-8 Dear Jim, congratulations to the victory ;), it?s an important step for the working group to move forward. Dear Collegues, proceedings defined I put my hat in the ring for working group co-chair. I'm seriously concerned about the impact malicious IoT devices will have on the internet's infrastructure. My goal in the working group is defining best practices and standards about how can be dealt with IoT devices pro-actively to keep the coming attacks under control. Coming from a home gateway/personal router/CPE background (DD-WRT / OpenWRT) such devices are for me potential gatekeepers that can play an important role. Also ISP's should be brought on board, it's in their sole interest as well. To have an effect we need to gain maximum traction in the industry. There are already activities (SPIN / IETF home gateway WG) in this field. I would work on connecting the ongoing activities to form technical standards and reference implementations for easy adoption by the industry. I would also work on advocating these to industry players (i.e. Broadband Forum) to get broader support for these activities as well. It would be my pleasure to work closer with all of you for the better of the internet. Thanks in advance, Peter > Am 05.11.2018 um 07:43 schrieb Jim Reid <jim(a)rfc1035.com>: > > Ladies and gentlemen, boys and girls, start your engines! :-) > > Since the WG now has an appointment process in place, it's time to use it. > > Anyone interested in volunteering as a co-chair is encouraged to step forward. It would be helpful if potential candidates could post on the list what their vision is for the WG and what they would/wouldn't do if appointed. I would also urge volunteers to consult RIPE692: "RIPE Working Group Chair Job Description and Procedures" to get an appreciation for what this role entails. I'll also be happy to provide advice and guidance to anyone thinking about volunteering, either in private or on the list. > > The tentative schedule would be to finalise a list of potential candidates by early next year and run the selection process in March or theresabouts so the new co-chair can be in place in good time for RIPE78. Please speak up if you think this schedule is unreasonable or impractical. > > Although I have no say in who the WG chooses -- I just make the consensus determination -- I would very much like to see someone new in the role. It would be a pity if one of the usual suspects got the job. Not that I have any criticisms of them. A fresh face, new thinking and a break from the same old routine is both healthy and desirable IMO. However that will of course ultimately be a decision for the WG to make. > > Over to you... > > > _______________________________________________ > iot-wg mailing list > iot-wg(a)ripe.net > https://lists.ripe.net/mailman/listinfo/iot-wg ------------------------------ Message: 4 Date: Mon, 5 Nov 2018 17:05:11 +0700 From: T?ma Gavrichenkov <ximaera(a)gmail.com> To: ps(a)embedd.com Cc: iot-wg(a)ripe.net Subject: Re: [iot-wg] appointing a co-chair Message-ID: <CALZ3u+Zn-g36h80ag7vY+GDeMKYt1=iEcWq6y-On86u2S+eb2g(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" I support this. | T?ma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera(a)gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 On Mon, Nov 5, 2018 at 3:54 PM Peter Steinh?user <ps(a)embedd.com> wrote: > > Dear Jim, > > congratulations to the victory ;), it?s an important step for the working group to move forward. > > Dear Collegues, > > proceedings defined I put my hat in the ring for working group co-chair. > > I'm seriously concerned about the impact malicious IoT devices will have on the internet's infrastructure. My goal in the working group is defining best practices and standards about how can be dealt with IoT devices pro-actively to keep the coming attacks under control. > > Coming from a home gateway/personal router/CPE background (DD-WRT / OpenWRT) such devices are for me potential gatekeepers that can play an important role. Also ISP's should be brought on board, it's in their sole interest as well. To have an effect we need to gain maximum traction in the industry. > > There are already activities (SPIN / IETF home gateway WG) in this field. I would work on connecting the ongoing activities to form technical standards and reference implementations for easy adoption by the industry. I would also work on advocating these to industry players (i.e. Broadband Forum) to get broader support for these activities as well. > > It would be my pleasure to work closer with all of you for the better of the internet. > > Thanks in advance, > Peter > > > Am 05.11.2018 um 07:43 schrieb Jim Reid <jim(a)rfc1035.com>: > > > > Ladies and gentlemen, boys and girls, start your engines! :-) > > > > Since the WG now has an appointment process in place, it's time to use it. > > > > Anyone interested in volunteering as a co-chair is encouraged to step forward. It would be helpful if potential candidates could post on the list what their vision is for the WG and what they would/wouldn't do if appointed. I would also urge volunteers to consult RIPE692: "RIPE Working Group Chair Job Description and Procedures" to get an appreciation for what this role entails. I'll also be happy to provide advice and guidance to anyone thinking about volunteering, either in private or on the list. > > > > The tentative schedule would be to finalise a list of potential candidates by early next year and run the selection process in March or theresabouts so the new co-chair can be in place in good time for RIPE78. Please speak up if you think this schedule is unreasonable or impractical. > > > > Although I have no say in who the WG chooses -- I just make the consensus determination -- I would very much like to see someone new in the role. It would be a pity if one of the usual suspects got the job. Not that I have any criticisms of them. A fresh face, new thinking and a break from the same old routine is both healthy and desirable IMO. However that will of course ultimately be a decision for the WG to make. > > > > Over to you... > > > > > > _______________________________________________ > > iot-wg mailing list > > iot-wg(a)ripe.net > > https://lists.ripe.net/mailman/listinfo/iot-wg > > _______________________________________________ > iot-wg mailing list > iot-wg(a)ripe.net > https://lists.ripe.net/mailman/listinfo/iot-wg ------------------------------ Subject: Digest Footer _______________________________________________ iot-wg mailing list iot-wg(a)ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg ------------------------------ End of iot-wg Digest, Vol 21, Issue 1 *************************************

2 1

Draft minutes from RIPE77
by Jim Reid 09 Nov '18

09 Nov '18

Amanda Gowland has produced an excellent set of draft minutes from the WG session at the last RIPE meeting. Many thanks to her. Please speak up on the list if there are any errors or omissions. IoT WG RIPE 77 Thursday, 18 October 2018, 16:00 - 17:30 Scribe: Mirjam Kühne Agenda: 1. Administrivia Jim Reid opened the second official meeting of this group as a RIPE Working Group. 2. RIPE NCC Update (Marco Hogewoning) The presentation is available at: https://ripe77.ripe.net/archives/video/2307 Jim Reid asked how the community could help to fill the empty spaces currently in the directive. Marco said he didn't know at that point. He recommended to work with the local regulators. Pete Koch, DENIC, mentioned that there were large concerns about open source products. He wondered if there was awareness about that or special ideas for treating open source products. Marco responded that the document seemed to be fine with open source software, but manufacturers needed to stay within their limits. However, there were exemptions for amateur radio operators. Brian Nisbet, HEAnet, said that some of those pieces that were currently missing were things that should be there right now, for instance network abuse. He wondered why they were waiting for later. Marco explained that the directive was indeed very generic. It suggestd to stick within the particular regulatory framework, but it leaves details open to the regulator. Christian Bretterhofer, Andritz, suggested having discussion about why and what devices actually needed to be connected to the Internet. Marco explained that there was indeed an ongoing discussion about possibly slowing down innovation and making more conscious decisions about connecting or not connecting devices. Florian Streibelt, Max Planck, clarified that the exemptions were only for ham radio operations. 3. The Internet of Threats: Fighting FUD with MUD (Michael Richardson, Sandelman Software Works) The presentation is available at: https://ripe77.ripe.net/archives/video/2309 Artem Gavrichenkov asked who was going to implement this. Michael explained that they believed it should in the interest of the ccTLDs. It was necessary to make that investment. They would also present this at the ICANN meeting to encourage ccTLDs to implement this. Artem noticed that the presentation only covered smart homes, noting that that’s only a small fraction. He wondered why, for instance, industrial devices were not included. Michael explained that the protocols they were proposing to apply in the home were variations of some of the IETF protocols that were being developed for specifically securing industrial devices. Artem said he was afraid that smart home vendors weren't going to implement this because they would lose money. Michael explained that this was one of the reason they were building a firewall around them. Jelte Jansen, SIDN, made the audience aware of the SPIN project at SIDN and that there were quite a number of similarities to the presented solution. He suggested to possibly standardise the way MUD files were spread. Michael responded that the initial thought was to add a trust anchor and that they were going to get a curated database with changes that came from the community. Jelte suggested to think about a more general solution. Robert Kisteleki, RIPE NCC, applauded Michael and others for this exciting work. He asked what role machine learning could play, adding that this was the best remote presentation he'd seen. 4. Police Perspective on IoT, Challenges and Strategy (Jaap van Oss, Manon den Dunnen, Politie Nederland) The presentation is available at: https://ripe77.ripe.net/archives/video/2311 Jim said he hoped this was a start of an ongoing dialogue. Artem asked what data source the speakers were using for making the statement that the majority of DDoS attacks come from IoT devices. Jaap van Oss responded that this was based on his general knowledge in investigating these kinds of crimes. 5. Security Problems in IoT (Thomas Stols, Computest) The presentation is available at: https://ripe77.ripe.net/archives/video/2313 Jan Zorz, ISOC, asked if an IoT device had the 'smart' at the core, was connected to the Internet and could be controlled from the cloud. He wondered whether it was a security risk. Thomas responded that this was not necessarily the case if the cloud was properly secured. But yes, it could definitely be a risk. Brian Nisbet was shocked to hear that a hackers' organisation was shorting the stock of a company just because they have no bounty programme. Tomas said he agreed, but from a legal perspective this was a grey area. Manon asked if Thomas thought that sharing biometrical identity was the way to go. Thomas said it could possibly be used as an additional security mechanism. Manon said she was concerned about this, because it’s giving away the closest thing to our identity and sharing them on the Internet. Thomas responded that it was definitely improving security compared to passwords. Peter Steinhäuser, enbeDD, clarified that the facial recognition of Apple was actually not going to the cloud, but it stayed on the device. Neofytos Kountardas, Greek Cybercrime Unit, added that the European Commission was looking at the option to add cybersecurity certificates for devices. Thomas welcomed this initiative by governmental institutions. 6. The Internet-of-Insecure-Things: Causes, Trends and Responses (Arman Noroozian, TU Delft) The presentation is available at: https://ripe77.ripe.net/archives/video/2317 Jim thanked the speaker for this fantastic work and said he would like to see more of this kind of work. Jelte said he was surprised to see that doing nothing is better than informing your customers by email. Arman clarified that people just tended to ignore these kinds of informational emails. Purely sending abuse emails didn't seem to work. 7. AOB Jim said he would like to close the discussion on the WG chair selection process on the mailing list shortly after this meeting. He hoped to have a co-chair for RIPE 78.

1 0