Archives

Database Working Group
27 October 2016
3:00pm:

JOB SNIJDERS: People please be seated, we are about to start the Database Working Group session of RIPE 73. I see there is ample space in this room to accommodate all of us.

This is the agenda as far as we have developed it. We'll start with the welcome. Welcome to the session.

We will need to assign a scribe. And traditionally we force someone to do it, so Nigel, thank you again for volunteering to be our scribe.

The agenda as it stands today is, we'll have a little bit of discussion about the chairs of the Database Working Group, then Tim will give us an operational update. Peter will tell us more about the AfriNIC IR homing. And then Alex Band will provide us with a new insight in the user interface.

Do we agree that this agenda is sufficient for this meeting or does anybody in the room present that would like to add an item or remove one?

I have to say I cannot see any of you. So, if you have something to say just start screaming. Then we'll continue on.

Has everybody read the minutes that have been sent out after the previous session? Would anybody object to accepting the minutes from the previous session as they are distributed? I hear no opposition. I see no opposition. Thank you. Then, the minutes of the previous meeting have been finalised.

That brings us to our next presentation. The Working Group Chair selection and discussion.

The chairs have had some internal conversation about the direction in which the Working Group is moving and whether we all find it agreeable or not. And I have come to realise that I do not feel comfortable being a Chair of the database any more, as I think that my personal desires and the pace at which things move in the Database Working Group do not fully align, and I don't think it's reasonable to expect that that will change any time soon. As some of you may know, I'm not known for my patience and I feel that the Working Group might benefit from leadership which has more endurance.

I have also found it quite challenging at times to deal with the Working Group, this is something that frustrates me at a personal level and I do not find it easy to distance myself from this. And third, the lack of participation to get things done in the Working Group has also been a source of disappointment.

So, therefore, I fall to myself, I'll step down and life will be much easier. So, thanks, here is a potato. This does mean that the Working Group has some challenges ahead of itself. I would like to invite Nigel, because he also has a statement he would like to contribute.

NIGEL TITLEY: For some considerable time now, I have been wanting to step down partly because I am largely out of touch with the database these days because I have been in an operational role that required interaction with it for a long, long time. When we had the two new chairs volunteer and Wilfried stand down I agreed to stay on for a bit longer for a bit of continuity. I was proposing to stand down at this meeting. This would leaf Piotr on his own which we thought was probably not a good idea, so I'm willing to stay on until we can find one or possibly two replacements, preferably two replacements to support Piotr, but this is sort of early announcement that when we get volunteers, I will call my long association with the Working Group to an end I think. You'll have to find a new scribe. I have been scribing for this Working Group for nearly 20 years or possibly even longer, and I think it's probably about time to finish, so anyway... thank you all, and thank Job especially for the work he has put in for the work that he has put in in trying to get some sort of semblance of life out of the Working Group, I am afraid Working Groups move slowly, and maybe he'll come back in ten years and find something slightly livelier and I'm sure he'll be carrying on as a member of the Working Group, if not as a Chair. But anyway, that's what I have to say. Any comments? Any volunteers? Please make themselves known to us. We have a Working Group Chair selection procedure, it involves the mailing list, as it should. We'll be putting out a call for volunteers. Please, if any of you feel moved to answer that call, then please do so. Thank you very much.

(Applause)

JOB SNIJDERS: So as Nigel mentioned we do have a Chair election procedure. That procedure will be followed. A call will be made next week, if you are interested, respond to the call, and then I hope that soon we'll find more volunteers.

Next presentation please!

More than half a year ago we introduced a new method to try and accomplish work. We called it numbered work items. The idea was that by providing a more structured procedure to come to decisions and to discuss technologies to separate solution finding from problem definitions, we used this procedure. And I would like to go over the current numbered working items that are flowing through the Database Working Group.

The first numbered work item is a proposal surrounding proactive notifications if attributes, security or abuse related information changes. This numbered work item was introduced in mid‑May 2016. So far, this is information based on September 30th, there have been three messages on the topic from three participants. So, at this time, I do not feel comfortable to declare consensus simply because three people is a very small sample number to decide on a feature like this.

I think that if numbered work items like this one continue to collect dust, the chairs should remove them and no longer consider them an active wording item, so it is up to Peter and Nigel to decide how long they want to have this item listed but as it currently stands, the lack of interaction is a little bit worrisome.

Numbered work item number 2 is displaying historic information where possible. There has been some interest from certain parts of the ecosystem where they would like to research how things look in the past. So far, there have been ten messages, five participants, so that's lightly better number, but still I would urge the Working Group to take a look at this and either voice support for the problem definition or voice concern. Because, again, five participants for a far going feature like exposing historic information is, it's not too much.

The AfriNIC IRR homing topic has generated substantially more messages, even in the last few days there have been more messages and more participants on this topic. But still, as it stands, 40 messages with, say, 12 or 13 participants for such a big project is a challenge. Especially given that the current 12 or 13 participants in the conversation are not entirely in agreement with each other.

So, I would urge the Working Group to consider value of this project and make themselves known in their support or not support for this proposal.

The fourth numbered work item is a problem statement regarding whether there should be multiple status attributes or not within certain types of assignments. Four messages, three participants. That's not enough to move this forward. So, if you have interest in this specific issue, make yourself known.

Many out of region operators that expand into the RIPE region and start building a business here are prone to bring their own ASN to the RIPE region, NTT is a perfect example, we don't have an ASN that is specific to the RIPE region, we use 2904 everywhere. However, as it currently stands the authorisation model in the RIPE database is a little bit challenging for those who bring out of reach resources, for instance you have to create a duplicate aut‑num object in the database, which should be, could be a company of the aut‑num that exists in our own IRR database, and some have perceived this as not desirable to have duplicate aut‑nums laying around. So this numbered work item tries to define a problem statement that might help us resolve some of the challenges that non RIPE region networks have when they come to the RIPE region.

However, on this topic, there have been three messages from three participants. So, again, this is not a lot of activity and this makes it very challenging to move a problem definition like this forward.

Then the last currently registered numbered work item, this was an attempt by myself to try and capture some of the challenges we have in redefining the semantics of what fields or what attributes mean in the RIPE database because if an attribute means this today, and we do a software update and then it moves, then it means something different, or, if you consider each object has an accompanying schema, after a software upgrade, it would be nice if you can validate the object with the correct schema. So, I thought if we have a problem statement where essentially we recognise that over time objects can change and that software should be able to deal with that, to be able to pars it to know with which schema model they should pars it, then we can make the introduction of changes in the RIPE database easier because now we can tell software programmers, hey, if you just follow the versioning or follow this whatever method we come up with, then your software knows when it's dealing with an old style object or a new style object. And at the moment change is easier in the database we might see some innovation and less complaints that things changed and that people weren't aware of those changes.

So, that was the intention. However, it did not gain a lot of traction, so far three messages and three participants so it's a very low showup with that level of participation it is not possible to move this forward.

So, this brings me to a little bit of a challenge, because although on paper the numbered work item approach looks appealing, in practice, I cannot declare this a success.

Now, there are a few options and this really is for the Working Group to talk about. Am I just not being patient enough? Is it okay if numbered work items exist for a year or so and is that fine? Or, should we abandon this approach and go back to the previous method in which people can just mail stuff in and at some point a Chair declares consensus? Or... what do we want to do with the experience so far? So, I would like to open up the microphones and I would be very interested in hearing feedback about this topic. And Piotr, you have to help me because I cannot see anybody.

RUDIGER VOLK: I did not really raise my hand. Kind of, unfortunately, all the proposals that came up so far, were of a kind where I would spend considerable time in doing appropriate phrasing of objections, and well, okay, that's kind of not that favourite thing one wants to spend time on.

On the other hand, of course, discussion of what may be misguided and could use input from my wisdom, if there is any, kind of has been missed, but what I certainly found nice about the approach is that the attempt of defining a fairly well structured process for stuff so that one can track what's up, and has it made progress? Unfortunately to far, none. And I would have expected that later stages of the process would have been defined and executed in a reasonable and easily traceable manner which would have ‑‑ which, in my opinion, would be an improvement about, or compared to traditional process.

JOB SNIJDERS: You know. I do appreciate your approach when you object to something and that you spend considerable time piecing together the arguments. But I would say with the numbered work item approach, that argumentation doesn't need to be a book. The idea was, we define a problem statement. Do you identify with the problem statement? Yes or no? Is this a problem? No, yes... feedback, even make it a feedback, because in essence if you oppose the numbered work item you are saying, you are describing a problem that doesn't exist according to me, and that is very valuable feedback. Because, numbered work items can only progress if a large enough body of people consider it a problem and want to find and start digging for a solution. So, I would say at this stage, any feedback is welcome, even if it's a terse sentence and this of course applies to the whole Working Group. Make yourself heard.

CHAIR: We are not going to abandon the NWI approach, because it's working, however, because it's structured, however, we do not have problems which gather attention to such an extent that we can move with any of it to some solution. Is it what you are going to say or...

What I understand from you and Ruediger's little speeches, that we are not going to abandon this idea, because it works. However, the problems right now defined with NWI are not a problem ‑‑

JOB SNIJDERS: That is a fine conclusion. If ‑‑ unless somebody speaks up and says no...

AUDIENCE SPEAKER: I don't think we should abandon it straight off. Maybe some encouragement, maybe the odd deadline, whereby if there is no feedback by date X, then it will be abandoned, the work item will be abandoned because there's not been sufficient effort put into it will encourage people to send some replies. Sorry, Rob Evans.

JOB SNIJDERS: We night need to update the published procedure, because the current text states something along the lines of the first phase is a problem definition phase and the chairs within a few weeks will do something. And base on the that, some of these items are over half a year old. We can conclude that either the process is describing reality wrong or reality is not in align with the process. Maybe a few small tweaks that include more liberal that lines, but actually enforce that lines could be useful.

ROB EVANS: And maybe you know the odd chase up from the chairs that says, right, the deadline is approaching, make you're voices heard?

JOB SNIJDERS: Association can you repeat that.

ROB EVANS: Maybe the odd chase from the chairs that says the deadline is approaching, make your voice heard now!

RUDIGER VOLK: What is formally missing at the moment is the process path to declare something dead in a structured manner.

PIOTR STRZYZEWSKI: I think that we have heard your voice and Job is going to step down or have you stepped down already? Do you wait for one more ‑‑ show except me and Nigel, if there will be any candidates in the process of Chair selection, then you will try to collective decide how to tweak the procedure. It would be unfair, I think, that we'll do that only if me and Nigel right now. Yes, we will try to put definition along these lines.

Anyone else? No, okay. Thank you.

JOB SNIJDERS: Excellent. The numbered work item process will remain in place. Thank you for your feedback. I appreciate it.

Can I see the schedule please? Tim, I guess it's your turn.

TIM BRUIJNZEELS: Now I know why everybody has been saying that you can't see the room when you stand here. It's true.

In any case, let me get started on this one. I want to give a quick update on the operational side of things.

Since the last RIPE meeting we have done three releases actually, but the first one is not on the slide. There was a planned release for making the description attribute added small allocations. That was quickly followed up, unfortunately, because in order to do so we had to introduce business rules whereas before we had object editors and some of the things that were possible in object editors were still not possible afterwards so we fixed that quickly. Some people in the space of those weeks had an issue, but I think it was managed through tickets. There weren't that many, I don't know how many there were, but a few.

Then, since then there haven't been many public releases. Actually, in fact, only one that we just released. The main reason for this release is because we have been making changes in other parts, mainly in the user interface of the database, and specifically for supporting setting up reverse DNS, we needed some features than weren't there, like the ability to do a change in bulk and only have it go through if everything succeeds or rolls back, so some trust anchors actionality. This really also includes some other minor useful improvements like it wasn't possible to delete a sin tactically incorrect object. You have to fix it first and then delete it which is a bit annoying. And other thing is this status attribute on resource objects, and cannot change it, in order to change it you would have to create a new object, but if it's not set, then there didn't seem to be a clear reason why you wouldn't be allowed to change it.

This is in the release environment now. We were planning to release this to production before the RIPE meeting actually but Ruediger Volk, thank you for testing it Ruediger, is one of the few people who is actually testing, using our release candidate environment, which we would like, please do so because it helps us catch things before they become problems. So, Ruediger's testing reveals a potential issue, but it was related to the fact that the data in the release candidate environment was very old, it hadn't been updated I think since April a year ago. So, we resynchronised the data and we are making it part of the our process to do so with every future release because it helps people test better which is very important.

Ruediger you said you would e‑mail but can I quote you on this?

RUDIGER VOLK: Yes, in the end I was very happy with the response from the RIPE NCC on my complaints and indeed after the recent has happened, my colleagues in moderations did run a successful test. And to be correct, I don't run the test, it's all the glory of our ops people. Thanks.

TIM BRUIJNZEELS: Thanks for that. So, with that, I believe we will put this version in production on Monday after this meeting.

Unless of course something else comes up before then, but I don't expect so.

Now, on to other things that have been going on. I was asked to add a slide on this particular issue, although we haven't actually done anything with it ‑‑ well, no let me ‑‑ I'll get to that. It existed before ‑‑ we talked about it in the past, let me say it that way. We have person and role objects that were all maintained and they had been locked. So, why did we do this? We went down this road because all maintained personal objects can be abused or could be abused for social engineering. You could hijack them, you could put your own maintainer on them, change the name, pretend that you are associated with some network and approach us, well we are probably thorough enough to double check that, you know, what's the history behind this, but you could also approach other people out there. And that is a real issue.

Now, from a legal perspective, because we did have a talk with our legal counsel, we even talked to our Board about this, is that the RIPE NCC could become liable actually for third party damages if we know, if we could anticipate that damages could be done. We had a way to stop it and we didn't do it. So, that's why we locked and also refused to unlock these objects until now because, an unlock process is very hard to get right. If you make a mistake here and it has damages as a result, that's a big deal. So, we want to keep all the responsibility of making the ‑‑ because the problem here, let me rephrase it.

The problem here is that if you do that for the wrong reasons and people change their name they have hijacked successfully anyway and it happened without the people making the references to these person objects knew about it. So, what we want to do instead, is, let the people who refer to these objects update, so, if you find your own person object is locked, create a new one, get people to refer to that, as soon as there is no more reference to say your person object it will actually be deleted automatically. Now that is, I have another slide on that later on ‑‑ that is something we have actually done in the last half year. That process wasn't working before, it is working now.

Also, there is, at the bottom, I don't expect you to be able to read this, but if you look at the presentation online, there's a link there. We have a process where, on a case by case basis, people can get their personal data removed from the database. So if you have a real issue that people refuse to remove the reference to your person object, and therefore it wouldn't be deleted, there is a way to do that and it's actually the same whether you maintain it or not.

So, that's basically ‑‑ no, one more point. Sorry, because Denis did raise this recently, and implied that by locking these objects, the RIPE NCC would be more liable. Now, on that, again, we had ‑‑ I had contact with the legal counsel and when these objects were not maintained, the RIPE NCC was actually just as liable as when we have the lock MNT on these objects. So it doesn't change anything in that regard and more important point here to take away is that if there are avoidable damages and we know about it, then we would be liable if we didn't do that.

So, I hope that this explains the whole situation and I'd like to move on with the rest of the presentation which is mainly about a lot of the work that we have been doing.

So, one thing ‑‑ contact switch. This was close to being done at the last RIPE meeting but not quite there yet. This is the default maintainer. That's the phasing out of the object editors, as you may remember people had to use object editors to edit the organisation and the allocation objects mainly for historical reasons, we have now made it easier to just select the maintainer in the LIR port amount of this will be put on your organisational object and your allocation object is you can use the normal update mechanisms to maintain these objects as well. And so far 44% of LIRs have selected a default maintainer. So I think it's pretty popular.

Some quick stats on how people are updating the database. I had a similar slide over a year ago in April 2015 actually. We see that ‑‑ well, passwords are getting less popular, which I guess can be a good thing in favour of more secure access mechanisms so from mail updates BGP signing seems on the rise. For sync updates, a similar pattern. For the rest and the web, that's basically we have a rest interface but our website uses the same interface which is kind of difficult to differentiate between people using both, but still password usage has gone down and SSO, so single sign on usage, has gone up quite dramatically since we made the changes of making that much easier.

Now, another thing that may not be so visible to this group but whilst we are keeping busy, I can assure of that, running the operational side of things, we're not short of work. One thing we have been focusing on recently is continuous deployment. This is, if not best, definitely very good practice in software engineering, that you build a release and essentially you test this release in various phases but you test the same thing and you automate as much as you can. So that means in development environments, acceptance environments, even before it reaches a release candidate environment, but ultimately the goal is that you can essentially with the push of a button have decision points and say okay this version is good to go to the next phase.

It really helps us close the feedback loop quickly on features, but also if bugs are reported it makes much easier to add use case tests for that and quickly verify that something works and then also quickly get those things into production, because currently a manual process takes quite a while to do so, to get these things done. So it's a very useful thing to spend sometime on.

This is going to be the major part of the remainder of this slide. I can already give you a spoiler alert, and we have done a lot of usability improvements. Some small improvements like inter auto complete, authorisation, prompting for authorisation for a parent object when you create a more specific INET num. We are currently working on recert DNS support and this link will actually get you to the work in progress of that in RC. Just to be clear, we don't intend to release the website of this work until it's a more feature complete, but Alex will talk about that in a lot more detail later so I would ask you just wait until he talks about it and it will be clear.

In any case you can have a look though if you go to create the domain object there, then you can already have a bit of a peak at the thing.

Now, other things: Alex has been tweeting a lot. So, the status values... it may seem like a small thing but when you look at the errors that people run into when they are updating things, we have statistics on that and there is quite a few cases where people just have no idea about which status to chose for an INET NUM for example when they create one and simply limiting the available options based on the apparent object helps a great deal. It sounds like a small trivial thing, and maybe in a way it is, but it really helps people use the interface much ‑‑ better and with less frustration.

So, another thing is that we already had a remark saying okay, this is the abuse contact for some resource, what we have added to this is okay, this is the organisation object for this resource. So it could be directly on this object itself but it could also exist in the hierarchy as you probably know. In that case we chase that hierarchy and we find the appropriate organisation for you. So that's linked to the actual organisation object.

Then recently, we also started highlighting, for the objects that are shared, so, organisational object and allocation objects and assignments that are done through the RIPE NCC, the RIPE NCC is actually maintaining certain parts of that object and other parts are being maintained by the LIR or the end user of these objects. And we have made it more clear now who is doing what. So, what's not visible on this slide, but what we have added as well is a learn more link where there's a bigger explanation about how this all works with the responsibilities. But, again, it's small changes that we think will really help people understand the user database better.

Now, this is a bigger thing, I suppose, in a way, or more fundamental thing from a data point of view at least. We have rebooted the cleanup unreferenced objects process. It wasn't working for a while, mainly because I think we took ‑‑ our approach was well, we tried to be perfect, and it's quite hard because you get into graph theory and problems like how do you identify a set of objects that is no longer really relevant to the resource side of the database and hasn't been for a while. So, what we went for instead is that ‑‑ because maybe I should have started with that, we have the data protection Task Force a while ago already concluded that we should not keep personal data in the database that is not necessary, right. If it's there, because it's associated with resources it has a reason, then if it's not then we should get rid it have. If you try to do it perfectly it's hard. We have started in more pragmatic implementation since 6th September so we just focus on person role organisation and maintainer objects. We delete it if it's over the 9 to days and they are also not reference bid any other object, and, they are not referenced by any result related object in the last 90 days. And what didn't fit on this slide is but yes, if there is a person maintainer pair or a roll maintainer, the situation, we also detect those.

So far... we have delete the quite a few objects this way, very little response to it actually, so, I think they were really unused.

That brings me to the end of my slides actually. The future: We just had a discussion of course about number work items, etc. And I would really like to see things move forward in the Working Group. But that being said, we are keeping quite busy. We have an operational side to run of course, there's servers to maintain, there's things to do, and if there are issues there and it's definitely our first priority always, then there may be requests coming out of this Working Group or because of policies, they usually go right at the top of the queue as well. But even when those things don't happen like I just showed, there is a tonne of stuff that we can do and we have more than enough ideas going forward. So reverse DNS is something that we are currently focusing on and I expect to have something that we can release quite soon. Other than that, we'd like to look into personalised authorisation again, we had discussions about that a while ago, and basically, last year Job actually sent an e‑mail to the Working Group saying why don't you release 2 RC so that we can have a look at it. We haven't done so yet because mainly we found that people are having a lot more issues with reverse DNS and with setting up INET NUMs properly, so those things I just mentioned actually, they seemed to cause for issues to people, so that's why it got slightly lower priority.

We still like very much to continue the work because it will enable us to present a really good view to users logged into the website. We can easily say to you okay, these are your resources and what do you want to do with them. So, things that you can think about there are, we can make it easier to manage IRR objects for example for RPKI if you know we present an interface where we tell you these are the announcements that we see for your space and do you want to authorise them yes or no? We could do similar things for IRR. Bulk changes are things that are possible. The query interface can definitely also use some of ‑‑ well there is no shortage of ideas, and, if you have ideas of course we are always happy to hear your feedback as well.

So, that brings me to the end actually. So I would say, any questions or comments?

AUDIENCE SPEAKER: Ruediger Volk, Deutsche Telecom. For any work that's going to effectively change the authorisation schemes, I am very reluctant and I think ‑‑ well, okay ‑‑ going to our Cs is not going to be helpful, we actually have to scrutinize the conceptual models and authorisation is really critical. I'm not completely sure whether the things, the bullets that I was seeing actually had some dangerous stuff in it. So, let's stay with the abstract thing.

Another point going into details. If we could go back to your slide with the person object management. So, this one...

I wonder whether I'm really understanding the third bullet from the bottom. "Maintainers of referencing objects for persons are responsible for updating." Does that mean that you will implicitly authorise ‑‑ because that would be opening a huge gap.

TIM BRUIJNZEELS: Sorry, I realise now in my efforts to save some space on a busy slide this came somewhat ambiguous. What I mean with this is maintainers of referencing objects are responsible for updating their references to other person objects instead. If the one that they are referencing to is no longer good. But another thing to note actually, I don't know the date by heart, but these objects that had no maintainer have not been updated for years, many years, and in many cases actually the name and e‑mail of address of this person object may be perfectly valid so there may not be a direct reason why you would have to update. If it's still okay, even though the object is locked, it may still be fine. So, that's why I wouldn't advocate processes where we try to reach out to many, many thousands of maintainers and objects, holders, to update things that may actually be perfectly fine.

RUDIGER VOLK: Well, because authorisation is critical. The need for updating the maintainer actually I would think is a real thing even if the e‑mail address and the place of living and so on hasn't changed.

PIOTR STRZYZEWSKI: I have a question. Could you go forward two slides. I have a question, do you think that this increase in ‑‑ decrease of using the passwords and increasing using the other methods is because of the increasing number of LIRs, like, 2,000 of them joined the NCC from last year, so is it because they are new players and they are not used to using passwords and maybe Rumey is doing a great job with the training and so on. So, do you think it's because of that or do you think it's because people want to use more advanced authorisation method than MD5?

TIM BRUIJNZEELS: It's hard to say. I think it can be a combination of those things. What may also be a factor is that since April 2015 we had the issue where we had to reset passwords for which hashes had been publicly available before, if you remember that, that happened after that. And in that process, we really encouraged people to use SSO accounts, and BGP instead.

Actually, what I forgot to mention just now about, incidentally I was going over issues on a GitHub site where we have the WHOIS code and people report some things there and somebody there actually raised the idea of using a BGP and rest updates as well which something we may want to look at as well. I asked this person to bring it to the Working Group and they said they would. But that may actually open a wider discussion in this Working Group about where do you want to go with authorising tools, and maybe it's a good moment to rethink that a bit. But BGP seems like a perfectly plausible way to me that that could also be allowed there, but currently isn't.

PIOTR STRZYZEWSKI: Okay.

RUDIGER VOLK: A little bit off from your presentation but on the change to different modes of authorisation and actually access to the database updates.

With the good old mail updates, the parties that get notifications about updates used to get somewhat reliable identification of who was trying or doing something that is essentially completely lost with the web updates and I very seriously have to ask for that getting fixed because when I get ‑‑ when I get notifications about unauthorised attempts to do something, or a customer is trying to update something and I need to get back to them, or, even in our large organisation, someone is trying to do something and I don't even know which of the departments has been messing around, we really need to get that fixed and please put that very high on your priority and successfully so please the

TIM BRUIJNZEELS: Yes, thank you for reminding me because it actually is, but I should have put it on that slide. Currently it's actually planned that we work on that. We have the stories as we call them, the work items worked out for that internally, but what he plan to work on it after we have done a release for reverse DNS, so it is planned to be worked on quite soon actually.

PIOTR STRZYZEWSKI: Okay. Thank you for your comment Ruediger and your answer to that. There's a comment from the chat.

AUDIENCE SPEAKER: Jabber, I have a comment from Denis who used to work for the RIPE NCC. He has said here that the RIPE NCC dropped passwords from the web updates and forced people to use SSO to use discussion, so you can't use this as an argument about people's preference.

TIM BRUIJNZEELS: No, we did not drop passwords from the web updates. You can use passwords. We just make it the default or make it very easy for you to say from now on I'd like to use my SSO account instead. But if you don't want to do that, you can use passwords.

PIOTR STRZYZEWSKI: I hope that answers the question. I have one more. Could you go forward to the end of your presentation?
I have a question, and I would not expect that you can answer that question, but this should arise. There is a very long list of improvements, a very short, as I understand it, you have a shortage on staff. So, maybe we, as a group, as a Working Group, should insist on NCC to hire someone to speed up the process, to speed up the development of the database? As I said, I do not expect that you answer that question, because but that's something could I bring under the discussion, maybe you should contact there... a managing director or whoever is sitting DPS Andrew

AUDIENCE SPEAKER: Andrew de la Haye, I am not the managing director but close to him. Thank you very much for your comment and I'll bring it forward to Axel and the board to discuss this specific item being requested. Thank you very much.

PIOTR STRZYZEWSKI: Does anyone want to comment or ask a question? Okay. Thank you Tim.

(Applause)

PIOTR STRZYZEWSKI: I am one of the co‑chairs of this Working Group. And I would like to present an update on the AfriNIC IRR homing which is called also numbered work item 3. And so I will shorten the name.

As you previously heard from Job, if we compare to the other NWIs, there was a huge participation in the discussion, so it was about 30 mails, so, if we compare that to the three mails for example for NWI number 2, that's huge, that's something which is incomparable, and there was a lot of messages, so, there was a heated discussion, but honestly speaking this is the only NWI which reaches the solution definition stage, this is the only one we moved forward somehow.

So, I was asked to make an update about it. There is a proposed solution by the RIPE NCC as requested by the community. And we are, right now, struggling, if we have or have not a consensus and as Job said previously half an hour ago, participants in that discussion, although there was something like 10 or 11 of them they are not making any agreement, they don't agree with each other about do we have an agreement on the proposed solution. So, although AfriNIC is happy to cooperate and at least I perceive that from the AfriNIC e‑mails, we are not in the position when we can call the consensus.

The proposed implementation is quite simple. We want ‑‑ it was divided into four phases. Phase number 1 is the communication phase. We can communicate, reach out the operation, get people using AfriNIC IRR. This should be done because AfriNIC is encouraging people to use their database. They build the tools, they encourage new members and current members to use that tool. They contact, as far as I know, they contact the users of the RIPE IRR, to move some objects to AfriNIC.

Then there's the phase number 2, in which there will be, prevent new AfriNIC Route‑6 objects creation in the RIPE database. The modification of existing ones will be allowed, but there will be no possibility to create a new one and of course deleting will be encouraged, so in this phase, we will be also communicating if we will ask members to delete the objects from RIPE database, that's kind of communication basically.

In phase number 3, AfriNIC is going to, according to this proposal of course, AfriNIC is going to import the remaining objects. And then will work with its members, if there will be any conflicts. There was a discussion in this week that there is, there are some objects which can conflict, but there is not a huge number of them. Since the AfriNIC IRR is quite young database.

And in this phase, AfriNIC members can easy delete or not identify objects after import so it's up to them what this do if they have objects.

And at the end in the phase number 4, there will be a deletion of the only Route‑6 objects in the RIPE database, and basically delete AfriNIC aut‑num objects if they are no longer in use. But as I said a few minutes ago, we are ‑‑ this is the proposed implementation, proposed solution, and we are not in the phase in which we can decide that there is a consensus on that. So, I have discussed it with Job and what we would like to propose is to make more kind of advertising kind of PR and kind of research. When I said kind of advertising peer PR, I would like to ask the NCC to make some more materials, both the RIPE NCC and AfriNIC to make more materials, I encourage them to do so, about how the transition should look like and what to do if there's a kind of conflict, what could be broken, when and where things would happen and who to contact in case of any problems. And when I said that kind of research, that means that both RIPE NCC and AfriNIC would be encouraged by us to make a kind of research to check how things could go worse in case of something will be screwed up.

So, that's the update. We are not moving forward. We are not abandoning this project. This project is, to some extent, ongoing, and there is an interest from the community.

That's all I think. Any questions? Ruediger. Rumey.

AUDIENCE SPEAKER: Rumey, RIPE NCC. Just to follow up on what you said we could very easily produce either video or maybe do a webinar to explain to people or pull them in and show what the migration would look like.

PIOTR STRZYZEWSKI: You are very good at that, so, I expect you ‑‑

RUMEY: Thank you, I shall tell my boss.

PIOTR STRZYZEWSKI: What I encourage you is to contact with AfriNIC that they will at least link your videos or make them all together with you or something like that. Ruediger?

RUDIGER VOLK: I was irritated about the proposal, the initial thing, and I'm irritated right now with the presentation with the observation. A year ago we had someone from AfriNIC here to explain what AfriNIC is planning. And I'm really surprised that we did not first solicit a status report from AfriNIC and a report about what their plans are and what they have achieved and ‑‑ well, okay ‑‑ at this meeting, I think the technical staff of AfriNIC is not here, but there are representatives, and I am really disappointed that it seems we didn't ask for them to report. And my understanding of some of the controversial discussion seemed to be related to that ‑‑ well, okay ‑‑ this looks like we want to do something about AfriNIC and ‑‑ well, okay ‑‑ the times of the white man's burden are long passed. I haven't evaluated the current proposal, but I really would like, and find it appropriate, that the process for moving stuff to AfriNIC should be driven and directed and at least with explicit feedback of the people there.

PIOTR STRZYZEWSKI: Okay. So just to comment on that. I'm sorry for your disappointment. That's probably my fault because I was responsible for making an agenda. I didn't think that it would be useful or appropriate or whatever word I can use to ask AfriNIC staff to present the status of that. Sorry. I will note that to do that next time in Budapest if I still will be the co‑chair because we have to make a call for co‑chairs ‑‑ and you know that.

The other thing is that yes, we know that there are representatives, but ‑‑ even if I asked them, I'm not sure if they will be able to present that, but that's another story. And you said about the status of things from the AfriNIC staff and that they should ‑‑ that the process should be driven by the AfriNIC staff. I think that mail from the AfriNIC staff on the mailing list clearly state that they are happy with this process, which is ongoing in the RIPE region, or maybe I am missing something.

RUDIGER VOLK: Well, was the statement that they agreed to what the Europeans have decided?

PIOTR STRZYZEWSKI: It's not a Europeans RIPE communities across the globe, so sorry. Tim?

TIM BRUIJNZEELS: No, we didn't initiate this. This was initiated by the Database Working Group on a request by AfriNIC actually, who was speaking, I trust, on behalf of their community. So, this is not something that we just want to do as, you know, the white man in Europe. Definitely not. And I really ‑‑ yeah ‑‑ okay... maybe that perception existed but I have really tried to address that. Like, a while ago, I don't remember when exactly, but one of the e‑mails I sent to the list was that I feel that's what's clearly needed is that the Working Group re‑states that the Working Group wants this and that AfriNIC re‑states that this is actually what their community wants. Now, it's been a while, it's been a bit slow on the mailing list, I admit, but I have also asked Daniel Shawl to comment on this because he is one of my peers at AfriNIC, and he did so recently. I can only trust that when he says that this is something that AfriNIC wants and that the AfriNIC community wants, that that is true. They have always been saying that to me. I think they have always been saying that here. So, I would really like to move beyond that perception. That is really not what we are trying to do here. We are just trying to facilitate.

PIOTR STRZYZEWSKI: Thanks Tim. That's a very good comment, and Job?

JOB SNIJDERS: I would also like to remind the Working Group that AfriNIC is possibly just the first out of a series of RIRs, the same principle applies to APNIC objects in the RIPE NCC, to ARIN objects in the RIPE NCC. So, the cultural background really has nothing to do with this. It is more what would be the highest yield in terms of improving routing security. Because that's where this originated. The AfriNIC prefixes and APNIC and Eseatra in the RIPE database are not verified in a way like the RIPE prefixes are and that's what it boils down to. We wanted to improve the quality of the data and since AfriNIC is tasked to manage the AfriNIC space, they are the perfect location and maybe this was naive to think that improving routing data is an admirable goal, but I have to disagree with your view where you ‑‑ we're not trying to push stuff to another region and force it through their throats. I think there's benefits for both RIPE participants and AfriNIC participants in terms of routing security.

PIOTR STRZYZEWSKI: Thank you. Is there any other comment or question? I don't see anyone waving. Okay. So thank you very much.

And next one is Alex. The stage is yours!

(Applause)

ALEX BAND: It's my turn to step into the void and see lots of blackness.

I'm Alex Band, I am the product manager at the RIPE NCC. And together with Tim and together with the database team, we make things. And we make a lot of things.

This is what we did in 2016. I just went through all of the announcements, and all of the functionality that we built and I was actually kind of surprised there was such a long list of improvements that we have made to the RIPE database, and that is all done with the feedback that we get at RIPE meetings like these, at regional meetings, at member lunches, and the things that we hear from training services, the feedback that we get from customer services, for example, in terms of the amount of tickets that they get on a certain subject, and it really helps us, it really enables us to create a better database with a better user experience that is easier to use for everybody. And it's especially helping newcomers, we get so many new members and if I look at the sort of the on boarding process that we have created, everything from signing up to creating a RIPE NCC access account, to going through all of the paperwork, to become a member, once you have paid your bills we actually create objects for you in the RIPE database. We have come a really, really long way. And it's becoming really simple for new members to get started with the services that we offer. And I think that is a great achievement and we would like to continue this so therefore I am also very grateful to Piotr for suggesting additional staff, because there is so much that we can still do to make all of these different processes easier.

And what I want to use this talk for is to show case one of the work flows that we have been attacking over the last couple of months, to help users set up reverse DNS.

So, this is an overview of all of the error messages that users of the web interface got thrown in their faces in the last 30 days, and in the last 30 days, the domain object has 7100 error messages. That's a lot. That's stunning. That is actually 55% of all of the error messages. So 55% of the error messages thrown in the web interface are because of a single object. And this is how it looks.

We just give you a form and we give you 7 fields to fill out, and people are simply not that familiar with the concept of reverse DNS. So, they go like okay, this is something that I apparently have to do. I'm going to try this out. I'm just going to look at all of the help text. I am going to read the documentation. I'm going to take my prefix, create reverse notation out of it. And I'm going to fill it in. And I hit submit and then we throw an error message in your face, and this is a really simple example. We can also throw like seven of them in your face. And then we had to go back and then the user gets to rinse and repeat and try again and try again and try again until they either get it right or they just give it up. Like, you know, I can run my network without reverse DNS.

That's just not a user experience that you want to offer. And you go, where do we go wrong? I mean, all of the documentation is available on the website. We tell people what to do. But people just sort of end up in the RIPE database and they try this, so, we were like, okay, we can do better, we can do way better.

So we came up with a work flow based on the most common error messages that reverse DNS throws. And this is in order of importance. And by far, is no name server found at child. People tried to set up reverse DNS. They tried to create a domain object without even configuring their name servers. I go okay, it doesn't answer any queries over TCP. The server is not authoritative for the authority you are trying to delegate. People just filling in one name server. That's also a thing. You go like why is that even a problem? We give you two fields. But, it's a thing. People just fill in one name server and then hit submit and then they get this error message and it even says so in the help text. It says include this attribute twice, but people don't.

So, then you go okay. We can iterate through this, we can come up with a new design, so we got an UIUX designer in software engineer and we have talented engineers and you sit down and come up with a new idea and approach for doing this. This is what we have done over the last couple of months.

The first thing we do is we give you a splash string before you even get to the part where you fill in the information. In the screen we tell you you first have to do something on your side. You are to configure your name servers, you have to know something about BIND and if you don't, then maybe you should get somebody to help you. Stuff like that. So it gives you all of the steps. So we lift that had out of the documentation. We linked to the documentation, but the main points we give them to you in a splash screen saying make sure you have two servers that are authoritative for the zone. Make sure they are set up in different subnets, etc., etc., and if you have read all of that and you understand and you go, we give you a field. We give you one field, because we want you to fail early, we don't want to fill in seven fields, then fail, go back and do it all again. We just give you one item to fill in. After the maintainer you fill in the prefix. If you fill in the prefix incorrectly it will just tell you straight away. It does that in realtime. So as soon as you have completely entered a valid CIDR prefix, it will do validation to see if that is even possible to do.

And if you have done it correctly. You get the fields to fill in the name servers and it's two of them and again, now we do, together with Zonemaster, we do from the RIPE database we do a query, you have it validated by Zonemaster and it will give us a reply back to see if this name server is actually online and it does that again in realtime.

So the first one, it gives you server looks okay and for the second one I filled in this, and it goes checking name server, checking name server, and it goes no, that failed. I'm sorry and you simply don't get anything else to fill in. And as soon as you get it right. It goes hey, this is great, because now, I have a prefix, I have two valid name servers, and all of the reversing that you had to do manually, we just now do that for you. So this wizard doesn't only allow you to create a single domain object, you can create like 128 of them in one go. You can set up reverse DNS for your /17 and just go for it. It's all possible now.

So, as soon as you have that, as soon as you have the reverse zones you get to fill in all the other information and there you see like the little bits and bobs, the little tweaks that we have made to the user interface such as auto complete. I will just enter my name and it will give you my NIC handle. It is stuff that people expect in 2016 in terms of functionality. Every website is capable of doing this nowadays. And I think the RIPE database web interface should be no different. So we have tread this additional layer with auto complete and as soon as you have filled that all in, you are good to go.

Now, the functionality that I have showed you, these are screen shots from the RC environment. But this is live. And we really, really, really, really want you to test this. We really don't want Ruediger to be the only one using the release candidate. Could you please all do this? Because, the feedback that we get on this is so incredibly valuable because it helps us shape these products and iron out all of the bugs and corner cases and quirks that we have, will undoubtedly have, we try to catch all of them. We do a lot of Q A in order to make sure that we get it all going and get it perfect before release it to production, but getting these things early is better for everybody, really.

So, it's a work in progress, as it clearly says. But there's more stuff coming up. Because there is a couple of problems of course and as I mentioneded, your capable of setting up reverse DNS for something like a /17 and then you go into design problems. You go, if I send that to the queue for Zonemaster and it has to check all of that, how long can we reasonably have people people staring at a web page waiting for it to be done. So, we're still working on solutions for that, so if you are going to try this right now, for a very large prefix that needs to be cut into a /24s, probably it's going to either time‑out or give you problems. So when you test this, do it you know with a bit of a smaller range, that sort of makes it manageable.

We also don't want to give you the entire list in the screen‑shot that I showed you before, let me just go back ‑‑ it says reverse zones and now it has two, but when it has something like 128 or 64, it becomes a really long list to scroll and we really don't want that. So, we just say, reverse ‑‑ for four reverse DNS zones will be created and it gives you the starting and ending range, you can click on that and give you a POP up with a nice list. The other thing that we still need to do is all of the error message as now grouped together but we want to make them in relation to the specific domain objects that you'll be creating, so you could actually have a lot of the domain objects correct if you are doing a large group and some of them will though you an error message and we'll just tell you these are fine and in all of the others you still need to do something.

They can re‑try, you can refresh as often as you like. When you are all done you can just go and submit it. So this is stuff that we still need to create. And we'll be work very, very hard on that over the next couple of weeks and if, in the meantime, you find problems with the basic functionality that we have created up to now, please, please, please let us know, because it really helps us make the products that we deliver better.

If you have any questions, now is the time. If you have any feedback, I'd love to hear it. Everyone is trying this in RC now, aren't they?

PIOTR STRZYZEWSKI: I didn't see anyone waving, so...

ALEX BAND: All right. Thanks very much.

(Applause)

PIOTR STRZYZEWSKI: So, that brings us to input from other Working Groups and Task Forces. We are quite on time. I want to point you to the presentation which has been presented both in the Plenary session and in the Anti‑Abuse Working Group about the correctness of data with the RIPE database, or generally speaking in the WHOIS database, it was presented by the person from Europol. Just, if you are interested, see the recordings and maybe this will be somehow discussed ‑‑ somehow discussed later on in the either the Anti‑Abuse or other Working Group. And Brian has a comment on that.

BRIAN NISBET: So, I think just to very quickly say on that, there is a very nascent proposal from Greg from ECP from Europol is looking to work on in regards to the requirement for accurate data of clients of LIRs in the database and suballocations and all the way down. So, what I have asked for is for people who are interested in working with him on that, to contact me, or put it on the mailing list and then importantly we'll figure out which Working Group this conversation should take place in. It's very possible that it should be database rather than Anti‑Abuse, but that's something that I'll talk to the chairs of database about. It's even possible it should be Address Policy, we don't know right now. So, we'll work that one out. But if anyone here is interested in working on that, please talk to me and we'll set up a small group to work with the EC3 folk and other LEAs on that proposal, thanks.

PIOTR STRZYZEWSKI: As far as I know there is know other input from other Working Groups or Task Forces so that's the last item.

Just any other business, and I see a person who is waving their hand. So...

AUDIENCE SPEAKER: Yes, Paulo Maroney, I am co‑Chair of the Routing Working Group. I have seen a lot of the effort and work to improve the quality of the database and I want to state that this is not only useful for Europol but is also useful for in in daily operations. And if I'm allowed to add a personal statement, you should not be disappointed by the lack of noise on the mailing list for such items. In my opinion, this does not mean there is lack of interest. It only means that this work is useful and appreciated by everybody and simply people are too busy just to say thanks so just go ahead.

PIOTR STRZYZEWSKI: That's a very valid point. Thank you. And right now I really don't see anybody waving hands. Which brings us to the end of this session.

Quite on time. We have still four minutes left, and I would like to thank you Job for his work as a co‑chair, and I would like to ask you for applause for Job.

(Applause)

Thank you one more time. And I would like to see you all in good shape in Budapest next time during the RIPE 74 meeting. And I would like to also to encourage you to be more active on the mailing list. Thank you. And see you.

(Applause)

LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.