Database Working Group session
26 May 2016
2 p.m.
CHAIR: Hello Working Group. If you will return to your seats, we'll get started.
Welcome to the Database Working Group session at RIPE 72. I appreciate all of you spending your time in this session and helping us guide the database into the future. Like last year, we're going to try really hard to stay on schedule, so do not be offended if we waive the papers and say you need to stop talking, it's just so we can be on time.
I'm going to appoint Nigel as our volunteer to take notes.
The agenda: You are view it online at the RIPE 72 website. Oh, there we are.
So, this is our agenda. Unless there are objections, we will proceed as it's presented here. I would like to invite Nigel to review or minutes from the previous meetings and review the action items. Sorry, I would like to invite Nigel for the approval of the minutes from the previous meeting, and the action items.
NIGEL TITLEY: Good afternoon. As usual the minutes were circulated I think within about five minutes of the end of the Working Group session last time. I have had no comments on the list. Oh, one comment actually I had, which was that I had actually put it down as the RIPE 72 minutes rather than the RIPE 71 minutes. So, I'm assuming that the minutes were acceptable? Does anyone have problems with that? Tim?
AUDIENCE SPEAKER: I have one slight remark. I think Wilfried made comments on the RFC set of the R P sell and not RPKI, that is overtaken by events.
NIGEL TITLEY: Right. Okay. We'll update the minutes for that. A from that, is everyone happy? Yes, okay, in which case the minutes are approved. And I will go onto the next item, which is the action point roundup.
This will be the last time I will give this because we are actually abolishing the action point system and turning it into a work item system, which Job will talk about shortly. But anyway let's go through the action point roundup.
Action point 67 .5. Which was actually on the anti‑abuse Working Group, is to check that this Working Group has properly specified both what should be done with mail that is sent to the abuse contact and possibly its format. I understand they are working on this? Brian?
BRIAN NISBET: Yes, we are. It is harder than it looked to begin with. But, conversations have started, certainly, so, there may well be a bigger answer in October. But, yes, that process has started. We will report back to the group. There's a certain amount of nailing down actual requirements rather than what I thought there were.
NIGEL TITLEY: Lovely. So this one is ongoing. But I guess what we will do is close it in this group and it will come back to us from anti‑abuse. Right.
Okay. 67.2, RIPE NCC, come up strawman proposals for displaying history for objects where available.
AUDIENCE SPEAKER: Tim: Job will talk about the work item process in a bit, but this has become a work item so we can define the statement and move forward from there.
NIGEL TITLEY: This has become a work item.
67.3. This is also on the RIPE NCC. To examine and report on possible solutions to improving geolocation data.
AUDIENCE SPEAKER: Tim: On that, I sent a reply to the list yesterday referring to a statement that we are not spending further resources on this at this time.
NIGEL TITLEY: Basically we're closing this as overtaken by events. Okay.
Okay. 70.1. This is on all of us to discuss deprecation of plain text passwords in e‑mail.
I don't recall seeing anything much about this on the mailing list. Do either of my other two co‑chairs know anything about that or did they notice anything
JOB SNIJDERS: I would suggest that for this action point to proceed, somebody needs to step up and submit a problem statement to be chairs. If that does not happen, then the item is closed. If that happens ‑‑
NIGEL TITLEY: Okay. That sounds fine to me. If somebody would like to pick that up. Oh, Tim is standing up.
AUDIENCE SPEAKER: At this moment: If nobody else volunteers we can make a problem statement.
NIGEL TITLEY: We'll convert this into a problem statement. Thank you.
AUDIENCE SPEAKER: At this moment: 70.2. Yes, also for that one, a problem statement was created and sent to the list yesterday, I believe, so ‑‑
NIGEL TITLEY: This one is converted as well. Okay, excellent.
71.1. Wilfried. To organ effort to look at the fact that the original RFC set in RPKI has been overtaken by events and should be examined.
Is Wilfried here? No. Okay. So, we'll chase this up with Wilfried off line I think.
AUDIENCE SPEAKER: Tim: I believe Wilfried was talking about the RFC set for RPSL, not RPKI.
NIGEL TITLEY: My apologies. This is incorrectly put down. He is absolutely right. Yes, so this is an incorrectly recorded action point but it still needs following up. So, I think we will chase it with Wilfried off line I suspect.
71.2. Marco, Erik, Job and Tim to work on a method of cross authentication of aut‑num, possibly involving RPKI.
Is this turning into an action item as well, a work item as well?
JOB SNIJDERS: I think this action point should be closed as it's overtaken by events. ARIN submitted for instance a proposal to the Services Working Group. There is a number work item related to forum route objects, so some effort in this problem space is being done, but this particular one, as it is stated, should be closed.
NIGEL TITLEY: Okay. That sounds fine. So that basically has turned into an action on the NCC Services Working Group, and also a work item for database. So that's fine as well. This one is covered.
And that looks like the end. Yes, okay. Thank you very much everyone. Job are you taking over now?
JOB SNIJDERS: Numbered work items. I have been a Chair for a little bit more than a year now, and one of my observations, and my co‑chairs share that insight, has been that getting things done in the Database Working Group previously could be a little bit of a challenge because there was some unclarity to how the process works to get something done. To address that concern, to provide people with a framework of this is the process to follow to get something done in the Database Working Group, we introduced this concept of numbered work items.
The process starts with the kick start. You can e‑mail the Database Working Group chairs with some text, preferably something that is already a problem statement itself, but you can also just e‑mail us with concerns you have or vague test in that regard, and we'll help to you refine it as a problem statement, something that is attackable with solutions. And when you do so, the chairs have the option to say yes, we'll convert this into a work item, or no. If we say yes, we'll assign a number and we'll distribute it to the mailing list saying hey guys, here is a problem statement, and then we get into ‑‑ that is Phase 1. The problem statement phase, where we search for consensus on whether there is a problem, and whether that problem is defined correctly.
The outcome of Phase 1 should be something that solutions can be defined for. So, we really should strife to make these problem statements tangible, not old traffic or over arching in scope. Small steps is, I think, what this group prefers in the process development, and having defining small problems or tangible problems will help us succeed in that regard.
So if in Phase 1 we agree this is a problem, then we go to Phase 2.
Solution definition:
In this phase, people can voice solutions that resolve what was addressed in the problem statement. And it is really important that people distinguish that there is a separation between agreeing on the problem and agreeing on solutions. Often these two were mixed in the past and as chairs, we think that by separating the two, will make it easier for people to cooperate on concerns.
When we go through the solution phase ‑‑ we have not yet successfully done so because this process is very new, so next meeting we can evaluate if this actually works for the work item to proceed to Phase 3, one of the final steps would be that RIPE NCC staff summarises towards the mailing list what their understanding of a solution is. So there's a feedback loop in which the RIPE NCC ‑‑ part of the final outcome is that they have to state to the Working Group what their understanding is, and we need to agree that that indeed is what we propose as solutions.
And then Phase 3, after a solution has been defined and agreed upon, is the deployment phase. RIPE NCC will then write code or plan to write code and it will be deployed in a certain timeline that is agreeable by our community.
And once it's been deployed in production, we have reached the finish line.
In all the number of work items I sent yesterday, I made reference to the original e‑mail that stipulates how this process is supposed to work and I really encourage you as a group to try and follow the process. Do not mix problems and solutions. And going from there, I really hope that our Working Group becomes effective and a channelised force of energy that pro Pels the database into the future.
Are there comments, remarks, questions?
AUDIENCE SPEAKER: Ruediger Volk. If nobody else...
So, first question: Do we already have a website that has the process definition and that will actually provide overview of the active work items and their status?
JOB SNIJDERS: At this moment, we do not, but it is certainly our intention to publically list it where there is a link where it says this number, this topic, with background information. (Publicly). Another aspect that I failed to mention is, on a monthly basis we want to send reminders to the list that these are active work items, who is responsible for the next phase, what outcome are we still waiting for and...
RUDIGER VOLK: So, kind of, I hear there is the intention, but I do not hear that there is actually a specific plan.
JOB SNIJDERS: Starting June 1st, it will be published. And June 1st you'll get the first reminder that says which are the active work items. Is that okay?
RUDIGER VOLK: Okay.
JOB SNIJDERS: Five days from now.
RUDIGER VOLK: I'll wait and see. The next question is, the phases of the process are explained. Deposit we need and should we actually a little bit more (do) explicit of what is done process wise to finish a phase, like, well, okay, what I would see is actually a phase transition cannot can you remember and consensus cannot be called (occur) unless there has been a very clear statement what the assumed outcome is. Say resolution definition, and time to actually review this.
JOB SNIJDERS: So for the first phase we have set a limit of a few weeks. The second phase, from the top of my head, does not have a time limit but my personal expectation would be in the line of two or three months.
RUDIGER VOLK: Okay. Kind of what I would suspect is that the parts of the phases where discussion happens is probably hard to say, well, okay, it always has to be done in three months.
JOB SNIJDERS: Correct.
RUDIGER VOLK: And it doesn't make sense to try to set up rules for that.
JOB SNIJDERS: So we haven't done that for that phase.
RUDIGER VOLK: Yeah, yeah, but for kind of terminating a phase, I understand that consensus will be called and I think it is a good idea to explicitly make clear that well, okay, the proposal for the consensus is clearly put out. Last call is done. We should know how much time, two, three, four weeks, and then of course is question is, for the chairs or whatever you define, to check whether the response actually is against sess or not. And I think, kind of a timeline and well, okay, both parts in the process, the small parts are really needed I think should be clearly defined.
JOB SNIJDERS: Thank you for your feedback. I'm willing to review the current approach once we have been through it a little bit and then we can reflect on whether things are working for us or not. But the things you remarked, I agree with a great many of them.
We're up for our next agenda item. Who is next? Hans Petter, please welcome the Chair of RIPE.
HANS PETTER HOLEN: Thank you. I have been ‑‑
AUDIENCE SPEAKER: One moment, I missed a comment from the chat. Can I still say that?
JOB SNIJDERS: No.
HANS PETTER HOLEN: Another acronym. PSWG. Some of us frequent ICANN meetings a bit, and they set up a public safety Working Group and that was actually set up by the Government advisory committee, so it's kind of an interesting creature. What they focus on is needs from the law enforcement but also on consumer protection, so it's not just one topic. Into the the WHOIS services and since it's in ICANN, you may think it's just domain names, it's not really because they started to look a bit on how do we do this in the, for the IP addresses, for the numbers. So there was a workshop at the last ICANN meeting, I was not at the ICANN 55, I was not part of that but there was a workshop between the RIRs and this Working Group to better sort of understand or to make this Working Group understand how the RIR WHOIS databases work and what data is there and so on. And one of the things that's coming up and that was actually already a theme for two presentations in the anti‑abuse Working Group is the accuracy of the data in the databases. So from our friends in law enforcement, it's clear that if there is some crime, for instance, Crypto locker being distributed and you figure out that the keys so this is on this server with this IP address, you want to find that server, right, and that's kind of the challenge on a high level here.
And we just had a presentation on the challenges with that. So, the outcomes of this workshop was that the RIR policy development process was explained, and all the members have been invited to participate in our meetings, and in our policy development process discussions. So, don't be afraid that we will see new participants in this Working Group, because there are other users than just the network operators and the data on it for the data that's in there.
And it's also been identified that there is a need for more capacity building, we need to teach the rest of the world how this thing really works, because there are lots of assumptions on the data in there.
Now one that I think that I find is very interesting that there isn't really just the database. In our RIPE database, as we talk about, as one database, we have a lot of different data sets and there are a lot of different entities responsible for the quality of those data sets and that's not really clear when you look at how we talk about this and how we ‑‑ and looking at the interface. And why do I say this? We have 13 and a half thousand members of the RIPE NCC, and they are responsible for maintaining their objects.
So, RIPE NCC is really just a data processor, but the responsible for the content of those objects is with the LIR. So, this is kind of some of the challenges that we are facing moving forward. How do we educate the world around us, who is responsible for what and how can we increase the data quality on the database?
Can that be done through user experience, or how do we do that? And that's kind of an open question to this Working Group, I just sort of threw this out here. If you want to know more about this, we have a colleague from the RIPE NCC, Richard lending, and Gegory Munier is here from Europol, I'm sure they are interested in engaging us with. Since they showed me the five minutes sign, I'd like to spend the remaining five minutes for any thoughts or questions on this. So go ahead.
AUDIENCE SPEAKER: Tim from the RIPE NCC. I think maybe Alex will say something about that later, I don't know, but we have been doing a lot of work on the user interface recently, which I expect many incidental users of the database will use and we're also looking into ways there to make it more clear, I which attributes are managed by whom. I'm hoping that might help here.
AUDIENCE SPEAKER: Brian Nisbet. I think that this is a really important point and thank you very much for raising it. We have kind of had this going forwards and backwards for the last N years in regard to data, who is responsible for it, what we should do, and I think that the requirements from law enforcement and otherwise, they are only going to get more relevant. And I think that we, as a community, need to be aware of the fact that some of the reservation that is we have had, I have said this many times publicly before, some of the issues we have or reservations, we have got to get over them. You know, we can't just sit there and go, no, because for some special union corn reason, you know, I cannot have to do something or not provide that information. It's very difficult for the NCC, it's very difficult for the community to make LIRs do this, but it's so incredibly important. So, I think whenever we're thinking about this and whenever we're thinking about reasons why we, as LIRs, don't want to put certain data in there or improve the data or otherwise, then we really need to ask ourselves why we're doing that and what good actually comes out of that. Thank you.
AUDIENCE SPEAKER: Ruediger Volk. I was happy to hear Tim talking about marking attributes for classification of responsibility or other stuff is. I think that type of markup in the database output actually can serve purposes in the law enforcement thing and helping people understand actually the data better. But I also think for other of the current problems, we may find partial solutions there, like if the source attribute would tell, well, okay, this is an aut‑num that is out of the RIPE assigned pool or not. Or this is address space that belongs there or not. So, I would think that that should be actually one of the next work items.
AUDIENCE SPEAKER: Marco, RIPE NCC, external relations, he can could he go your request, we do engage with a lot of people outside of this room that are looking at the database itself. I think it needs a great step forward would be to indicate who is responsible for the actual maintenance and then you can be held accountable. That's not the only thing we face. We do, it's clearly stated in the anti‑abuse presentations, there is still a large gab in what we call capacity, which basically comes down to training people. And one of the things we also often bump into, that's not always exactly clear what is actually contained in Anna tribute. It says e‑mail or it says address and it's not actually clear whose address should be in there or whose e‑mail address should actually be referenced there. Is that some automated process that just looks at database notifications or is that actually a contact point? And echoing on Hans Petter's request, I would love to continue the discussion with the community and how we could make it more clear to other users what the meaning of certain attributes and certain objects in our databases are, because that's on a very big source of confusion.
AUDIENCE SPEAKER: Well, I think that's part of the problem here. This is Milton Mueller, I'm here from ARIN. You know, databases in the age of surveillance are not things to be taken lightly. So, one of the key principles of privacy protection is that databases have a purpose and if they are going to be used for beyond that purpose, you have to inform and get consent. Now if the purpose of your database is to facilitate the operation of the IP address space, then that's its purpose. It's not, you know, it may be convenient for certain users to transform that into other purposes, but that's not its purpose. And you know, these legal protections and procedures, procedural protections regarding access to data have been evolved over a long time, and it's very dangerous for technical communities that may not fully understand the civil rights and civil liberties implication to say simply say we can do this technically, let's just turn it over. Be very careful about doing that and be very mindful of the purpose of your database and the standards legal protections that go along with that.
HANS PETTER HOLEN: Thanks Milton. That was actually a nice queue to another presentation that I think about for another meeting. Namely what consequences does the new EU protection legislation have on the RIPE database.
AUDIENCE SPEAKER: Peter Koch, DENIC, I did something unusual. I tried to read the documentation, and I found a reference to the online RIPE NCC documentation, and since we have heard that we can't do things here and there because law enforcement is in necessity of accessing this, this is section 2.1.1, purpose of the RIPE NCC. I do not see any such requirement in there.
HANS PETTER HOLEN: I think the purpose that I would be referring to, without studying the text, is that law enforcement would have a legitimate reason to be able to ask the RIPE NCC who have they delegated a certain address blocks to, and that is what RIPE NCC is responsible for answering. Today, we also have who the LIRs have delegated to, and that's not the RIPE NCC's responsibility to keep updated. That's the LIR's responsibility. And I think in this chain here, there is a lot of interesting problems to look at. I mean Milton raised one of them, is this using it for another purpose that the data was there for? I personally wouldn't see too much of a problem that we actually continue to have publicly available who is, who the address space is allocated to but whether the assignments serve any purpose at all, if I want to provoke, that's actually a big question to me.
JOB SNIJDERS: Thank you. Next up is Tim Brunijnzeels from the RIPE NCC.
TIM BRUIJNZEELS: So, straight to the content. I am going to try to keep this brief but of course if there's questions at the end. We can discuss. First of all, I'm bringing this one up because it's becoming a bit of a tradition. We have an ongoing effort to get maintainers in the database to use the single sign on, well especially in our record dates, UI because that makes sense. And we see a lot of up take continuing. If you look at the graph, you see points where it goes steep err. The first one was already discussed at the last RIPE meeting. This was when we reset all passwords for which the hashes had been ‑‑ were about to become published. And well the second is an effort, Alex will talk more about in a minute, that's when we started requiring or making it also easier to use the SSO accounts in the user interface.
So, another item.
Unmaintained person and roles. Unfortunately we have a lot of personal role objects for historical reasons did not have a maintainer. Especially in these days of IPv4 runout, we consider this a big risk in terms of hijacks. And after talking to the Executive Board, a decision was made to lock all these objects to prevent the hijacks, but also I sent an e‑mail about this to the Working Group, that should definitely not stop us from discussing further. On the contrary, this still needs to be discussed, but in the meantime, these objects are locked to prevent hijacks. So there is no number of work item for this just yet, but probably there should be.
Then, the next issue. The restriction of the RIPE NCC RPSL maintainer. Later today in the session there will be a discussion about either router objects in general, but very specifically there was one thing that we could improve here, this maintainer was never intended to appear on MNT‑by objects. This would make it vulnerable for other people to delete or update. We attacked that problem specifically by introducing a business rule that prevents that that maintainer appears on M, it, it by and clearing up existing objects. Objects that had remaining other maintainers, well, still have them. In total, about 2 and a half thousand objects were locked. We have heard non complaints about this so far. Which may be because people tend to create these objects and then just leave them out there, which is a different problem, but just putting it here so you know there were some concerns about if people would be locked out of their objects, we did warn whoever we could warn like the contact data that was available, and we had no complaints. So, for reference.
So, the discussion is to be continued. But in the meantime, at least hijacking these objects is prevented.
Abuse‑C follow‑up. We have now added Abuse‑C to remaining organisations with resource allocated or assigned by the RIPE NCC. Particularly ASN holders, so aut‑num objects were not done properly when we last spoke about this. That's now resolved. I proposed a cleanup to the, I believe, to the anti‑abuse Working Group mailing list regarding this. That where organisation objects have an abuse mailbox attribute and also have an Abuse‑C attribute, we could spend an effort to clean up the abuse mailbox. The more general abuse mailbox cleanup was part of the plan, well from years ago, but my sense of the community is that there is some controversy about how that should be done, so, I think we may want to discuss that further before we take an extra action there.
Okay. The description cleanup. Probably fresh in the minds of some people. Because, well, we performed it at first after the proposal had reached consensus in this group. But, there were some problems with it. Sadly, we, and it wasn't us, we messed up the formatting and we did not inform NCC nodes as we should have. I'm sorry that that happened. On the plus side, routing was not affected as far as we know when we did this change, so, it's good to keep a bit, perspective on that as well. We have discussed this on the mailing list, and in the end, the conclusion was to do the cleanup again, but we will inform NCC again that we are doing this, and notify contacts that actually have a notify e‑mail on their objects. You this now planned for next week, Thursday, so...
Then, I think the last item on my list came up in the last weeks as well. There was a request to increase the daily DB, dump frequency, and I believe that the purpose of this is that it can help Miras build up their state more quickly. The problem with this on our end is currently the dumps take a long time because we have to go through the whole database so it's not quick, we would need to improve this with a smarter way of doing things, that would require serious effort. And our understanding until now that because of that explanation, there was no remaining urgency to do this, but that is incorrect, again I would suggest that we take it on as a numbered work item and see how we can meet the requirements.
So, that was all I had. And questions, comments welcome of course.
JOB SNIJDERS: On the last slide, I have a small comment myself, because I sent the original e‑mail. .what I wanted to say, if we see the database dump frequency, it seems that I am maybe the only one that has a desire for that feature. So just take it off your to do list. Scratch the request. I will not pursue it as a numbered work item. So, that's simple. Ruediger.
RUDIGER VOLK: Looking at the changes that you have been doing recently and remembering comments and short exchanges at the last meeting where I think job said well, okay, note that because we should do it, and I think it got lost. With removal of the changed attributes, the possibility for people to actually have some hints about who did something on the objects in the past have disappeared. ? Small organisation where is there is a single person that is managing stuff (in) that is only as far a pain as different organisations do not have the old way of telling their contact in that organisation that oh, we see your objects have been done by that e‑mail address, which also was useful. Of course, more for the large err organisations than the one person one. For large organisations, actually the number of persons that can do something legitimate on the database can be quite huge and the question of who did what actually can be very serious and important, and there is no other way at the moment than to establish local conventions that you put in some remark to trek this, and well, okay, actually having automatic recourse to what's in the database system for this actually works much better. So ‑‑
JOB SNIJDERS: If I cut you short. To summarise what you are lacking is I think an audit trail. I don't think it necessarily needs to be publicly viewable, but the way to progress this particular work item is, we need to define a problem statement, so, we could say, it is unclear who changed an object. And then we can proceed to an implementation.
RUDIGER VOLK: Okay, kind of what I brought up last time was that well, okay, there are these notification messages, and as far as the updates are caused by an e‑mail message the old school way, the notification actually tells the credentials of who did it. For all the online stuff, we only get cryptic IP addresses and I think at least in the notification messages to put in something that nice who did it and the notification messages are sent to people, not to the general public, I think that's the thing we discussed last time, and that got lost, and well, okay, by removing the changed and by moving lots of the interactions to SSO kind of the problem becomes more urgent. And ‑‑
JOB SNIJDERS: I appreciate that. Nigel has made a note that you and I will work together to formulate a problem statement and we should be able to send it out in two weeks. Thank you.
AUDIENCE SPEAKER: Hi, a comment from the chat. A question actually from Migel from AS31004. He would like to know, will there with a process to unlock person and roles objects? The follow‑up question. If and unlock is not possible, could I at least initialise immediate deletion and if I'm able to provide the necessary proof of my ownership.
TIM BRUIJNZEELS: So, we made a proposal for this. I think we should discuss it as a work item so that the problem statement is clear and we can have a structured discussion about it. But we did say initially that we were not planning on unlocking these objects because there are, from the top of my head, over 8 hundred thousand personal objects involved, and checking identity properly would introduce and unacceptable risk of getting that wrong. What we would propose instead is that people create new person objects and as soon as the old person object becomes unreferenced it's automatically deleted. But I would say in short let's discuss this on the list and see if that proposal or another proposal can reach consensus and then work on it.
JOB SNIJDERS: Thank you Tim. So next up is Tim.
TIM BRUIJNZEELS: All right. We spoke about this last time as well. We don't have to read all this. It's on the mailing list. But, essentially, I believe we reached a consensus earlier that in cases where route objects have an AS number and an INETNUM that are both let's say homed in AfriNIC, the Proxy‑Arp thing to do would be have those route objects appear in the AfriNIC IRR that has recently been introduced rather than the RIPE database IRR. So I sent that problem statement to the list. It would be good to see if we have agreement on that, and this goes maybe a bit against Job's process a reminder, we did talk about a proposal how to move forward earlier. Essentially it would consist of a communication step, get people to use the AfriNIC IRR, then stop accepting new things in our IRR and then in the end a cleanup. There were some comments last time so I think we should discuss this on the list to make sure that first of all we agree on the problem statement and then second, if that is quick, we can ‑‑ I can resend this to the list and okay that was our proposed solution, we can have a construct I have discussion about are we there yet with this or do we need to address certain concerns? At least that would be my proposal. But of course if there's questions and comments right now, then if the chairs want to allocate time to this, we can have a discussion.
JOB SNIJDERS: The numbered work item was e‑mailed out to the list yesterday. I would very much appreciate if the group voices their opinion and says agree or disagree, because if there is silence cannot proceed with this project. So, check your e‑mail and reply with your opinion. Thank you, Tim.
I would like to invite Alex Band from RIPE NCC to the stage.
ALEX BAND: Hi. I am he will axe band from the RIPE NCC. The product manager. RIPE NCC usability. We did get a lot in this area because as you saw in the update that Axel gave yesterday in the Services Working Group, we got a lot of new members, a lot. And we are confront with this RIPE database thing and I have also been a trainer for three years and I know how painful it can be to get people started in this whole using the RIPE database and using the different concepts. We have been putting a lot of effort into trying to make the RIPE database more usable. This is what I would like to talk about.
Using a bud word here because we're doing a data driven, instead of going around and asking people what do you find hard by using the RIPE database, we look at what people do and where they run into a problem. Because the kinds of things that you want to know is what kind of objects are being created? What method is being used to update the RIPE database? What kind of objects are the most error prone to create? And what can we do to take all of those hurdles away, what can we do to essentially make the database easier?
So what do you do? You analyse everything. We put analytics on every form, every button, every action you could essentially take within a RIPE database, we're analysing it. And the example that I want to give you in this presentation is essentially the error messages that users are confronted with. This is the top 10 and I made this top 10 for just this month. So this is in May.
Out of all of the people who tried to create a domain object, that went wrong 43015 times this month, using only the web interface. So, this is regardless of e‑mail updates, regardless of synchronous updates. Just using web updates, 43015 times just this month. It's like shocking. Shocking what people are doing in order to try to create ‑‑ setting out reverse DNS is just notoriously hard. I knew it was error prone but I didn't know it was this bad. At number 2, INET NUMs. I want to go into this rather than domain objects, because set something out reverse DNS is actually kind of a complex process that also involves the reverse delegation checker and essentially a piece of software that is not maintained just by the RIPE database, but there's also another department involved. So, solving that is a little bit harder. Let's see what we can do in order to make the creation of INET NUMs a little bit easier.
What are people doing there? The most common thing that happened 251 times this month, up until a couple of hours ago, when I created this, missing the required org attribute. You go that's weird, so people are creating an INET NUM and as the error message they get it is missing the required org attribute. Wait a minute the org attribute is only required when you create an INET NUM with a status allocated PA. So, people are just going I don't know, I have to select a status. Let's select the first one in the list. Allocated PA. And then they go try. And they get two errors, two for the price of one. First they go no, no, no, allocated PA is not allowed here and also by the way you missed the required org an attribute the. So that's one thing that's happening. The other thing, you see it in the top three, people select a range, and then essentially it looks at the parent range and it goes wait a minute the status you selected is completely incompatible with the parent. So people are just not aware of the fact that under an assignment you can't create another assignment. So, there is people trying to create overlaps or people just really miss standing the status itself.
Then at number 4 you have got I filled in a range but it turned out that this object already existed. Oops, I didn't check that. Etc., etc. Etc., etc.. so, there is lots and lots of errors in just creating INET NUMs alone and I can do this all day for any kind of object.
So, what do you do? You start building features based on users' behaviour in order to take away all of those hurdles that we put in front of them. You create this hole and you essentially just wait for people to fall into it. Well we can take those hurdles away.
Now, if you fill in a change in the RIPE database, it immediately checks, once you leave the field, it immediately checks whether that object or that same range already exists, and if it does, it just links to it and it goes like, no, no, no, that already exists, there's already an object like that that, here is it is, I'll give you a link to T also the submit button is grade out. You essentially cannot create an overlap and you are immediately guided towards the right object. The other thing is that if you try to modify an existing object, everything that cannot change is grade out. For example, one of the error message that we had a lot that was in the top five last month, is people trying to change the status of an existing object. But that's not allowed. You can't do that. So we just grey it out. The same is for changing the org reference, etc., etc., so everything that cannot change is now greyed out. It seems simple, but it has a huge effect. The other thing is that we put auto complete on everything essentially and we give you additional information, so when you first fill in an AS number it also puts the organisation name behind it making sure that you select the right AS number. Otherwise you need to know them all by heart. It's just trying to help people along. We do the same thing for abuse contacts. So if you start typing an abuse e‑mail address or an abuse contact role account name, it just all the owe completes it and gives you a suggestion on what it thinks that you would want.
The same thing for all of the people in the UK who fill in UK as the country code. And get an error message, you select the UK and you get GB, because what it should be because what is the standard. Essentially what we were expecting from people up to now is that they know all of their ISO country codes by heart but now we just provide a list with countries. Again, it seems like a really simple change, but it has a really profound effect in the amount of errors that the database throws.
We also have some weird stuff. I found this in the loads, why? What the hell is happening there? Because it looks perfectly fine. It's just range of IP addresses, separated with a hyphen, but it's not a high ten, it's an N dash, because your operating system converts two dashes into a single dash and it converts your single quotes into fancy quotes, right, so, we are a lot more lenient now, so if you fill in an N dash or M dash or regular hyphen, we convert to a regular dash, a regular hyphen, we are a lot more lenient and forgetting into what we accept from the RIPE database.
As a result, we started actively doing this in February, and we have more than ‑‑ we had like 17,000 errors on average per month and now it's like a little over 9,000 numbers up until today. So, making all of these kinds of small changes has a significant, a really significant impact in how error prone the RIPE database is. So now you see that a large portion of that 9,000 error messages that are left is actually trying to create the domain objects, so that's what we would really like to do next.
We also have some other stuff. So like I said, make reverse DNS less error prone. Locking down the status attribute values is something that we can do better. So, what we thought of is if you fill in a range, then essentially we can have the front end, have a look at what the parent object is, and unpopulate the drop down list where you select the statuses with essentially everything that it can possibly be. So, if the parent object is, for example, allocated PA, then the only possible status values that you can have in the object under it are a suballocation or an assignment. So, it will only give you those two options in the list depending on the range that you have selected earlier in the form. All little ways in trying to help people along in making the RIPE database a little bit less error prone.
And then personalised authorisation, I really want to tackle because the concept of maintainers is still really hard for users to understand. And with SSO we're making great strides in making it all seamless and logical. But we also want to do some work there in order to make that easier.
But just more stuff we did. This existed for an eternity in the RIPE database, it's called a reclaim functionality. And we renamed S it used to be called reclaim because everybody associated the word reclaim with us taking back the resources. It's not really the message you want to convey, so we wanted to give it a catchey name. I said I wanted to call it force delete. The other option was to call is pseudo delete, as in pseudo, make me a sandwich. Force delete allows you to delete like domain objects and INET NUM objects where you don't have the maintainer of the object itself, but you do have the maintainer of the parent INET NUM that sits over it. The only way that this functionality was normally used is by end users sending in this problem in a ticket to our customer services, our registration services department and then that person at the RIPE NCC telling them that they can actually do that using that maintainer. So nobody knew that this functionality existed, nobody found this by themselves. And now we just put it in people's faces like okay, during the authentication you are presented with a maintainer. If you don't have the credentials for that maintainer, just hit the force delete button and it will take you to a dedicated page that will explain to you these are the possible maintainers that you can use, so we just fetch all of them, you select one of them you go, I know the password for that one, you fill it in and it allows you to delete the object. So that we did.
Then of course, after a really short absence, it was just a couple of weeks, we put text updates back but we improved it in such a way that it also benefits from all the other things that we did to single field entry, so you also get a diff at the end and it gives you a more scriptive error messages, etc., etc.
The last thing we did ‑‑ I took this example, especially the lower block, the help text is not the most readable thing in the world. This also goes back to for example, for LEAs not understanding what all of the attributes mean, we rewrote all of the help text to make it more descriptive and it's like in a regular font and it has links to additional documentation. So it just becomes a whole lot readable and understandable. Then you have really tight control over this. If you have a suggestion, there's a report a bug button on the bottom right corner, you will you'll find it on every page of the RIPE database, if you think something is missing or something is not very clear, just tell us. Because we can very easily change this, we have a very good feedback mechanism. By the way that report a bug button used 173 times since we implemented it three months ago. It's all people trying to tell us little things, it includes a screen‑shot, it's really really convenient, to get user feedback in a good way.
And then lastly, the last thing I want to talk about is that for a lot of users, who wanted to change details in, for example, the organisation object, or their allocation, so the INET NUM for their allocation, some of the attributes there are managed by the RIPE NCC, such as your organisation name. But also the admin C and text C, you have control over them so you could change them. You just couldn't change them using the RIPE database interface. You had to look into the LIR portal and go to the so‑called object editors and then change your admin C or your text C and your allocation there. It was really really confusing for users because they went to, I just want to change the admin C, why can't I do that using the database? And now we do. So you go into the LIR portal and you select your so‑called default maintainer, so this is the maintainer that is associated with your LIR and once you have selected it in the portal we put that maintainer on all of the objects that have joint responsibility. So, we put that maintainer on all of the organisation objects and on all allocations and from then on out, there is a RIPE NCC maintainer there and there is the LIR maintainer there. And using bidses rules we determine which of the attributes can only be changed by the RIPE NCC and which of the attributes can be changed by you. And then you can use any update mechanism of your choice to update these particular attributes in your allocation or organisation objects.
So, that is what we have done there. And that was deployed last week. It's basic implementation and we have some ideas on how we can improve it because for example when you select your default maintainer, it also does auto complete but essentially it lists all the possible maintainers in the RIPE database, but we can do smart searches and suggest to you what is probably the most likely one that you want to use. So, that's the work in progress that we're doing. So lots of stuff happened. And especially I'm very happy with making the RIPE database less error prone and easier to use, and we look forward to your suggestions in that area.
Any questions or any comments?
JOB SNIJDERS: Thank you for your presentation. I like the data driven approach, and we have cleared out all the action items. You are resolving all the errors so by the next meeting we can probably ‑‑ hand hand the database will be error free, yeah...
RUDIGER VOLK: When you tweak the authorisation models, I am a little bit sceptical ‑‑ well, okay, whatever ‑‑ can we please have descriptions was what changes you are intending and then making so that we can actually cross check from organisations where probably more complex use of the authorisation model are in place.
ALEX BAND: Okay. Noted. Elvis.
ELVIS VELEA: I like it, good job, but you have a report a bug button, and you don't have a give me feedback button.
ALEX BAND: Yeah, but the sap name of that button was a long discussion. It was initially called feedback. It didn't really work.
ELVIS VELEA: So no one would give you feedback with a feedback button.
ALEX BAND: No, and calling it report a bug button ‑‑ I don't know ‑‑ we tried two different things and this one works better.
AUDIENCE SPEAKER: Dmitry. I would say we came a long way from the old interface to the new interface and as a topography gig I like the M dashes and N dashes, there are other characters that look like dashes but there aren't. I have this interesting question. You have decreased number of errors dramatically, I don't know how the speed is, but do you think there is any other approaches besides what you are doing to make it easier for people to handle database changes? Any smartness in it?
ALEX BAND: I think some of the smartness we can build is for example the suggestion that I did for determining the possible statuses when looking at the parent object. That that's I think one example of smartness that we're building in. Off the top of my head I can't think of others, if we sit back and look at the users behaviour for long enough I'm pretty sure we can come up with other ways of making the database more understandable.
AUDIENCE SPEAKER: Just one more thing. Auto completion is great but I probably object to auto field versus auto suggest. There is a fine list between offering you a list of things you may want to type versus typing the first one of the system thinks is right. You don't want people to select option number 1 without thinking because they want to make sure they are doing the right thing, especially if the possibilities may be dramatic.
ALEX BAND: Absolutely.
AUDIENCE SPEAKER: And one more thing. Which is probably longer discussion. Like the password is great, I don't know if you ever want to do the Jill factor for the passwords.
ALEX BAND: If you use your SSO account for authentication, then you can use two factor authentication.
AUDIENCE SPEAKER: But additionally for the object passwords.
ALEX BAND: Additional? So, you'd have to factor for some services and not others, so you can say okay this is what I want to lock down. That's an interesting one.
AUDIENCE SPEAKER: It's a bigger thing, I don't think we have time to discuss it now.
ALEX BAND: No. No. Thanks.
AUDIENCE SPEAKER: Lu Heng: I have actually a quick comment, question actually. RIPE does have the best user friendly web protocols to update its database. But some of the other RIRs don't have a such user friendly web protocol to update, at least not as easy to use as the RIPE ones and you just made a great improvement too which is already works pretty well user interface. And would be shared across the different once and also help improve their user interface because I think that many companies here also operate in different regions and some of them are not as user friendly as yours really. Band ban thank you, that's a good comment. We have regular meetings and they are well aware of the steps that we're taking, not only in the database, but for example also with RPKI and that kind of thing. So there is cross pollination there.
JOB SNIJDERS: Thank you for your presentational ex, I look forward to auto complete on my password. Next on stage database co‑chair pot or.
PIOTR STRZYZEWSKI: Hello. That's the first of my presentations, so just to follow up from anti‑abuse Working Group. This will be a one slide.
So there is a proposal number 2016‑01, main discussion is in anti‑abuse Working Group. Right now it's in the version number 2. The main idea is to extend the RIPE policy number 563 in consult with the other RIPE policy numbered 639, and (consent) to make mandatory Abuse‑C for all resources including legacy Internet resources. That's important. Why I am here with this? Because this will impact database if the policy will be adopted by the community.
And the impact will be that there will be less complicated business rules at the end of the process, but, we will have also an impact on the software itself on this part errors, that's something which corresponds with Alex's presentation, that errors, that Alex present explanations of the fields and I am pretty much sure errors should be also more user friendly, so dedicated looking at explanations instead of general errors will also be kind of a result of that policy, but just to be clear, we can do that without the policy as well.
I encourage you to follow the discussion on the anti‑abuse Working Group mailing list. That's all for this presentation. Question?
Thank you. So the next presentation.
Okay. That's our first numbered work item, the title is staying on top of the abuse contact changes. So there is an initial idea raised by Dennis Walker on the mailing list a few months ago, unfortunately no one responded to that but I do it decided to make it N W I number 1, and the problem is that the resource holder could be unaware of the changes made to the abuse contact details of his /her resources.
That could be a result of addition, change or deletion of any part of the abuse contact details put in his/her organisation object. And because a picture describes it better, there's the diagram, courtesy of the RIPE NCC, and by the way Ruediger, this is taken from the documentation of Abuse‑C, we have no chance to discuss that during the anti‑abuse Working Group but this is part of the documentation. So as you see, there's an INET NUM from which there is a link to the organisation from which there is a link to the role in which there is an abuse mailbox attribute. So, if abuse mailbox attribute will be changed from abuse at RIPE net to abuse at example net, or the role object will be changed from the A B 123 ‑‑ RIPE to A B 639 ‑‑ RIPE, or anything else goes wrong, or in the action which is not foreseen by the holder of that INET NUM, the INET NUM holder will not know about the changes, because the current notification mechanism will inform the maintainer of the role or the maintainer of the organisation object, not the guy who is taking responsibility for INET NUM.
That's by desire, so it's not the back, it's just the design of the database. So, that's the problem.
And right now we are in the Phase 1 of the numbered work item process. We are looking for a consensus on the problem statement. However there was no answer to that e‑mail and I would like to, all of you to make a comment on the mailing list. If you support the idea, or you think that the problem statement is out of nowhere, or whatever. Because, then we can move forward. If there will be no consensus of the problems, then we'll have no idea where to go forward. Job, do you want to comment right now or at the end.
JOB SNIJDERS: Do you agree with the problem statement?
PIOTR STRZYZEWSKI: Yes.
JOB SNIJDERS: Then you should also e‑mail to the list.
PIOTR STRZYZEWSKI: I know that.
If we move forward to the Phase 2 and have the chance to discussion the solution there is an idea by Dennis Walker sent to the mailing list. The idea is, but take it as one of the possible approaches, because right now still we do not have a consensus for the problem statement. So the idea is to make another attribute to the organisation object. It was called abuse noteive, it was proposed to be required and multiple, and this, another, attribute to keep an audit trail of any changes made to the abuse contact details for any parts of the resources. This required, which was mentioned at the previous slide, so this required, means that it's not mandatory by the database, but it's required by the business rules, etc. Enforced by the business rules in some situations and should be added, not must be, but should be added to any organisation object referenced by a resource object. And the idea by Denis was the abuse noteive from the top level resource would be notified. As I said, this is just a proposed solution and we are still in the Phase 1, so don't be connected with this solution if we still do not have any problem statement consensus.
So, that's all. Any questions?
AUDIENCE SPEAKER: Peter from host server. What's the difference between abuse notification and just notification that my object has changed? Why would this need be a different field?
PIOTR STRZYZEWSKI: If you change something here, then only the maintainer of this role object will be informed. Not the guy who is maintaining this object
RUDIGER VOLK: If they don't put a notify into the object they want to have monitored.
PIOTR STRZYZEWSKI: I don't agree with that. If there would be a maintainer here maintainer number 1 and there will be a maintainer number 2 here, those guys will not know anything about here
RUDIGER VOLK: You should be able to put a notify into the role object.
PIOTR STRZYZEWSKI: Yes, but ‑‑
RUDIGER VOLK: If you are the maintainer of something else, a notification ‑‑
PIOTR STRZYZEWSKI: That's a fantastical technical solution but we are trying to solve the problems in the political layer. Some organisations are huge enough not to make an argument about that
RUDIGER VOLK: Well, okay, bad data models breed strange creatures.
PIOTR STRZYZEWSKI: Thank you. Noted. Did I answer your question?
AUDIENCE SPEAKER: Essentially I think we should just move this to discussion on the mailing lists because I think there is ‑‑ like I have stronger questions about it, but we need to discuss it on the mailing list.
PIOTR STRZYZEWSKI: Fantastic.
JOB SNIJDERS: I do like to emphasise that on the mailing list we are in the problem statement definition phase and we first need to address that there is a problem here. And if cannot agree that there is a problem. Cannot move to the proposed solutions or even discuss them. So let's focus on that phase first and later we'll get to actual solutions and implementations. Thank you.
PIOTR STRZYZEWSKI: Thank you very much and the next gentlemen on the stage will be job with his presentation. Thank you.
JOB SNIJDERS: Numbered work item 5. Route objects for non RIPE resources.
I sent an e‑mail yesterday to the mailing list with a rather large problem statement that was formulated with the help of RIPE NCC staff. What it boils down to is that in the RIPE database we have various types of objects. I think there is no controversy that an INET NUM that is part of the RIPE managed space, with an ASN that is managed by RIPE as well, should be in the RIPE database.
However, we have different foreign style objects as well, and there are variations where, for instance, the INET NUM is of, is RIPE space but the aut‑num is not. There is foreign INET NUMs there but the ASN is managed by RIPE. And there are objects that are essentially have nothing to do with RIPE.
The existence of these issues leads to a deterioration of the data quality, because essentially the out out of region objects as they are today are anecdotal. We kind of trust them at face value and we have no way of verifying them. Other than that, the current approach leads to data duplication, because the current model encourages (people to create aut‑nums in the RIPE database in conjunction with maybe aut‑nums that exist in APNIC or ARIN or other databases. So this topic has come up quite a few times. What we are currently looking for is refinements to the problem statements. It would be nice if people can suggest text that makes the problem statement more concise, or, if people voice their agreement or disagreement with the problem statement as it is posted.
If we at least agree, or disagree, either way is fine, that foreign resources being hosted in the RIPE database is good or bad, then I think it will be much easier to converge on a solution, or abandon the effort.
And with that, I would like to hear comments, feedback. It is okay if you express agreement or disagreement in this room but I do encourage you to also e‑mail it to the mailing list. I see our most active participant in this session is going to the mike
RUDIGER VOLK: I missed one presentation today to comment on. The problem statement that I would make here is it would be a will really good thing if the objects that have some foreign part in them could be easily identified. Pointing back to previous discussion in this session, if we had markings like this aut‑num is foreign or is RIPE, and in extending this notion in small ways, I think that that would be essentially the interesting thing to get.
JOB SNIJDERS: I appreciate the feedback. If there are no further questions, I will clear the stage for I think our final agenda item. Our final agenda item is, is there any other business?
I am extremely pleased that this might be the first database session in years to conclude before the deadline. That is quite an achievement. Thank you for attending. I have repeated this a number of times, but I'll make this a final statement.
Your participation on the mailing list, especially in the new numbered work items approach, is crucial in deciding the future of this database. So, if you care about data, if you care about the RIPE database, please voice your opinion and that will really help us guide this further. Thank you for your time.
(Coffee break)
