RIPE 85
Database Working Group session
27th October 2022
2 p.m.
WILLIAM SYLVESTER: We're here for the Database Working Group today and we have a fun filled agenda. Unfortunately my co‑chair Denis is unable to be with us today, so, despite his multiple presentations please bear with me as I offer up some of his content, and we'll have some fun with that.
The agenda today is, obviously we're in the welcome. We have an NWI update. Ed will be remote offering us the operational update. We have a geofeed discussion and then we have proposal 2022‑01. I want to thank the scribe and RIPE NCC for all their help, both on Meetecho and transcribing for us. So thank you guys.
And otherwise, one of the others things I wanted to talk about is session planning, as every Working Group we have elections, we have Chairs, we technically have three Chair positions open for the Working Group for quite a while, we have had one vacancy, so if anyone is interested in learning more about what it means to become a Chair or getting more information, please reach out to me or feel free to email us, or mail the mailing list. We're going to be doing some elections coming up soon, but from that election, I just wanted to put some stuff out there as Denis and I probably won't be around forever, and at some point we need to find some other talent to come in.
With that, we'll jump into the NWI updates.
So, we have these things in database called numbered work items, a little different from a lot of the other policies that we have in the general sense that it's directions we give to the RIPE NCC that we work on as a group, and so within these ‑‑ you know, we have struggled a little bit as we have had a lack of community involvement. We have bursts of activity. I think when we started out I think we had close to ten of these. We have worked through a bunch of them. We have a couple on the agenda today, but there are long periods of silence and we have struggled for consensus on some of these. The one thing I would encourage is as we talk about this on the mailing list, all of our business happens on the mailing list, all of our discussion happens on the mailing list and so from that, we encourage everyone to comment, because that's something that's very important for us to both conduct the work within the Working Group and for us to get done the stuff that we're doing.
So we have 3 options. Detailed community discussion and consensus. This rarely happens. Some of the stuff we treat as bugs or small fixes. Often times RIPE NCC will approach us and say hi, we have a list of things that we think need to be fixed. Usability issues, user interface updates, performance problems, other types of things. Or the third thing is just for us to close some of these items. Due to lack of interest from that perspective.
So if the community doesn't discuss it, then, you know, we pass certain things onto the NCC to fix it. If there is no objections raised, it just gets fixed. You hear about it at Ed's presentation coming up about operational updates. If there is, you know, no objections raised and there is no discussion, we end up just closing it.
So, here we have NWI 2, the history of deleted objects. The NCC legal team presented at RIPE 84. We need requirements for historical data. So we're looking for folks to contribute and offer volunteer... NWI‑4 is assigning a whole allocation. Has a possible new status value. NCC is working on an impact analysis. And database analysis is done and Registry Services still has some concerns. With NWI‑10, country attribute. It's still ongoing by RIPE NCC, in advanced stages. And then for NWI‑12 and 13, NRTM version 4 the NCC is working on a server implementation. Then we have geofeed to be discussed today.
As far as 14 extending the maintainer reference, RIPE NCC is working on implementation plan.
And then with NWI 16 IPAM recommendations by the Database Task Force, it's been discussed on the mailing list recently with Denis and Shane. We have asked for input from operators who use the database for IPAM and so far we have had no responses.
For 15, 17 and 18, the task force recommendations not yet considered. And for 18 we're still sort of reviewing policy 2022‑01 which we'll talk more about later.
Any questions on NWIs? Okay. Seeing none, we'll jump to Ed's presentation for the operational update.
EDWARD SHANE: Good afternoon. Thanks. Can you hear me?
.
Good afternoon Belgrade and everyone that's joining remotely and apologies I couldn't be there in person today. Here is the operational update from the database team.
I am Edward Shane, I am a senior technical analyst with the database team at the RIPE NCC.
And here is the team. Two have joined since the last RIPE meeting, Miguel is a software engineer and ops engineer.
And progress since the last RIPE meeting. We have had one Whois release at the beginning of October and it's there are a lot of small improvements and bug figures, primarily we have made improvements to the RDAP interface, we have removed Whois tags which we have talked about on the list before, we have added text/plain to search the rest APIs. There was some discussion on comment, as multiple comment is no longer available on updates and we no longer allow updates in comments to managed attributes. Finally, this affects NWI 10 the organisation country code is now modifiable for end‑user organisations without any RIPE NCC assigned or allocated resources.
There are two outages since the last RIPE meeting, apologies for that if anyone noticed. So, the first one was the mail update service on the 1st September, there was an outage for, it's used by a lot of people. There is still a lot of traffic through mail updates. But we updated the XM package which caused the local configuration to be invalid. It's something we didn't pick up with testing. And but we saw that mail bounces and we had to fix the configuration to resolve the issue. And a lesson learned from is to improve our testing and monitoring foreign incoming mail updates. We're looking to improving the configuration for mail updates, so incoming mail is sent directly into the Whois application.
Secondly, between the 7th and the 11th October, the RIPE database e‑learning environment was inaccessible over IPv6, and this was due to a reinstallation of the training environment. We changed the firewall rules, but ‑‑ which allowed traffic for IPv6 from the RIPE NCC network but not externally. And again, it's something we need to improve. We have already improved the external monitoring of our e‑learning environment including checks for IPv4 and IPv6.
So, statistics for recently introduced features to Whois. The regular abuse‑c validation, we have now just have more than 92,000 abuse‑c addresses. We have 19,000 left to be validated for this year. But given the statistics so far we are on track to complete validation of all abuse‑c for this year.
Secondly, the RPKI non‑auth route and clean‑up, we deleted 75 route objects since the last RIPE meeting and related to that unregistered prefix clean‑up, we deleted 13 route objects since the last meeting. The numbers are small but these two clean‑up jobs are automated and the uptake of RPKI these numbers would only increase.
For NWI‑8, which is to synchronise the LIR portal users to the default maintainer in the RIPE Database, we have just over 1,600 LIR organisations using that, which is 23% more than the last RIPE meeting and finally the NWI‑9, which is to open the NRTM service we have 272 distinct client attributes which 34% more than the last RIPE meeting, so it's good to see there is more clients using the service.
To clean ups since the last RIPE meeting. Firstly, to clean up locked PERSON objects, which is an ongoing process. We have now re‑‑ we have updated just over 100 persons which were locked by the RIPE NCC lock maintainer. There are persons that are referenced by maintainers or resources of the early registration project. So there is just over 12,000 locked persons remaining, which are locked by the RIPE NCC. So, we will continue to look into reassigning the maintainer for those.
And secondly, we now removed Whois tags. This is a beta feature and it had roughly 2.5 million records in the database, which identified either user or registry resource, but it hadn't been updated in years and it was very low use, to we have now removed it completely in the latest Whois release and the associated data.
Operational work: We are replacing our on premise metal servers. Some of these servers are vintage 2013, so they are well due for retirement. We will have new servers, multiple servers in multiple data centres for resiliency. We are containerising and upgrading or rebelcation manager. This is software depending on switchover and failover of the.primarily database in production and we have been doing in regularly in production with no side effects. So it's ‑‑ we are more confident in the use of this application. We can relying on it.
Finally, we're doing a lot of configuration management work. We're switching the engine that we use for configuration management and we're just about finished with that, the last environment to do that now is production.
Our web application. So we plan now to make our web application open source. There is two main reasons for that. The code will be public. So ‑‑ and there will be a permissive licence. We want to, our community to reuse our code to contribute to improvements and make bug reports like they already do with the Whois application. And secondly, we want to do development in the open. So, the community can follow progress on our new features, see what we're working on
TORE ANDERSON: See when things get fixed.
We now notify users when the RIPE NCC access session times out in the browser. Which you didn't know about before and this caused some confusion and bugs, where an update in Whois would fail and you wouldn't know why, and related to that notification, we also now notify when a new release is available and ask the user to reload the page to pick up the new changes.
We have also enabled HTTP/2. It's something that have made much easier by our switch to the load balancers and dropping the proxy servers. So HTTP/2 is now enabled in all environments.
And finally with plain text option is now also visible in the web application. So, if you go to the query page and make a query, you will see one of the thing is a plain text so you now don't have to go to port 43 to get a plain text response from Whois.
White pages: In March, the Working Group asked us to deprecate white pages because it wasn't being used. Since the last RIPE meeting, we have now deleted the white pages organisation, we have cleaned up the documentation. We have contacted the four affected persons and we have also excluded them now from deletion so they won't be affected. However, this exclusion process is, there is no defined purpose for doing this, we have facilitated it for operation reasons because users sometimes do want their persons deleted even though they are unreferenced, and we have seen there are some reasons for keeping your person object such as it's used as an Atlas anchor, it's used an a domain registry contact. There are consultants using PERSON objects when they are working with LIRs, they use their own person for contact information. But we need to know whether these usage are in accordance with the purpose of the RIPE Database and right now there is no purpose for doing this. So, this is something that needs to be discussed more with the Working Group.
Default maintainer. As I said at the last RIPE meeting, there were inconsistencies with the default maintainer feature. But now, the user maintainer now all LIR organisations do have one and only one user maintainer on the organisation, so it's not consistent. We're now also setting the default maintainer on all top level allocations and assignments. So this includes legacy with a contact with the RIPE NCC assigned PI and assigned Anycast resources.
Previously it was only assignments allocations excuse multiplexer and also it's covering aut‑num objects. With we're also setting the default maintainer by default on transfers. That wasn't the case before. So now by default your maintainer will be the default maintainer on your organisation. We're now also stopping synchronisation when an LIR is closed. And that was causing problems for users because they couldn't resynchronise with the different organisation, so that's now fixed.
We're doing weekly consistency checks to see where there is a consistency between an organise's default maintainer and their resources.
And finally since we have made all these improvements, should we apply this change to existing resources? This is something that would have I think quite a big impact because there are a lot of resources who don't have a default maintainer right now so this is something for discussion with the Working Group.
RIPE Database documentation. This is ongoing since the last RIPE meeting, we have now migrationed all the main RIPE Database documentation to its own website which is linked from the web application. On the left hand menu you'll have a new link that says documentation and you can go straight from there. It's a really big improvement for us for the database team. We have ‑‑ it maintains the data a lot easier. We have an open source repository where we store the documentation. For users there is a consistent UI across the RIPE NCC now like RIPEstat documentation, and RIPE Atlas, they will look the same as the RIPE Database documentation. There is built in search facility, examples in the text are live examples, make an API line call for example. It's easier for us to keep the text updated and we can align code changes with documentation changes and apply them simultaneous.
In progress, there is a large DB support area on the main website and we're going document by document right now. As we move documentation from ripe.net to the web application, we are redirecting the old location and we are cleaning up the text as we go as well. So that's ongoing work.
Our RDAP service, so we're extending our RDAP implementation using two profiles, Cidr‑0 and NRO. Those are across our RIR efforts to increase the consistency in the RDAP service, so the response from one RIR will look versus the response from the other RIRs, we have already added the Cidr‑0 profile in the last Whois release and there is some ongoing work to implement the features implemented in the NRO profile.
Numbered work items. So as more detail from William's presentation. For NWI‑4, so we are working on an impact analysis for NII4. So, that's broken into three parts. For the RIPE NCC. So firstly for registry services, there is two primary things that the registry service told us about this proposal. First is that there is the policy proposal 2022‑02 on the assignment requirement. That can have an impact on this numbered work items, so they suggest that we wait and see the outcome of that proposal first before giving an any of response on the impact analysis.
Secondly one draw back of this combined status in single object is that an LIR and an end user, they can't share the same object. So the object will be co‑maintained by the RIPE NCC and the LIR, but the end user won't be able to make changes, so they are text see the contact details, their maintainer won't be on the object, so it will be for the LIR to maintain the object.
And that could be a major, a drawback of doing this.
Secondly, the second area is for the RIPE Database, so the DB team did look at the impact of this proposal on the RIPE Database itself and Whois. And we concluded there is a lower impact. There is ‑‑ we will need to allow the user to switch between allocated PA and allocated assigned PA. That's a change because up to now its status has been mutable, you can't normally change it but now you'll be able to change it back and forth. And second, we will need to update our business rules where it affects an allocation or assignment. But I didn't find anywhere where an allocation and assignment rules are in conflict, so we will be able to extend the business rules to take this new status into account.
And finally, the internal registry, there is no impact on the internal registry software. The internal registry software does read in right to the RIPE Database, but they don't change the status value.
So, NWI‑10, definition of country. So we have made some progress since the last RIPE meeting, the country code data is now complete and available for 99.3% of nearly 20,000 end‑user organisations in the RIPE Database, so, rather than waiting for the data to be absolutely 100% complete and for the software changes to be complete we are going to publish what we have next Monday the 31st October, we're going to put the country code for end‑user organisations into the RIPE Database. So we'll notify the Database Working Group as well.
And additionally, from next Monday, a newly issued resources will have the organisation country code as well. And in progress registry services are working on the data for the remaining end‑user organisations, and the internal registry software changes are in progress right now, for example the internal registry database, delegated stats, that work is ongoing and we expect it will be finished by the end of this year.
And with the latest Whois release, additionally the country code is now editable in organisations without a code change resources, so if you don't have any resources assigned or allocated by the RIPE NCC, you'll be able to maintain the country code yourself.
So, finally, NWI‑12, NRTM version 4, the database team contributed to the NRTM version 4 draft RFC document and thank you to the co‑authors, Sascha, Job Snijders and Stavaros. So we now have more complete understanding of the draft RFC document and we have already started work on a service at implementation. So, we can put the RFC into use.
Upcoming changes: So, there is a bunch of upcoming changes, things we're already expected to be working on. As I mentioned in W I 10, country code, we'll doing that population on Monday, and also the service at implementation for NRTM version 4. Protecting references to objects in the RIPE Database, so I need to publish an impact analysis for that. The search UI, we completed Phase 1 of the search UI changes to the query page and remaining work is to integrate changes for full text search and to open our full text search API as well to end users. Currently the API is only used by the web application.
Client certificate authentication. This is something that's been on our list for quite a while. We had a demo in our test version... for a while but when we dropped or proxy servers and went to load balancer setup, we also lost the client certificate configuration that we had. So, we want to now go back and enable that in all environments so users will be able to use client certificates to authenticate updates in the RIPE Database RIPE Database.
And finally as I mentioned at the last RIPE meeting, resoaring missing history. There is roughly 23,000 objects in the RIPE Database that has some missing history. This affects the history lookups in the RIPE Database. And it's something that we want to do something about and restore missing data in the coming months.
That wraps up my presentation. Thanks very much for your attention. Any questions?
.
(Applause)
WILLIAM SYLVESTER: Any questions?
AUDIENCE SPEAKER: Hi Ed, Stavaros from AMS‑IX, thank you for the update. I have a question regarding NW ‑‑ NRTM 4, are you going to do the something implementation of course. Do you think it's useful for the RIPE NCC to code the prototype on the client side as well to help the adoption or do you think it's something completely out of scope?
ED SHRYANE: I am hoping we won't have to because it will increase the scope for us a lot more. But it's if necessary and the community find it useful we'll spend extra time to do that but right now it's not a priority. I am hoping to do work on the client side separately r I think it will be healthier to have a different team doing the client side to the server side I think it would mean a more robust implementation.
AUDIENCE SPEAKER: Okay. Thank you.
WILLIAM SYLVESTER: Anyone else? Great. Thank you Ed.
So, up next we have geofeed, and the geofeed discussion. This has been a long intense discussion. There seems to be consensus, that geolocation is a purpose. In fact geolocation has been something that the database has been used for pretty much since its inception, but without clear purpose there is limits that are needed. RIPE NCC limits by prefix length or status is not acceptable by the community.
GDPR needs dedicated specific purposes for processing personal data. Old style generalised catchall purposes are not sufficient. Facilitating coordination between network operators for agreed operational purpose it is very vague.
That last one has been around since forever, and I think that no one can actually describe what it means.
But operational purpose it is what we're all here for.
So as we look for a new purpose. First, does anybody in here use geofeeds currently? Raise their hands. A couple. Okay. So we need to focus on geolocation specifically, and agree on the wording for a dedicated defined purpose of the database, of course we are always looking for volunteers, someone to update the purposes. The question is, there is a lot of different options in regards to how we might go about doing this, whether it's an update to terms of service, whether it's an update to the purpose of the database, whether there is other options out there that we might have in order to sort of accomplish all of other goals of bringing together both the technical, the legal, and ultimately the end user and operational aspects of how we use this.
So, update purposes. What does that look like? Well we have never really done it before. I think the original terms of service were drafted by RIPE NCC, put out to the community and the community didn't really comment on it.
You know, the terms and conditions are a legal document, that's a RIPE NCC document. The Database Working Group consensus is sufficient for NCC to update it, as it's covered by article 8. You know, the question is is this needed to policy? Are there other aspects to consider, like does the Executive Board need to chime in on this, or are there other considerations that are out there?
.
So, any questions? Any comments? Anyone using geofeed?
NIALL O'REILLY: I'm not going to talk about geofeed itself but rather about the question of adding a purpose. It seems to me that you can ‑‑ you have a lot of discretion here about how lightly you want to do this. You could suggest a text to the RIPE NCC after forming a consensus on what that should be, and simply make it another NWI at the light end of the scale. Or you could use the PDP, and I think it's up to you ‑‑ it's up to the co‑chairs of the Working Group to decide which they'd prefer, and to get the Working Group to endorse that approach by consensus. I'm not headed towards either the lightweight or the heavy weight approach.
AUDIENCE SPEAKER: Shane Kerr. So, I think instinctively we try to avoid heavy processes, but the PDP does have advantages in that it let's you know exactly where you're at at every stage, and there is like specific points where you call on certain types of feedbacks and things like that. So, if you are not in a hurry, I think the PDP is a fine way to do it. You don't need to only use it for policy ‑‑ or for like official RIPE policies, you can use it for anything.
WILLIAM SYLVESTER: What would you say about the geofeed aspects in regards to being a purpose of the database and/or, you know, taking that as an incremental step?
SHANE KERR: So... my own feelings about this are that there are a lot of things which are currently part of the database which shouldn't be as tightly coupled as they are and my own feeling, and I think I mentioned this in the database task force requirements at some point, is that I think the real goal should be to make it easy for these purposes which are very closely aligned with the RIPE Database, to be able to sync and coordinate with them so that a separate database of geo IP information that was linked to changes and allocations and assignments and things like that, would be able to receive events effectively and follow the updates in the RIPE Database. So, that doesn't really answer your question, unfortunately. So I think I think from a strict definition, if I was very concerned about privacy, my own feeling is that it shouldn't be part of the database, but it's almost impossible to run such a system without knowing in great detail in realtime what's going on with the RIPE database, I don't know if that makes any sense, so...
I mean, honestly, I have a similar feeling about the routing information in the database, right. Routing information doesn't have to be in the database. It's put there because it's convenient. And it's very tightly coupled, but the coupling is one way, right, so the routing system needs to know the assignments ‑‑ well in principle it needs to know the assignments and what's going on with the allocation, but like, transferring of addresses doesn't matter who is routing it or things like that. Maybe an external pre‑check or something, so...
.
I know you have muddied the water and I apologise.
WILLIAM SYLVESTER: Thank you.
AUDIENCE SPEAKER: Erik Bais. On purpose, I think it is up to the Chairs to select which process to use here. I think NWI is probably easier to get things going faster. For that, having the geofeed info in the database where it is, it's helpful. So, yeah...
WILLIAM SYLVESTER: Anyone else? Great. I guess we'll go to the main event now.
And jump into our 2022‑01 personal data in the RIPE Database.
So, just to be clear this is not my proposal, unfortunately Denis of unable to be here today. I was really hoping a couple of other people were here, but I guess that will keep the fireworks down.
So, Denis's original policy draft covered privacy issues for contacts and resource holders, and then ultimately verification of those contact details. Over the summer, there were discussions in three separate areas: Contacts, resource holders and verification. Each of these had certain support and/or objections, there was no real consensus on the general sense, there is a lot of human nature that seems to be TTL positive aspects get overlooked as the negativity comes to light and a lot of people are more vocal on the things they object to than the things that they support. Within this community, there is no exceptions, you know, vocal group will shout from the roof tops for the things that they hate while everyone else is sitting in the basement quite he will working.
As we look back we had policy discussions follow the same pattern. Not to dwell on this too much, but the idea here is to bring new ideas and different things to the table and to have it considered and to get input from everyone.
So, let's talk about the scope. Clearly, scope is probably set too wide on this policy to start with. We need it extended, discussion periods, we had a longer period for impact analysis, and we're going to need to extend, you know, review periods. There is a message here: If we reel the scope in and focus this a little bit more during the PDP stages, as we have progressed it seems that there is an interest in dropping verification, focusing directly on privacy, maybe consider verification at a later date but maybe probably not. You know, the process allows for revisions to the policy and the impact analysis, but for now, the intent is to remove verification references.
The intent of this policy was intended to be good. The intent was to identify ‑‑ I mean this started off several RIPE meetings ago where we identified there was a lot of personal data that had been put in. Somewhat of a housekeeping issue. Certain parties that were using some of the data and putting data in the database not necessarily in a way that it was intended. But within the policy and the way the policy is proposed, the wording is probably not really where we want to be. And, you know, there is several different views that have been on the mailing list, and I know there is just been some discussions here in the last 24 hours that I think are very helpful for those of you who are not up to date on this policy it might be useful for reading and understanding.
And please, bring your comments to the table.
But with that, let's open up the floor and hopefully have a good discussion on some of the privacy objects. Erik, I know you had some opinions.
ERIK BAIS: Yeah... for the record, Erik Bais, AWB Internet. I sat down with the author, Denis, this week, and also in the past time. The scope on this proposal is huge. And I think as my feedback, having done quite a lot of policy, you need to reduce this to, you know, bitable chunks. I think probably people might like one part, and flip over the other part and go nuts on it, because they think it's over reaching. And that way, it's really hard to get the people that support it to actually get them to support the whole policy. From that perspective, I would be a great support if the policy would be dropped, and if it was, you know, rewritten in smaller chunks and go back to the drawing Board.
I think it was a very helpful discussion and I applaud Denis for the work that he has done. This was not an easy task. He has done a lot of work on this. But from this point, I think there is, you know, quite some negative feelings on this proposal as a whole, and instead of rewriting it for version 3 or 4 or 5, I would say drop 2022‑01 and, you know, start in smaller portions again. That would be my feedback.
WILLIAM SYLVESTER: Thank you. And just to be clear, the original intent as Denis has described it to me was that we could transition from having personal information to having more sort of corporate or operational information in the database and somewhere that got lost in translation through some of his proposals where I think that there was definitely some folks who thought that he wanted to do away with, you know, all contact data or something along those lines. Which wasn't necessarily the original intent, although it's easy to sort of think that just in a review of some of the drafts.
Any other thoughts, comments, feedback? Anyone have any other opinions?
AUDIENCE SPEAKER: Niall O'Reilly. I just want to echo Erik's words of thanks to Denis for opening this bag of worms, and to suggest that if this is withdrawn, we shouldn't regard it as a failure, we should regard it as a job well done and we should come back to taking the meal in small tap as sized chunks rather than 2 pounds of steak.
WILLIAM SYLVESTER: Well thank you. I here that we should be eating the elephant one bite at a time versus trying to eat it all at once.
Cool. So seeing no other questions or concerns, we'll take this back to the mailing list which is where we conduct all of our business and from there we will continue to iterate. With that, is there any other business anyone wants to bring up to the mic. Anything that's of concern database related, any of the things we have talked about today?
.
We are running way ahead of schedule.
ERIK BAIS: Well, you know, as we're having time to spare anyway, how are we doing on the assignment size for the same size for the allocation, specifically for the /24s that have been assigned?
WILLIAM SYLVESTER: In regards to what?
ERIK BAIS: So, most likely, I am not sure if that's still online. There is the issue that you can't assign a ‑‑ the equal size assignment as the allocation in the database because the database doesn't allow that. I know there was some discussion on that in the past. I am not sure what the status is currently. So, and as we have sometime ‑‑
WILLIAM SYLVESTER: Networks we have sometime.
ERIK BAIS: I am not sure if Ed is still around.
ED SHRYANE:
ERIK BAIS: Did you hear the question?
ED SHRYANE: Yes, sorry I did. Can I see my presentation? So I covered this in the presentation. The NWI‑4, the impact analysis is ongoing, so it's in three parts ‑‑ okay. Our analysis is in three parts. Registry services feedback, RIPE Database business DB team and the internal registry, so the RIPE Database and internal registry has low impact and no impact and the feedback from registry services, this is just waiting for the outcome of the 2022‑02 proposal and secondly, this proposal means we have ‑‑ we will create a multi‑valued single status attribute combining both the allocation and the assignment but the biggest draw back with that is since you are combining that in one object, the object will continue to be co‑maintained by the RIPE NCC and the LIR, and not the end user. So, the end user will not be able to share the object. That's the biggest draw back so far.
So that's where we are with the impact analysis, and I can publish the details of what we have found so far if that would be helpful.
The alternative proposal that was proposed I think last year was to use a tuple. So you identify the nomenclature resource using the status and the prefix, so, similar to (aut‑num) Route‑6 and disc it can be an advantage. You can have multiple objects maintained by different maintainers but the issue is you have the same prefix with multiple objects so there will be more client side changes needed for it.
So those two competing proposals are on the table, but the impact analysis is on the multivalued status.
ERIK BAIS: Okay. When can we expect the impact analysis to be finalised?
ED SHRYANE: Well I can publish what we have if that would be useful. But the only question mark is over the impact of the 2022‑02 policy proposal, whether there will be any impact on this change.
ERIK BAIS: Okay. All right. ‑‑
ED SHRYANE: I will publish what we have then on the Database Working Group list.
ERIK BAIS: All right. Thanks.
WILLIAM SYLVESTER: Thank you. Any other business? So, who wants to be a new Chair? Don't everybody raise your hands at one. All right, well seeing no other business, I guess we're going to get to coffee break much earlier than we anticipated. If anyone has any questions about any of the policies we have talked about, I am always available to discuss or Denis as well, feel free to reach out to us, either on the mailing list or directly. We'll take everything we have talked about to the mailing list. Hopefully everyone can engage with that.
One other question I have is for everyone in here, who is not subscribed to the mailing list? Raise their hands. We have got a couple here, a couple down there. Is that because you guys aren't interested in the database or you don't use the database? Is this the Cooperation Working Group? I was wondering where the RPKI presentation was, and Rudiger, Rudiger went to RPKI today. Who knew? Well...
.
No, I mean, for this Working Group, and I know a lot of Working Groups struggle with this and since we have sometime it might be helpful to consider some of these questions of, you know, is it everyone is busy so therefore you are not using mail? Is it that you prefer other platforms than will mail? I know as a Chair collector we were talking through some of these issues in regards to some of these things and it would be just be interesting to have additional feedback if there are better ways that we can either communicate or push things out and to engage. Ultimately historically we have had people who everyday in their jobs used the database that we're definitely very interested in how they interacted with the database or how they didn't want the database to change with the way that they interacted. How the database data was updated or maintained in a certain way that helped or eased certain aspects. Shane?
SHANE KERR: I mean it's not weird, different types of communication have different characteristics, right. In the past the Database Working Group has created task force around specific things and I think the main advantage of that is you get people in a room talking together which of course wasn't possible during Covid. I don't know that there is a good answer. Basically, I think that if you are going to have a discussion where people are trying to figure out where they stand and come to a consensus around like ideas, like medium sized mails, not too many is going to be something that people are going to be willing to read, right? However, if ‑‑ for high speed communication like this, that's not a good place for the mailing list. So ‑‑ and also, although historically we have done it because there hasn't been any other options, reviewing very long highly detailed discussions is hard on a mailing list and honestly, if I see a six‑page mail come, even if I'm highly motivate and very interested and totally respect the person who wrote it. I'm going to put it in to do later, right, and I may have time set aside for that but something may come up and it's going to be hard to find that. That's not to say that we shouldn't have highly detailed documents which go over lots of things. I just don't ‑‑ I don't know that you are going to ‑‑ I think it makes ‑‑ I think it adds a challenge to the whole discussion and I don't know a good way to do that. There are other ways to review documents. It turned out that companies have developed these, open source have developed these, so... maybe the right way to do it is to try to direct conversation temporarily away from the list and then back. I don't know. I don't know.
WILLIAM SYLVESTER: Which device would you read that six page document on? Would you read it on your phone or tablet, or would you save it for later for your computer and would you actually sit in front of your computer later to read it?
SHANE KERR: I don't follow mailing lists discussions on my phone. So, I would always read that on a laptop, so that wouldn't be a hurdle one way or the other.
WILLIAM SYLVESTER: Anyone else have any feedback?
.
Well, seeing none, I guess we have a coffee coming soon.
Just a thank you again to the RIPE NCC, they jumped in and helped out today, especially with Denis being out, the workload was a little high today. And thank you top scribe and transcription. For all your help we appreciate everything you do, thank you. Other than that, we will see you next time, I guess that's Rotterdam, right? Thank you so much. Take care.
(Applause)
.
(Coffee break)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
