Database Working Group
30th November 2023
At 9 a.m:
WILLIAM SYLVESTER: Glad to see everybody is up early this morning, especially after the activities last night, we have an exciting agenda today, we are going to go through our NWI updates, Ed is going to give his operational update and we have a couple of interesting presentations and we have the ‑‑ I wanted to thank RIPE NCC for scribing this meeting and being the secretariat and thanks to the AV team for helping us out and making sure everything goes smoothly. We will jump right into it, so I also want to introduce our new co‑chair, David, he is going to give us our NWI update, welcome, David.
DAVID TATLISU: Hi, everyone. We unlike other Working Groups have something called numbered work items and I have got a couple of updates since RIPE 85 I would like to talk about.
NWI is numbered work item similar to a ticket. We have a defined process where the Working Group participants approaches the Working Group Chairs with a loose problem definition, the chairs can decide whether or not to accept that and if they do ‑‑ if they decide to accept it they return it to the Working Group mailing list where a more final problem definition is defined. The Working Group participants and the NCC will then develop a solution definition, the NCC will go ahead and implement that definition and deploy the necessary changes and then the NWI is completed. During the entire process it's possible the Working Group Chairs cancel the NWI when it's deemed no longer necessary.
Starting with NW12, it concerns displaying history of deleted objects where available, NCC presented a legal analysis going over among other things potential privacy concerns and questions regarding the scope and requirements, a more tangible problem definition might be required.
Continuing with NWI‑4, the fundamental problem is that objects cannot have multiple status values at once, inetnum allocation cannot be assigned as a whole, because that requires the same objects have to be required and allocated at the same time. The NCC has published a network analysis and Edward will go into more detail later.
NWI‑10 adding the country attribute, this has been added and auto filled by the NCC so this NWI is now completed.
NWI 12 concerns implementation of NRTM v4, syncronised between different registries and the implementation is about 99.95% finished. We can probably consider NWI finished and Edward will go into more detail in his operational update. Of.
NWI 13 added geolocation attributes, specify the rough or accurate location of IP addresses, has agreed to proceed and the attributes are available now. I am sure many of you have already seen this but it looks like this, you add your geofeed attribute which serves standardised, add ‑‑ with NWI 14, it's about protecting references to object in the RIPE database, so it added the optional MNT like maintainer IoT and this can prevent an organisation's contact being used in the wrong organisation so it's just a little anti‑abuse measure.
Now, since we, the amount of activity on the mailing list varies quite a lot I would like to ask do we as could chairs need to change something, do we need to how we work with NWIs, change the entire process? Would the Working Group like to try interim sessions on Zoom, I have already talked to the NCC and organising them shouldn't be a problem. Do you think something is missing, do we need anything to work more effectively or do you think everything is fine and we are just worrying about nothing?
So I'd like to start a discussion if anyone wants to comment?
All right. That was the end of the update.
(Applause)
WILLIAM SYLVESTER: Up next we have Ed with our operational update.
EDWARD SHRYANE: Good morning, welcome. I am a software engineer for the database team at the RIPE NCC and I am presenting on behalf of the team. We are five people now in the team and we are ‑‑ this is the result of their work since the last RIPE meeting and I'd like to thank them for their effort in contributing to all of this.
Progress since RIPE 86. First of all we have had three Whois releases, 1107 in June where we finished we added NWI 14 which as David said we are adding the MT MNT ref, if you want to protect references to those object types you can use MNT ref there.
We made improvements to version 4, Version 1108 in September we made more changes improvements to the full text search API and index improvements so we fixed edge cases in separating words in the API and we improved how we index objects, how we structure the index. And finally, 1109 in November, it's due in production next week, next Monday, we have now removed a prefix validation on the geofeed attribute following an Executive Board decision, geolocation is now a purpose of the RIPE database. We implemented the RDAP redaction feature and I will speak more about that. We now support HTTP basic authentication and client certificate authentication.
We had two Whois outages since the last RIPE meeting and both related to mail updates. In June there were intermittent delays due to a locking issue, we use a lock to claim and process incoming mail updates, and we found that contention/non‑contention failed in Whois rather than retrying. So we put a work‑around in place. Unfortunately, on the 28th August mail updates was again delayed due to a manual work around, the first due to the first out age and we didn't know because monitoring didn't alert us, now the underlying issue is fixed and monitoring is now also fixed so there shouldn't be a reoccurrence of that.
So some statistics on Whois features.
Regular abuse‑c validation as Marco presented yesterday morning, we now have 93,000 Abuse‑c addresses and we are on track to complete validation of all those addresses by the end of the year. RPKI we have two clean‑up jobs to reduce the size of the NONAUTH database, we have deleted just over 400 objects since last RIPE meeting. NWI 8, it's a useful feature where you can check a box in the portal to syncronise into the default maintainer in the Ripe database so you can same the same SSO account for authenticating and maintaining as you would use in the portal and just over 1,500 LIRs now are using that.
And finally, the NWI 9, the NRTM service is open, almost 500 clients using version 3, the classic NRTM in production.
We have done two clean‑up remarks jobs, first we removed the non‑authentication remarks, which are there for almost 20 years, affecting just over 600 objects. And secondly, we removed the ref SRV attribute which was removed in 2009, affecting nearly 35,000, and in both cases we were sure to notify the Working Group and also e‑mail maintainers before and after the changes. So people were kept informed.
Operational work:
So behind the scenes we have done some improvements operationally, we are now doing better monitoring inside our applications so we can have more insight into how the application is behaving. Previously we have had a lot of OS monitoring but nothing within the application so now we can ‑‑ we have a better view of memory usage, CPU usage, threading, so we can keep an eye on that operationally and also for feature changes we can see the impact in production.
We are doing more frequent server and application patching, we are using latest long term versions, we are also more frequently patching our ‑‑ all of our environments, the OS. We are ‑‑ as part of the Whois work we have ‑‑ we are he migrating our applications to use HTTPS in the back end rather than load balancer, that has some advantages for us because we have more control over TLS, we can turn on and off features and control better the algorithms, and TLS versions that we support, and we can also do better fine grain support of certificates, using let's encrypt now, automating the certificate rotation, certificates are per server and per name so we will be phasing out the start certificate for the DB sub‑domain. Finally, we have a procedure for password rotation, we are now rotating all database passwords regularly.
Web application, after announcing at the last RIPE meeting it is now Open Source, the link is there, it's on GitHub, we completed an external security review and no major issues found, we think it's important that we work in the open, that our code and our work is visible for review and feedback, and that you can keep track of changes rather than waiting for an operational update, you can see as we land features and deploy them, you can see both fixes and feature changes.
We are also supporting unsupported browsers better, so previously really old browsers would display a blank page if the framework we are using different start, now we detect that and we display a message asking you to upgrade your browser. Secondly, the framework generally only supports the latest versions of major browsers and we saw just a little bit further back like browsers even from 2001 fell out of support, so we'd like to improve that so we fixed it by allowing the application to still start but we display a banner rather than stopping people from continuing. I encourage people to update but there are plenty of users on older browsers and for various reasons they may not be able to update so they should still be allowed to use the web application.
We are now filtering maintainers by selected organisation. This affects users with multiple LIRs, previously on ‑‑ in the web application you would always get all of your maintainers which could be annoying because you would have to edit and remove them again depending on your organisation. Now we are a little bit smarter, depending on your selected organisation if you have a default maintainer we will just use that. And filter out the others. And
Finally, a minor improvement but on the query page it's possible to use flags in the input field, now you can also share those results with others so the page is a little bit more useful when you are using flags.
RIPE database documentation, as previously mentioned, we have now ‑‑ we have now completed our migration from the old DB support page on the website, the goal here was to try and get all of the documentation together in one place, do a review of anything that's outdated and make it more maintainable. So all the documentation is now in marked down format, we have published a source code, although this time the text is under a non‑commercial licence, if you want to use commercial you need to talk to the RIPE NCC. And planned, we are going to move our documentation to a specific standalone website, we had been using the web application website for convenience but I think it makes sense that the documentation is standalone.
RDAP, we have made a number of improvements there. The registration data access protocol, it's a next generation Whois using more modern standards such as HTPS and JSON. There's a cross RIR effort to fill in the gaps between the existing RDAP and Whois. One of these is redacted fields so we are documenting in the RDAP response what's missing and in particular e‑mail, we are filtering out e‑mail by default because we don't want to block you for querying for personal data. So we will now tell you that we are filtering out e‑mail, for example, in the redaction element.
We are ‑‑ and a point to note is we are using the redaction by removal, there's different types of redaction document and in the draft RFC, that's what we are doing.
As mentioned, we are filtering e‑mail addresses now, to match the behaviour in Port 43 and to make sure you don't get blocked for using RDAP and e‑mail is in redacted.
Mag news at the last RIPE meeting pointed out he wanted to see some improvements in the documentation for RDAP we have updated to document the redacted feature, and we have started to document better the differences with the standard RDAP RFCs and why the differences are there but also we are making another effort now to review the differences and to try and reconcile them, some of them are more difficult than others, but we are going to try again to reconcile with the spec and also between the behaviour, between the different RIRs that we are consistent with what the other RIRs are doing.
Finally, well, also the last word on the full text search API, we have been approving that over the previous months. The API is there for direct use by end users, you don't need to go through the website, the API is better documented so you can use it directly but we have also improved the web interface and various bug fixes that were reported by our users so thank you for that, I think it's now a much better service.
Client certificate authentication, this will be added next week, it was requested by our community quite a while ago and we did have a trial implementation which depending on our load balancer but there were shortcomings, but now we have implemented in the back‑end, we are completely in control of the certificate ‑‑ the authentication process and also the http S makes it easier, I have documented here an example so we support self‑signed certificates as well as, yeah, certificates with a trust, route trust, to try this out it's already in our release candidate environment, procedure is pretty straightforward. Why would you want to do this? You are not sharing secrets with the RIPE NCC or in transit so you can create a certificate with a private key, you share the certificate, which is public, in the RIPE database, and you can authenticate using your certificate end key in the TLS negotiation when you make a request, it's more secure because you are not sharing a secret.
So the procedure would be to create a certificate or purchase a certificate, you copy the certificate to a key cert object so you print out your certificate text, you put it into key cert object, you link your key cert object to the maintainer and you can use, there's broad support for client certificates in HTP clients so you would ‑‑ for example using curl there is a couple of parameters to specify your key and your cert and you can authenticate updates
Number of work items, David has mostly covered this already but very quickly, mostly I want to talk about NWI 12, which is NRTM version 4, it's mostly feature‑complete, I would suggest it's quite usable now. Snapshots are there, the notification file, is there, signing is there and delta files are there. Key rollover is one thing, as Sasha discussed on the clients side Sasha is working on adding NRTM support to IRRd, one thing we need to test is key rollover, at least once a year. What we support now, it's already turned on in production so you can start using it, the URL is public and the sources are separated, we have a public key is separate, it's not part as part of the service itself but published on the FTP site, you have more freedom, you can test more broadly there and try it out. Please let us know your feedback.
Upcoming changes. Very briefly, there's more effort needed for cleaning up remarks attributes, two things left over, we want to do something about the ERX transfer, remove legacy remarks but as Denis pointed out, maybe the better ‑‑ we are also try to fix the data, it's 20 years old, it is a data from early registrations, we asked our end users to fix the data themselves. If you feel strongly that we should be making an effort to fix this data instead of removing the remarks please let us know.
Secondly, references by name it's a bit more straightforward, like the other jobs, we will notify the Working Group and the affected maintainers in advance, before we do that.
RIR search, this is another effort by the other RIRs, there's a draft RFCto extend RDAP to extend better searching for resources and also hierarchical searches which is missing right now, that's already in progress, we are working on that, so expect it in the coming release, we are going to add geofeed, it's a pretty straightforward RFC, I think two pages, so we are going to add geofeed there also and it will be an additional profile in RDAP. Finally, in our web application we want to warn when a route object conflicts, you will get a banner above the route object if there's a conflict, and thanks to the RPKI team, we are working on that with them.
Proposals, very quickly, came up in the last ‑‑
SHANE KERR: So, a quick question sorry to interrupt. A quick question, when you come to the last slide, you are warning when a route object conflicts with RPKI, is that a background test or during scans or ‑‑
EDWARD SHRYANE: It's just during query, not just up ‑‑ anyone can see it, not just the maintainer of the object so it's for everybody. You will see in the query response if there's a conflict.
SHANE KERR: Okay. Interesting. I think if ‑‑ as someone who is maintaining objects in the database, I think they'd be interested to know that and they could actually do something about it whereas query might be interesting but also not much you can do about it.
EDWARD SHRYANE: That's definitely something that was on my mind because you may not be able to do something about it but I think it's better to be informed if you are using the information from that route to be aware that there's an RPKI ROA that is conflicting with it. So I'm happy to take any feedback from the community on how best to do this, but right now the plan is to add it in the query, yeah.
SHANE KERR: Thank you.
EDWARD SHRYANE: Thanks, Shane.
RUDIGER VOLK: When you say you are issuing the warning on queries, that means in the web interface?
EDWARD SHRYANE: Correct.
RUDIGER VOLK: Maybe some API, but not the traditional Whois?
EDWARD SHRYANE: Yes, correct, that's a good clarification. It's possible to do it in Port 43 with a comment but it could be disrupttive if you are not expecting it, if it's a new comment and you are parsing objects and comments. For now, we will just add it to the web output and API, there will be a flag in the API response so you can detect it.
Proposals. Just two proposals. Massimo Candela pointed out in the last session a country is currently mandatory, undefined, sent to anything about the resource maintainer, it's open to interpretation what it is. Maybe it should be optional rather than mandatory. So I am happy to take feedback, I will write an e‑mail to the Working Group asking what people want there.
I think it was last week I wrote an e‑mail asking for ‑‑ proposing we add non ASCII characters to names, that's turned into a discussion about UTF‑8 and hopefully that can be discussed further. But just to point out there's an impact analysis there from last year on the process of doing UTF‑8 in the RIPE database.
RUDIGER VOLK: On essentially changing the syntax, I wonder, the original RPSL actually had pretty specific formal grammar for the syntax and once in a while, in the past, I ran into problems because objects did not conform to the grammar. I am not quite sure what techniques, all of the tools that are used today are based on, but I think, I think I would still like to see good grammar for the resulting changed syntax, not quite sure how easy that works with going to UTF‑8 but I think really, real strong formal grounding for the syntax is a requirement.
EDWARD SHRYANE: Thank you, I completely agree. This is something that the Working Group needs to decide on before we make any changes. The RFCs specify ASCII, we already allow non ASCII in the database, there is description remarks, not in names, not in primary keys, but it's something we need to be careful of the impact because there is such wide use of Port 43, 90% of our traffic is still Port 43, we do support UTF‑8 in rest API and web application but most of our traffic still uses Latin‑1 or ASCII so we need to be careful before any changes.
HARRY CROSS: Is there a plan to extend that to certificate authorities later down the line because I am thinking about potentially generating very short‑lived certificates for a one time update or something?
EDWARD SHRYANE: You mean that the RIPE NCC be their own certificate authority?
HARRY CROSS: You can issue and short‑lived certificates from that to do your updates?
EDWARD SHRYANE: That's a great idea, we can certainly support that. Thank you.
HARRY CROSS: Thank you.
MARCO: I wrote the Whois client that everybody uses. Unfortunately, I actually implemented in the client that responses from the RIPE server are Latin‑1, so returning UTF‑8 will cause issues unless this is changed. Well I totally support the returning UTF‑8 ‑‑ start with this right now.
EDWARD SHRYANE: UTF‑8 is backward compatible, ASCII characters will still appear as that and anything else will chain and Latin‑1 no longer Latin‑1.
SPEAKER: The client will recall the input, assuming it is Latin‑1 and record it to whatever is the ‑ of the terminal.
EDWARD SHRYANE: There's nothing in the protocol to tell the terminal, just changing from Latin‑1 to UTF‑8 is going to be a big change.
SPEAKER: Are there implementations using common line apartment on the query? This could be a very good solution because it will allow clients to support UTF‑8 at their own pace, this will solve everything.
EDWARD SHRYANE: Yes, that's a great idea because we already support converting from different character sets and update, we can do that on query as well and if the client can tell us what characters they want that would be a really nice solution yes.
SHANE KERR: I think that's a really good idea to have the client signal and I propose we use the rocket emoji as a suggestion for that.
EDWARD SHRYANE: The Cloud consultation and in the weeks that I optimistically said at the last RIPE meeting has turned into months but the Cloud consultation document is now in review, we are taking some extra time to make sure it's right and it has enough detail for good feedback and once it's ready we will publish the Working Group for consultation, and secondly, we are conscious of Cloud costs and we are looking at the permissions of our ‑‑ any Cloud architecture against the budget for next year as well because anything we want to propose has to be realistic.
Any further questions?
WILLIAM SYLVESTER: We have a couple of questions from ‑‑ from one united: "Is there any information on what objects have been changed in the process of NWI‑10 deployment?"
EDWARD SHRYANE: Well, you can see in the database anything that's ‑‑ that is ‑‑ any organisations with ‑‑ any organisations or end user organisations with resources, NWI‑10, country codes are now mandatory there so you can see there, you can check the database I can publish the numbers in the Working Group, that could save some effort. Those numbers, we can come up with those.
WILLIAM SYLVESTER: Robert Shack from ETS. Does the latest TLS version of Java mean Java 21 already?
EDWARD SHRYANE: The LTS version of Java 21 is only TLS since middle of September I believe, we haven't had time to implement that, we are currently using 17.
WILLIAM SYLVESTER: Thank you so much.
EDWARD SHRYANE: Thank you.
(Applause).
WILLIAM SYLVESTER: Up next we have Mark Kosters.
MARK KOSTERS I am glad you all can see me because a lot of time podiums are too tall. From ARIN. And I am doing something a bit different here so this presentation has no graphics on it, so, and this is very much sort of in the IETF sort of format.
RUDIGER VOLK: What are the graphics in the lower left corner?
MARK KOSTERS: That wasn't ones I did. So I think that's part of the presentation material here.
But anyways, so this is very much in sort of the IETF sort of realm because this is something that has sort of come up since the last RIPE meeting. So Massimo Candela gave this presentation about geolocation, right, during the plenary, and it was pretty interesting, it was even more interesting afterwards and what was said at the mic. But it got us sort of thinking, so, you know, this stuff we have heard in various regional registry regions that this is something that we all should do. So I'm bringing this to the floor and I am glad to see that Ed is already thinking about implementing this so this is good, it's going through some review right now, it's ‑‑ I am talking about this, but this is going ‑‑ is in the IETF and going to be part of the Working Group.
So, let's go talk about our predecessors. Let's go ahead and talk about Whois. So, Whois is ancient, right? And we have been trying to get rid of this puppy for years and we have ‑‑ we all know the issues with this protocol and we are talking about this today, talking about character sets and stuff that modern systems are already taking care of but we are still dealing with 1980s technologies but why aren't we thinking about doing a replacement? And there has been many attempts so we have Whois plus plus and R Whois, ARINs RWS etc., lots of people have tried to put this out. We have one we think will stick and that is RDAP, here you can see the RFCas specified. All the region registries actually have this deployed. What's interesting, how many of you all know that domain registries are ‑‑ have contracts with ICANN are mandated to actually implement RDAP? A few.
So this is coming. And who is, for domain registries, who knows what's going to happen to it, I mean it's really kind of a loss leader for them, if I was them I would kind of turn it off, it's not all that useful anyhow because almost everyone has stuff redacted for their domain registries. But it's happening, right, and we are right now, it's in the second phase where the wrap‑up period begins and we have the sunset day of January 28th of 2025 when you need to have RDAP implemented for the domain registries. And if you want to take a look at it, here is the URL below, to take a look and see what I have on the screen is correct, I think it is because I cut and paste. So, you can see that hey, this is something that maybe we should consider as we go forward with this. Hey, maybe Whois, which is a prodominant share of all our traffic, all the regional registries traffic, the predominant share is with Whois but some day RDAP may be taking over and clients may be taking over in terms of querying for this information, which traditionally done with Whois.
So all the regional registries have this deployed. There was a survey done of all the implementations and we discovered differences in how we did things and we figured out a way forward, and this resulted in an RDAP profile specification and here is the document for this, it's actually part of the ECG where all the regional registries tech guys and girls get together and try to figure this stuff out. So, we have all agreed to it and four out of five RIRs are now in compliance so we all behave the same way.
So, in the last RIRs planning on having this done in Q1 of next year. So this is showing good momentum going forward with RDAP to replace Whois.
So, I'm hopeful that RDAP will be the replacement to Whois and maybe in five years we can look at this presentation and say, well, okay, you can still render it because it's all in ASCIIish and you can see it and you can actually say well okay this is actually what happened in years past.
So, let's talk about geofeed. So this is something that intrigued me with what Massimo brought up at RIPE 86 and said here is interesting way of going forward where the regional registries don't have to store any of this data, all they have to do is basically have a URI point to go where to find it and RFC9092 talks about using the remarks field and is now being replaced by geofeed field, which is fine, but not all of us are going to implement that between all the regional registries.
So, ARIN, for example, doesn't have remarks field in our Whois system, right? LACNIC doesn't use the same things as we do. So I'm not sure if this is actually the right way, it's a fine way of doing it but I am not sure if this is going to be the consistent way going forward to making this happen. So this is something that hey it's fine, let's throw as many things to the wall and see what sticks but this is something that we are all looking forward, how things are working.
So, here is the proposal. And basically, within RDAP there's IP network class, that includes new geofeed member and you can see the geofeed member is very simple and includes privacy and security considerations. So this is being promoted within IETF and that's one of the reasons why I made this presentation very unsexy, and it has a lot of good sort of forces going forward with it, people who have done previous drafts that have been working towards this, like this idea and are intrigued by it so we are looking forward to seeing how this goes and I was wondering if you had any questions about it and see if this is something if you wanted to follow through on and I am glad to see that RIPE is actually doing this, thank you very much, Ed. If you want to look at the references, you are more than welcome to, there's more work to be done here. What do you guys think, good idea?
Who thinks it's a bad idea? I am not seeing anyone is thinking this is a bad idea, thank you very much and I think I saved a little bit of time.
(Applause)
WILLIAM SYLVESTER: Thank you, Mark. Ed, you are back up. NWI‑4, Tuple impact analysis.
EDWARD SHRYANE: I'l be very brief this time. I would like to briefly explain the requirements for NWI‑4, the two impact impact analysis done so far and I would like to get out of the way to encourage some discussion on the best way forward.
So, the background is that particularly with smaller allocations now, there's more of a need for single assignments within that allocation. The requirement is to create an assignment, allow an assignment that is the same size as an allocation where you have a single assignment. Currently there's a work‑around where you have to split your one assignment into two, which is a bit of a hack. So ideally we should allow support an assignment that's the same size in the RIPE database. The first idea was to add new status value, allocate it a signed PA so combine the allocation and assignment together into one object, published the impact analysis last year. One of the major drawbacks though ‑‑ the advantages are super straightforward and simple to understand, with the downsides are multiple downsides, the INET must could maintain between the RIPE NCC and the LIR the current allocation structure and not by the end user so the end user doesn't have any input to putting their own data in there. Assignments often have a different maintained by than the allocation, I found that over one‑third of the assignments have a different maintained by, presumably the end user and of course an assignment can have different in there, so combining all this into one object it's going to be tricky.
Also, secondly, clients offer most interpret the new status as both an allocation and an assignment. So if they see this value they need to understand that it's an allocation and assignment. If you are counting allocations these objects should also count, if you are looking for an assume this also should be included. There was a comment at the last RIPE meeting expressing a preference to use a Tuple, combined status and prefix rather than changing the status, turns out we do this in a different way, route and Route‑6 objects we use a tuple of the prefix and the origin. We could absolutely do this for inet nums as well and that would allow multiple objects with the same prefix in the database.
Published an impact analysis in September, as I said there's a precedent in route objects, also clients need to be updated to be aware of this Tuple and I think the ‑‑ one of the major drawbacks, the way RDAP is specified it doesn't expect a Tuple in an IP object so you can't query for an object like this using RDAP.
So they are the two options so far. Can I open up to questions, suggestions, comments, how do we move forward?
WILLIAM SYLVESTER: Anyone? Anyone awake?
EDWARD SHRYANE: If there's no discussion at this time I would invite people to take part in the Working Group mailing list, I would appreciate any feedback. We are stuck between two choices with down sides to implement this. We can pick one of them. It's for the community to decide.
RUDIGER VOLK: There's one in the queue.
EDWARD SHRYANE: Thank you, Rudiger.
SPEAKER: Thank you very much for this ‑‑ the detailed impact analysis, I am still in full support of the Tuple solution, the RIPE database should, contact should match as close as possible to what's happening in realtime, software updates happen all the time. I am considering this to be one of them.
EDWARD SHRYANE: Okay. Thank you. If there's no more comments, I will leave it at that and back to the mailing list. For a way forward we need a decision from the Working Group, thank you.
(Applause)
WILLIAM SYLVESTER: So with that, that wraps up our agenda. The last item on our agenda is any other business, so if anyone has any other business, please come to the mics and bring that up. Now that there's a few more folks in the room from when we started, I want to propose a couple of ideas that David did in his presentation at the beginning, one of those is does it make sense as a Working Group for us to set up interim calls or other types of contact points between meetings as a way to foster communication, as a way for us to better conduct business and provide feedback, especially when feedback might be interesting for smaller groups, who maybe care about a specific topic that the entire Working Group may not, and within that, I know we have had several topics that have fit in that bucket recently where we have had a few vocal voices that were very interested in something specific, so with that I would open up and ask. Shane?
SHANE KERR: IBM. Yeah, I think if you are going to want to actually get work done that's a really good idea. The time between RIPE meetings is just too long ‑‑ these meetings are great venues for lots of information sharing and raising points and things like that, but they have the kind of detailed discussion that you are going to need, you want to have people sitting in a room or sitting on a Zoom session and looking at a document and going through point by point which I think it's perfectly fine but it doesn't fit this style of work, I think it's great, go for it.
WILLIAM SYLVESTER: Great, thank you.
ERIK BUYS: I agree with Shane, the amount of time waiting, it's just not practical. I think there are requirements for the Working Group to be updated and people are vocal enough to specify if it goes into a direction or if they have questions on it, but please do not wait on us. You know, I think it has better things to do than waiting on feedback, which is not coming and for the majority of the things I would say it's silent consensus in that case.
WILLIAM SYLVESTER: Sure.
MIRJAM KUEHNE: RIPE Chair. I think it's a great idea and really welcoming this initiative and other Working Groups have done similar interim sessions and they have made great experience with that and as ‑‑ well the previous speakers both said the time between RIPE meetings can be quite long and it's great to see some more engagement and activities in between and the RIPE NCC is actually supporting this so it's really easy to set that up, contact me and I will help you out.
WILLIAM SYLVESTER: Great.
RUDIGER VOLK: Questions. Did you have in mind something that is kind of regularly scheduled which might be just once in the middle.
WILLIAM SYLVESTER: Sure, sure
RUEDIGER VOLK: Or every other week or whatever, or something ‑‑ or something where kind of on demand when a certain topic is getting hot and demanding, demanding attention, looking at IETF, I'm seeing some Working Groups there doing weekly scheduled stuff and others just on demand and there seems ‑‑ well okay it's actually a very different work style, I wonder which direction one would want to go here?
WILLIAM SYLVESTER: I mean from my perspective I would think it makes sense to do a hybrid which is maybe start with one meeting or two between meetings and then from there, if we have topics that are hot, we can also of course schedule extras or get together groups, obviously everybody would be welcome but if a group wanted to get together and set up an interim session, that to me would make sense as well. Much of that is to the discretion of the Working Group, as a Chair not necessarily trying to dictate anything here, mostly just trying to facilitate communication and discussion and from there go through. David, did you have some other comments?
DAVID TATLISU: The original idea was to schedule the first meeting sometime in December or early January, and then just see how really demand is and ‑‑ yeah.
WILLIAM SYLVESTER: Go from there. Anyone object? Then we have silent consensus.
Is there any other topics that anyone would like to bring to bear, any other questions, concerns, issues about anything relating to the database? Going once, it looks like we are running a little early today for once. Thank you so much for everyone attending, especially since we have this new time slot early on Thursday morning which I know is a little difficult for some. Within that, though, I also wanted to thank the AV team for all their help and RIPE NCC for being secretariat and also for being scribe and the stenographer for helping us out with making sure everything is up on the screen so we can all keep up, so thank you very much. And with that, we will adjourn.
(Applause)
(Coffee break)
