Database Working Group session
Wednesday 25 October 2017
2:00 p.m.
CHAIR: Welcome everybody, we're going to get started. Thank you all for coming. This is the Database Working Group. I am your co‑chair, William Sylvester. Our first item on our agenda is a welcome, so welcome. We have a scribe, Michael, from the NCC. Thank you. I appreciate everything that you guys to do help us out.
Marco is on Jabber. We'll be bringing any yes, sir from remote participants. Here we have our agenda. Are there any updates to the agenda? I think we have captured everything.
All right. Does anybody ‑‑ we sent out previously the former minutes, any comments on the minutes that were posted to the list? Any other updates? Seeing nobody running to the mics, we'll sake that as accepted.
With that, Tim, we'll let you do the operational update from RIPE NCC.
TIM BRUIJNZEELS: Hello everyone. So, I have 40 minutes on the the agenda.
Update:
I have talked about this at various occasions and the story is similar. The way we work, we really see three major areas of the database that we feel very responsible for. Well, we can discern different areas, let's say. There is, of course operations, we need to make stuff work and keep working. There are things that come out of this Working Group or other Working Groups that we need to work on. And the other major component that we see, I think it's best summarised with usability. It's getting people to use the database easily and dealing with issues they have. Helping people to keep the data correct and up to date.
So, with regard to the Working Group and policies. We have not done that many releases since last we met at RIPE 74. But we did release number 1.89 shortly after, and that included an change such that when you get a notification about a change to an object, we tell you who made the change, if we can. Because if it's a maintainer, then it's limited what we can say. But if an SSO account was used to make the change, we can tell you who made the change. And similarly, if a BGP key was used, we can tell you which BGP key was used to make a change.
Actually not mentioned here, but something that Rudiger mentioned, is that this kind of thing may actually also be useful for route object creation, that was a suggestion you made. I believe you can comment on it later if you want. But just to say, if there's a broader use case for this kind of thing that includes the creation of the objects that people want to be notified about who did it, that's something we could look at as well.
Other than that, this release included a change in the way that we validate the main objects, that was activated sometime after the release went to production, and we have seen no issues with it actually. So that's good. Then, recently we released 1.90, to deal with the changes regarding Abuse‑C that are implemented in the database. In summary, what the change means is that you can now add Abuse‑C references to a roll object within an abuse mailbox on resources objects or INET6 numbs and aut‑num objects, and we have already started to disallow new additions of abuse mailbox outside of role objects. We plan to do a cleanup of those attributes and other objects coming Monday actually. This was also communicated on the mailing lists.
So, there is not a lot that people need to do with regards to this, the abuse mailbox in other places would not have been picked up by abuse final logic actually, so we do point people at the way that they can set up abuse contacts properly for their resources in the e‑mail that people get for this change.
Sometime in the future, we will also do another release where we want to clean up the code and remove the whole concept of having this attribute on the abuse mailbox attribute on other object types, but that's for a later stage. We may actually combine this with other updates.
One more thing that I wasn't sure whether I should talk about it or not. Job Snijders made a request on GitHub, a source code is on GitHub and sometimes people make issues there, as you all know Job has done a lot of work on the large communities and there is a request to add this as a key word to the RPSL dictionary. Personally, I don't see a big issue there is question to this Working Group is okay, how should we deal with this kind of thing? Because it feels to me that it would be best if the Working Group indicates that this is a useful thing to work on or not. I think from our perspective, it's probably not that difficult to implement, but I can't really over sorry the implementation that is this may have on operations so, I would be more comfortable with other people, you know, adopting it if Job is not for his own reasons bringing it up in this Working Group but only on GitHub.
So there is that. I just wanted to say that and I think I should leave it to the Working Group to see how you want to respond to that.
Then on to operations.
So, as usual, some statistics on updates and queries. As usual, the rate of queries far outweighs the rate of updates, that's unsurprising. The average update rate is around five updates per minute, now we do sometimes see currencies where people try to do many more updates, but there are quite a few and far in between, it's not something we have been actively optimising. (It is)
Another thing that we have been doing some work on it's not as visible to all of you, but we have made some changes under the hood. Especially in the web updates part where we phased out an old component, and replaced it with a new version; that's about to go into production probably next week actually. And, well that helps us reduce the cost of ownership and then the maintenance burden that we have here and it makes it easier to integrate everything.
Other things that we are going to do in this area actually is, we have planned a major bit of work on helping to automate the resource transfers that are IPRAs have to deal with quite a lot these days because there is still a lot of manual checks that people need to do in the database before a transfer can happen and manual updates after it happens. So, we are looking into making that a whole lot more efficient for everybody.
Then, I'll get to this one, one more thing on operations. A while ago, out of this Working Group, we ‑‑ well, it was concludeed to deprecate the changed attribute and replace it with last modified and created. We still accept changed when it's submitted in modify or creates. But we generate a warning and we filter out the line in the actual object.
So, what we do see, though, is that there is still quite a few creates and modifies coming in with the changed attribute. So, on the one hand we would really like to get this out of our code base because it feels like noise, and that's never good. But, if we were to turn it off, it would actually impact people. So, I'm not sure what to do there. The list of people who do this is not that big, so it's a few people doing lots of updates.
So, we'll probably approach these people directly first and see if they can be persuaded to stop doing this. But, I do want to say it here because it's good to keep in mind when we make changes to the database syntax and we deprecate things and remove them, there is ‑‑ it's hard to get everybody to move along with these kind of changes.
There is also the question about if people are not aware that this was removed and they used changed for other reasons and it's actually filtered out of the object and maybe that's not really that great, right, maybe they should be aware that they should be doing something different.
Then, on to my favourite subject, usability. We have done a lot of work there, I thought that I'd put this quote here. It's quite applicable thing to, well, not just to us, but to everybody. So essentially, organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations.
So, when you translate this to the landscape of services that we offer, I think that, well, until quite recently, yes, we have made improvements like we have a single sign‑on system and it's easier to go, to use RIPE NCC service in different places, but it's still not really a seamless experience. Well, we really want to work on that because even though it's a natural process that those things are implemented in different teams and in different places, we don't want to subject you more to that than necessary.
So, on that, recently we have deployed the, well, what we called my resources, this is not just for LIRs, but also for other users of the database if you have a maintainer on an organisation object with resources in the database, then you should be able to see your resources in an overview. And this is an attempt to combine all that stuff. So things that you see here is, if you look at the details of an object here, you can also see details such as the ticket number of the allocation ‑‑ that was involved in getting this allocation or assignment. In certain cases, we also warn, and this is our own registry so this is a bit of a strange beast because we have some difficulty being our own customer, let's say, but typically we do see that sometimes for example LIRs have PI sometimes where another LIR is sponsor and I don't think that this is illegal but it's a bit odd and you know it's something we may want to tell you about like okay, this is really what you want.
But more importantly though, for this group I suppose, you can navigate your objects here, you can see the object higher key and modify object and in future, this is by far not a complete list, but we do want to leverage this to do more things, like to doing management of contact information for example, delegate or consolidate, who maintains these objects, reverse DNS Lameness, route objects, and, well, there may be many more things. And yes, if you have your favourite things to work on here, we would love to hear about it.
So, one thing I actually wanted to mention also on the usability front, is that we do see good results from this.
So, Andrew mentioned this in the Services Working Group, that we have seen a decrease of about 40% in database support tickets so we really believe that doing this kind of thing helps a large part of the community out there who are not necessarily as familiar with the database as people in this room.
Finally, I'm not sure when we will plan to work on this, but it depends also on other work coming up. But the query interface is used even more of course than the update interface, and well, there is so many flags it's really not for a lot of users out there. So we're also thinking of making a simplified version of this for people who just want to know stuff like, okay, who is associated with this IP address or something like that, because most queries are actually IPv4 addresses without any other comments in the search. So, we do have some statistics on what people find ‑‑ what people typically do here.
But, don't want to take away the more advanced search options for people who do know how to use this of course.
That's it actually that I had for this presentation. But I'd be happy to get questions, comments and discussion.
AUDIENCE SPEAKER: Marco Schmidt, RIPE NCC. We have a question from a remote participant, Job Snijders, and he has a comment saying: "Currently there is a community keyword in the up USL dictionary that refers to RFC 1997 communities. Now that we have RFC 8092, large BGP communities, it may be good to extend the dictionary and support documenting large communities too. However, I'm not aware of many networks passing import/export RPSL aut‑num lines so this may be a change that offers very little return on investment."
RUDIGER VOLK: I collected a surprising long list of things that I should actually discuss in response to the presentation, but let me first kind of jump at Job's remarks. The RPSL has been designed with a certain model of how to be extensible, and kind of the first clash I had with Job that I remember was when he brought up one suggestion for extending RPSL which was not aligned to the extension model, and after the clash, we actually figured out ways how to deal with this. I suspect ‑‑ well, okay, it is very clear that we really need to discuss a very specific proposal for the extension. I suspect that actually the large communities are much harder to introduce into RPSL than the thing where we had the clash, which was essentially the via thing.
From my perspective, it is absolutely clear that the extension mechanism of RPSL has to be respected if we do not do that, if we extend in ways that are in conflict with the extensibility architecture, we very definitely break existing clients. So, that is not acceptable.
Let me make one very simple remark on your question on, well, okay, are we going to disable the processing of changed attributes? You said people ‑‑ there will be impact on people. I think the impact on people is likely to be indirect. The impact actually is on robots. And kind of, my argument there is, yes, it would be nice if every robot that is out there gets fixed and updated, but that's a process that is really hard to control and kind of I would guess the penalty that you have to pay for maintaining that small part of code is completely justified by avoiding making trouble on the existing robots.
TIM BRUIJNZEELS: Can I comment on that? I see your point, and I largely agree with it. Nonetheless, I think there is value in reaching out to these people and telling them, because they might be using this attribute to keep a record of changes that they made and not be aware of the changes there. In that case, it would be good, because you know, they might be surprised to not see their attributes.
RUDIGER VOLK: Well, okay. I am painfully aware that the changed attribute is not maintained any more, it kind of I think was overkill and we really lost information that used, with understanding, what the value is actually were very valuable and that actually links into the thing where you said well, okay, you did receive some requests from me and I might elaborate on them. When database changes are done, maintainers to the notified parties get records of that. In the good old times when everything was on e‑mail, the identification of the guilty party always was supplied in the form of an e‑mail address, which was course we know could be faked like in the changed attribute as well, but usually it actually gave a good pointer to what was happening. With the online updates, we only are seeing IP addresses which, in this case, unfortunately are not really personal data, they don't identify the guilty party in a way that we can track who in my organisation actually did the thing, or whether someone else was doing it. You mentioned you did an improvement on those change reports the however they are limited to I don't really remember which class of updates. There are still updates and changed messages that don't get the information ‑‑ yes, well, okay, all the SSO based thing, kind of some identification of the owner of the account used should be dropped in there and that should happen on full the changed messages.
TIM BRUIJNZEELS: Okay. That's good to hear that point. But let me clarify some bits.
So, it is actually on all the updates of objects that we include this information where we can, not on creative objects. So, there may be or may not be value there. I think it's a discussion that's worth to have, but it was not included in the original thing.
Now, where cannot say who made the change is essentially when people use password based authentication, because there may be multiple maintainers on this object and if the password matches the hash in multiple maintainers, we can reveal sensitive information. We can reveal to people that the password that they have on one of their maintainers here is actually also in use on another maintainer. And that's why we decided that we're not going to tell people which maintainers match that password. So, it's unfortunate, but we feel that if we did reveal that we are introducing a security risk that we're not comfortable with and the solution is that people use more identifiable mechanisms, they can use SSO, they can use BGP keys. A discussion was had in the past, maybe this is not the place and time to have it again, but a discussion was had in the past about personalising authentication, having other constructs there, apart from a maintainer that has all the passwords on it because it's hard to identify who made changes there. So, that may well be a discussion that the Working Group still wants to have. But, without it, I don't see how we can easily improve this without introducing a that security risk that I mentioned
RUDIGER VOLK: Actually, I seem to remember that in old days the changed reports I think even pointed out which maintainer was used for the authorisation which does not give away anything except for, well, okay, identifying what authorisation was do you say used. Actually I would also like to see that also, but having kind some of identification who actually acted and, well, okay, are password based things possible in the online environment?
TIM BRUIJNZEELS: Yes. If you don't have your ‑‑ you are required to log in, but if you are not, if your SSO account is not associated with the maintainer around the maintainer does have passwords, you can supply the passwords and by default we will ask you do you want to associate your SSO account with this maintainer in future? But if you opt out of that, we remember that choice and we will not ask you that question again. I believe that's the change we made at least. So, yes, you can use passwords in the online ‑‑ in the web updates environment as well.
RUDIGER VOLK: Yeah, but kind of ‑‑ so when you are using online, you always ‑‑ you are always under SSO or is there a path that does not identify the user?
TIM BRUIJNZEELS: Well, you can use sync updates for example. But even if we do give you the log in prompt but if you do supply the password as a maintainer and you associate an SSO account with it, then that information is not carried over to the back end, that's just plain past word authentication then. One of the problems we have with this authentication model, at least in my mind, is that you can just supply a password. You don't have to supply the context of, and this is the maintainer associated with that password. It's not user name and password. It's just password. So, if we were to tell you, you know, successful update was made using a password matching this list of maintainers, or the first one, that might not have been the one that you were using. So... that's the problem. You could do it, technically it wouldn't be hard for us to do it. But we think that introduce as security risk that we're not so comfortable with.
RUDIGER VOLK: I certainly see that careful security analysis is needed, but I would expect that for essentially all cases, one can identify what information is available and can be passed on without disclosing too much.
TIM BRUIJNZEELS: One thing we could do there it would require some work, but I am definitely willing to look into that, is if you notice that the password only matches one and only one maintainer, that we can tell you which one it is.
RUDIGER VOLK: Kind of, the password is not disclosed to the recipient of the changed notification.
CHAIR: Guys, why don't we take this off line.
AUDIENCE SPEAKER: Peter Hessler with Hostservers. I joined the Database Working Group specifically because I I wanted to know specifically who made changes to my objects and so I am extremely happy that now you are including this information with the changed. I would be utterly delighted to see this also with deleted and created and any other objects that may be created or changed at any stage. I would also strongly encourage that for any sort of a, when RIPE NCC comes in and cleans up the database, that that includes RIPE NCC did it under clause whatever for reasons. Very object to us as the recipient of these mails to understand what happened. And just so we have our own set of change logs.
TIM BRUIJNZEELS: Yes.
AUDIENCE SPEAKER: Erik Bais, for the question that Job asked for the large BGP communities, I would like to see that if and how that can be implemented if possible.
TIM BRUIJNZEELS: So, yeah, my challenge there is that I'm not as familiar with all the details of RPSL as some you. So, I can pass on Job's request, but like I said, I would be more comfortable if the discussion that's kind of happening between Job and Rudiger here is happening between them, not me as intermediary.
ERIK BAIS: The majority of the stuff is done on the mailing list and not here at the face‑to‑face meetings, so...
TIM BRUIJNZEELS: If Job doesn't want to do it, I can take the request that is on GitHub and pass it, send it to the mailing list but after that I would really like people in the Working Group to talk about it, because like I said, I don't feel comfortable just proposing like hey guys let's just do this, because continue wouldn't hurt, right. I need some feedback there and it's not really my request to begin with. Like I said, it seems plausible to me, but other people may have opinions there. So, I think the way forward that I can see is that I take it to the list and then you know, people respond to it and we take it from there.
ERIK BAIS: Excellent. All right. Thanks.
RUDIGER VOLK: Okay. Let me put one short comment to Erik. Clearly changing RPSL is clearly not going to change on the basis of some GitHub unless a wider community actually agrees to use that GitHub as the forum and even the RIPE routing ‑‑
CHAIR: Let's take it to the mailing list. Marco any other comments from online?
AUDIENCE SPEAKER: Marco Schmidt. I just got a comment, I couldn't find out who said it yet, but it was said, made a question to maybe discuss here rather than take it uptime on the mics, should the large community witness the routing working group instead. There is it was original discussed.
AUDIENCE SPEAKER: Rob Evans, it was more to discuss it in the chat room rather than take up more time at the mics, but I was ‑‑ it was just RPSL was discussed in the originally and whether that be the case to discuss whether this is an appropriate change to RPSL.
CHAIR: Tim. Thanks.
(Applause)
TIM BRUIJNZEELS: Sorry, I forgot one thing. Nathalie, sorry, I have to put you a bit on the spot line. So as people know, Alex Band has left the RIPE NCC and he was product, doing product management with us, and from next year on, Nathalie will do that name role. So, well known by many. She is still very busy with other things though, so ‑‑ but yes, that's where things are going in the future. So very happy to work with her as well. Thank you.
(Applause)
CHAIR: All right, so next on the agenda is the mailing list in regards to the D mark, for those who have been active on the mailing list you will have notice that had we had all of our e‑mail messages as attachments, and through a lot of feedback we determined this was not ideal. Through Adam castle and his team at RIPE NCC, we just last week implemented a fix. I think that this has been much more acceptable. The attachments are gone, e‑mails are back. The one change is that it does break an RFC, it rewrites the from heard, the primary implication that have is when you click reply all it also CCs the Database Working Group mailing list. So, just, it was already placed down on the mailing list, but just to be aware when you are clicking "reply all," that you are replying back to the list.
I'd like to open the floor and see if anybody has any comments about the solution, any problems or otherwise? If not we can move on. But if you do have any problems or issues, please do let us know. Database has been a leading Working Group in in area, this whole initiative started is because we had users who were not actually getting e‑mails off the list from some major providers so we worked closely with the NCC and we appreciate their help in trying to work through this problem.
AUDIENCE SPEAKER: Petter Hester, I do appreciate the change. It's easier to use now. One thing in I notice in my mail client if I press just reply it's private. Reply all includes the group. Is that the intention?
WILLIAM SYLVESTER: That's currently the way that works, so yeah. The reply to is actually set in the heard. So, reply to is the original centre even though it comes from the mailing list.
AUDIENCE SPEAKER: Just as a side comment, demark is a horrible stain upon the earth and we should not be making changes to support these people that are trying to break e‑mail. So...
WILLIAM SYLVESTER: Thanks for the comments.
AUDIENCE SPEAKER: Peter Koch. Just because you mentioned that DB is a bit like leading, you said and Peter just said where is this going to lead? But anyway, probably you are the wrong person to ask, but is this now a discussion that is being held in every other Working Group or can we expect some ‑‑
WILLIAM SYLVESTER: Yes, so NCC is ‑‑ I don't think Adam is here ‑‑ Adam is here, I'll let Adam answer.
ADAM CASTLE: I work at the RIPE NCC. We are currently in the process of upgrading the Mailman solutions to have better demark settings for the mail list. That will be put to every Working Group, every Working Group Chair to see what they want to do with their mailing lists. Ideally we want one solution for all mailing lists but the Database Working Group mailing list was really affected by this so we had to act quite quickly. So, in the future, we would have better settings for all the maintenance.
AUDIENCE SPEAKER: Okay, thank you, so we'll do the demark setting unification after we have equal Chair selection processes over all our Working Groups.
CHAIR: Thank you for your comments. Moving onto the next agenda item are NWIs and currently open proposals.
On the mailing list, we have moved forward on a couple of initiatives. The first one we did was Abuse‑C, which was NWI 7, which is now in its implementation phase. And just last week we moved to the solution definition on NWI 5, which was our out of region route aut‑num objects. I know that there's been a lot of discussion in the last week or two, it's been really great seeing a lot of activity on the list but for the other NWIs that is still open. I am going to run through them.
NWI number 1, staying on top of abuse contact changes.
NWI number 2, displaying history for database objects where available. This was just reannounced on the mailing list last week. I know there is some preliminary discussion, but would encourage folks to jump in on that discussion, if it's something that you are interested in or have an opinion on.
NWI 3 was AFRINIC, IRR homing.
NWI 4 is the role of status field in multi‑valued status context.
NWI 6 is applicable data model not clear from contextless objects.
If there is anybody that would like to talk about any the NWIs right now we have sometime to open the floor. Peter, go ahead.
AUDIENCE SPEAKER: Peter Hessler. I'm wondering if the AFRINIC cleanup and the opening of the database to non RIPE objects, are those in conflict with each other? How would that be handled?
WILLIAM SYLVESTER: I mean as it stands right now we have a solution around the out of region objects that is currently being reviewed by RIPE NCC. The other proposal has been in the same status for roughly a year, actually about a year‑and‑a‑half. And hasn't quite found ‑‑ it's still in its solution defining phase. So, do you have a proposal?
PETER HESSLER: I don't have a proposal, I just would suggest that the Working Group consider that this may make it in their relevant decision or it may not.
WILLIAM SYLVESTER: Yeah. It might make sense to shut the other one down or revise it. Rudiger?
RUDIGER VOLK: Well on that, my suggestion is essentially kill that item. Wait for AFRINIC to come back and report that things are nice in AFRINIC. And we Europeans should not try to interfere too much with what the Africans are doing. We can help if asked, but ‑‑ and kind of, I think that should do it and well, okay, if we do anything else about address space and resources that are not authorised by RIPE, well, okay, that will apply.
WILLIAM SYLVESTER: Thanks for the feedback.
All right. With that, next up ‑‑
AUDIENCE SPEAKER: Brian Nisbet. HEAnet. I have no wish to bring any more work on myself, but I did say I would do something in Budapest and I sent an e‑mail to the list which got lost in the conversation about the NWIs. All I would say is, there is a proposal there which largely just says can we make sure we close the loop on pieces of work, and that even if a suggestion is made and people go no, then it just crops up and it goes no, we're closing this item, so we have that clarity. That was the substance of my suggestion, because ‑‑ I don't think it's a huge problem, but there do seem to be a bunch of kind of hanging where are we with this particular thing? I suppose it's as much as anything else it's a request to the chairs to do that.
WILLIAM SYLVESTER: From our process we have been working through the list. Whereas we have sort of been resolving one issue and moving it to the next phase, we have been trying to reintroduce those previous NWIs to see if there is interest on the list. As we found that as we have reintroduced them it seems that everyone has an opinion and some of these things have continued to move forward. Within that we haven't had the opportunity to close things down because of non response, which has been very positive, so it's been a long running process, and we do have a series of these things hanging out there but we have now worked through about a third, almost half of that list, you know, even just from the last year, so ‑‑ which is a lot more than I think we had done prior to that. So... but thanks for the feedback.
Right. Up next is Alain end user and from ICANN.
ALAIN DURAND: Good afternoon, I am Alain end user and from ICANN. Before I dive too deep into this, how many of you were in my presentation this morning at the Cooperation Working Group? So most of you were not, so good it's not going to be too much of a repeat. Those of you who were there, feel free to ask the same questions, if you want to.
So, as I said, I am from ICANN, I am from the research group of the CTO, so we're not lawyers, so we say that we are the good people.
So, these ITHI goal. The question that was asked to me is how do we know that any other policies which are being deployed and developed in our communities have an impact on the shape of the system of note fire that we have. How do we know that we are better this year than we were doing last year? And to answer this question, we need to talk about "the health" of the system. So, making an analogy with human health has some limit, it's not always one and one, but there is some interesting aspect to it. So we went and looked at this and tried to establish a baseline. And from that baseline, tried to see are we year after year. So if we end up with some number an indicator, let's say that we are at 720, by itself this number means nothing. But if we were at 800 the year before and we know that a lower number is better, being at 720 is better obviously. We don't necessarily know if it's a lot better or just a little bit better, but it is better.
So that's where we are trying to go. When we look at indicators for health, there are two fundamental approaches that one can choose. You can either take a bunch of data that's available, and try to find some pattern in this data. And from there, add X, Y and Z, divide by T and multiply the whole thing by A and you get an index. Or, the other approach is to look at the problem space, try to redefine "problem" areas and try to find ways to measure these things. And then go and find the data at the end of a process. It's a much longer approach, takes a lot of time to do it. We hope it will produce some good results.
One caveat which I really want to stress is, ICANN, the organisation is not looking at those numbers to take action on the community. It's really really important. The hope is to present the data, do a minimum analysis and to give it as input to the policy development process, or processes in our community, for example to this Working Group and to any of the other Working Group over IRs or policy development process within the rest of the ICANN community and leave it to them to use this data to figure out what it means for them.
So, ICANN has three branches, names, numbers and protocol parameters. So you won't be surprised that we really have three different processes here.
The first one is about the number one, so this is something that's driven by the NRO, the Number Resource Organisation and you will hear more tomorrow, I think, in the NRO report about some of the work they are doing there, there is some great work being done by the registry service teams on the different RIRs and they are starting global consultation process. If you go to the NRO website you will find a link to that, and would I strongly encourage you you to go and read this and participate to the discussion what's happening there. But more details on this tomorrow.
So, what really have more direct impact on the name side. So we started by defining five problem areas and we took a lot of time to can you say different problem areas. So we could add more to this list. And there were some suggestion this is morning to maybe add something about EPP and device issues related to that. This is something that certainly we can do. The one we chose so far, data inaccuracy, which is something that is really relevant to this Working Group. Abuse, overhead in the root DNS servers, leakage of names in the root and misbehaviour on DNS resolvers, all of them are related to DNS.
The process that we are using is a pipeline. We are going to find some data, some raw data that we can analyse, sometimes this whole data will have private data that is not publicly available, it's commercial data, sometimes it will have personal identification, and we have to abstract things from that. We are going to make our own data available and cannot simply pass commercial data or cannot pass data which has a PI, so we have to do this abstraction here. We will commute some tables so that we can follow indexings month after month or day after day and maybe process some graphs, and then publish this through the open data initiative which is another project within ICANN.
Because all this will be made public and this is really the goal here. That's why this is so important to have this filter on the left‑hand side so that we don't publish commercial or PII data.
So, I'm going to go quickly on some of the metrics that we have defined. Each metric has some refinement. A diverse number of submetrics. The first one is about data accuracy. So one big difference between ICANN the organisation and the RIRs is we don't have access to the registration data. With I remember you have all the different WHOIS information under the prefixes and the owners know all that. This is something the contributory negligence centre has access to in the ICANN world. The ICANN organisation doesn't have access to that so cannot go and measure this directly. The approach we chose was to be indirect and to look at the number of complaints that we call validated complaints, people are saying we have a problem there, so yes, they can be gained but that's an indication. So that's where we want to start.
The second one is about abuse, so there is another project in ICANN, well a number of projects in our group looking at things similar to this, it's called DAAR, for domain abuse activity reporting tool. Essentially what this does is to aggregate a number of anti‑abuse list, like Spamhaus and a bunch of others and look for each gTLD and region is in the contract with ICANN and try to see what is the density, I would say, of abuse populated problem in each of those TLDs or registrars, we break this down into the spam, phishing, malware and botnet. So far what we are seeing is spam is by far like, there is two other magnitude, larger than the rest. We are interested in spam because it's a factor for all the other problems to go into the system.
When we are starting to look at cluster of problem areas, either in the registrars or in the registries, we see what phishing, malware, botnet and spam go in different places. It's going to be "bad" actors or people who create situations that lead to abuse seem to be very selective in which top level domain or which registrar they are getting.
I would have loved to show you some data but you still have to go through an internal review process and get the stamp of approval from the lawyers to say yeah we can show the data. Hopefully that will come soon.
The next one is overhead in the root. We had a presentation from Daniel Karrenberg about some of the issues in the root that should not have been sent in the first place. Initial measurements show that if you add the queries for no such domain, that ends with no such domains, domains that don't such exist to queries that never should have been sent, this is something like 95, 97% of all the queries, that's quite a lot. That's okay today. The system can handle all that. But we want to make sure that we track this so that if this number were to become like 99 or 99.9%, it will be an early indicator that the system of route servers have to evolve. (Route servers)
Leakage is about all the names that should actually not be resolved at the root, things is that not have been delegated or things that have been listed in the special used name registry from the IETF, and in that list we see like a local mail and we see a lot of requests for them. So, trying to keep a tab on this.
Another interesting one is resolvers that are misbehaving. We have had a lot of an he can dole reports of resolvers that are returning the wrong answer, so I ask for a domain and I am redirected to another domain. Sometimes a competitor, that's something that should not happen, that's something that DNSSEC should actually address but DNSSEC is not deployed everywhere so this problem can happen. We have also seen evidence of a service provider redirecting port 53, so if you send a DNS request somewhere, the server that is responding to you is not who you think it is. Anecdotal evidence are interesting but measurements are better, so that's what we would to see here having a better idea how prevalent this problem is and hopefully over time it will not be as much as of a problem. Maybe it's not a problem now and maybe the anecdotal evidence is a false positive.
The next category is on the protocol parameters. So we scoped to DNS related registries in the IANA database, and what we want to do is to look at all the DNS queries and responses, and see how the DNS protocol parameters are being used. So, sometimes it will be, for example, the type of type that is being requested, how many As or AAAAs or MX or SOAs, etc., sometimes it will be protocol parameters that are not registered and are being use and we can wonder why are they not being registered, and sometimes we can use this as an early indicator of deployment of system technologies, for example DNSSEC or some of the cryptographic algorithm using DNS, is it being used or not or technologies like TLSA from the Dwayne Working Group in IETF. One of the issues is right now we are doing with measurements at the root and at the root we don't see everything of course. We would like to do similar measurements on DNS servers that are operated by service provider and others. So my call for action today, if you are, if you are operating one of those DNS recursive servers and would like to collaborate with us, we would like to talk, we have scripts, programmes, that you can use with capture traffic that will extract from your capture only the information about which parameters are being used, so we calculate some tabulation about which parameters are being use and we move all the information about the IP address of your use, which domain they are resolving and all those things. So this is something that is fairly innocuous and we'd like to use this to compute some statistics, so if you are interested, if you have, if you would like to participate in this project, come talk to me.
That was my last slide. So, if there are any questions, I would be happy to take them now.
AUDIENCE SPEAKER: Pete stress ski, speaking on myself. I don't feel that I am attacking you, but I found it mostly about the DNS and DNS ‑‑ in the other room right now running parallel, so why are you presenting this in the database except for the fact that the chairs accept the presentation? I do not find it strongly connected with the database. Maybe I missed something.
ALAIN DURAND: The fundamental reason why I am presenting this is at the end of the day, a lot of this is about the accuracy of the data. And you have a group that I would think is a most appropriate to talk to when we discuss accurate data. So, this is a heads‑up of what we are doing, and I the Chair that this was a proper venue for this.
AUDIENCE SPEAKER: Speaking the accuracy of the data, this kind of discussion in the anti‑abuse, but it was mostly about Abuse‑C, but still it's about the accuracy of the data. So, maybe this is something for the Plenary session, just to get to the wider audience.
ALAIN DURAND: That's actually a good suggestion, and I can represent my talk or some newer, updated version of it with some results this time hopefully at the next RIPE meeting.
CHAIR: Great. Thank you.
(Applause)
WILLIAM SYLVESTER: All right. With that we're up to any other business? So, first on the rest of the agenda, I wanted to bring up the Chair selection process. A year ago we had a very exciting Chair selection process with Nigel in drawing of the hats, helping us select our chairs for this year. In an effort to sort of recraft that process, we have been talking to folks and we're looking to make a proposal on the mailing list here shortly to sort of revise and modern eyes some of those initiatives. With that we have been looking at ways that we can implement a process that would provide not only a better selection process, but also provide us some continuity within chairs, so that we didn't have the situation that we had last year which is where all three chairs were brand new, and no carryover of sort of knowledge or understanding of the processes or what really what it meant to sort of run the Working Group.
Within that, we have also identified that we don't have a process for removing chairs or replacing chairs sort of mid‑stream if someone were to resign. Currently we have a vacancy as one of the chairs step down last week as many people have probably followed on the mailing list, with that I'd like to open up the floor and see if there is any comments in regards to what people in the Working Group would like to see and things that we might be able to do, Brian.
BRIAN NISBET: There's one thing I would ‑‑ a couple of things I would mention. One is that as has been mentioned elsewhere this week, one of the things that Hans Petter, the RIPE Chair, is looking at is trying to get a single system for all Working Groups, which I am in favour of, as long as it's the one that anti‑abuse uses obviously. I am in favour of and I think it's a good thing for the community and for new people coming in and not to have 17 different states writes policies. But all of that said, if that doesn't happen or whatever happens there, please, the drawing lots is ‑‑ I don't think it works for anybody. I am trying to persuade connect ‑‑ sorry, IoT not to adopt it. There are policies there from other groups, you can just steal one of those and not have to worry too much about those, but just having something which doesn't lead to random chance because we are not a community that has random chance.
WILLIAM SYLVESTER: Do you have a recommendation from which one to steal from?
BRIAN NISBET: Obviously I think the best one is the anti‑abuse one. Obviously I don't mind. I think there is a system there which consensus, and if the Working Group doesn't have a consensus on who they wish to be a Chair, it then defaults to an election situation. And that there is an ability for the Working Group to ask for a Chair to be removed and that's the core things. What wording goes after that... whatever...
NIGEL TITLEY: Ex Working Group Chair and author of the current Database Working Group Chair process.
I admit there are problems. In particular, we didn't stagger the terms and that's really the major issue. I would like to draw, to take issue with one of your statements is which was we're now short of a Chair. Strictly speaking we're not short of a Chair. The Chair selection process says that there should be a maximum of three co‑chairs, so you are not actually short of a Chair and there's no need to find a new one or anything like that. I would also like to point out that the drawing out of hats was a tie breaker process, and as far as I am concerned, it's as good as any. Voting is out. Because we don't have a defined franchise. Okay.
PETER KOCH: Consensus is a very good, consensus based decision is a very good approach to a number of things. But this consensus actually is a compromise in disguise. So to come so a consensus decision you need to be able to talk and walk towards each other, if we end up with situations where we are stuck in a way we need what Nigel said, we need a tie breaker. Even if there is a rough consensus as often referring to as coming from the IETF, applying the variables that the IETF uses isn't necessarily the good thing in personnel decisions. That said, even the IETF uses tie breakers, and they have a variety of them and they have a bit of experiences, these and those, but consensus doesn't mean you need to talk anyone to death to get off the slate. I think the tie breaker in this case worked very well. There were deficiencies in terms of continuity that Nigel already mentioned but that is not necessarily a bug of the tie breaker, it might be a bug of other things. So, don't expect to get out of the situation by continuously applying consensus based decision. You will end up with people that stick, and actually that's a good thing.
PETER HESSLER: One of the concerns that wasn't brought up on the mailing list was that use of the database ‑‑ breaking of the database terms and conditions is not allowed. And there is no dispute about that. Then, there is as members of the Database Working Group, we should be extremely familiar with this and one, thud we be held for strictly as a group to that? And two, should the Chair or co‑chairs also be held more strictly to that? And I think that we should cover that when we go to modify the Chair selection process, we should consider that.
WILLIAM SYLVESTER: Sure. Do you have a proposal in regards to what you would advocate?
PETER HESSLER: Not right now.
WILLIAM SYLVESTER: Great. Any other comments? Any other feedback? Is there any other business? We're running a little bit ahead of schedule. Anything else anyone would like to talk about?
Right, well with that, great I want to thank again Michael and Marco for helping out from RIPE NCC. Thanks so much. I really appreciate everybody being here. This will wrap‑up the Database Working Group. And we'll see you guys next year. Thank you very much.
(Coffee break)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
