Archives
Database Working Group session
6 November 2014
4 p.m.
CHAIR: Ladies and gentlemen, friends and colleagues, welcome to the Database Working Group during this RIPE meeting. My name is Wilfried Woeber working for Vienna University, and this is going to be the last time that I'm going to invite you to the meeting as you are going to find out by Nigel's presentation just after we go through the preliminaries.
To start with, there is usually the administrative small things. Like the welcome. So, you are more than welcome to chime in to each and everyone of the topics we are going to discuss. And Nigel has again volunteered to take notes and to circulate the draft minutes. Thanks for that. This has already become a well‑known tradition, so, again, thank you for that.
The next thing is to finalise the agenda. The Version 2, the most recent version was circulated today in the morning, with a slight delay due to the fact that I'm suffering from some e‑mail hiccups, so, my mails were not directly accepted by the mailing lists, so there was a slight delay, but it's on the website already, thanks to all the people working behind the scenes on the logistics updating the website and that sort of thing and thanks to the people here from the audio‑visual people here supporting us.
Is there anything on the agenda that you want to see added or modified or dropped? Because if there is not the case, then the draft agenda, the proposed agenda is going to be the list of things we are working along.
Next thing is the approval of the minutes, and unless I'm wrong, these have only been circulated only a short while ago, so I think we are not in a position to ask for any comments or corrections or to approve them today. I presume that there is another two or three weeks going to be time enough to let you chime in on the Working Group mailing list and if anything is wrong or needs modification, then please let us know. We, or the set of co‑chairs after this meeting, will then take action and declare the minutes as final, I guess.
The next thing here is the review of the action list. And this is usually also Nigel's deal, Nigel's tune, and I think there are some slides for that one as well.
AUDIENCE SPEAKER: Somebody in the chat room says that they would like to have something added to the agenda about geolocation, is that possible?
NIGEL TITLEY: This is the quick action point roundup, which I usually do at this time. Action point 67.4, which dates from two meetings ago, take the issue of geolocation to the RIPE NCC Working Group, as it doesn't seem to be heavily used. This was ascribed to Wilfried, this is ongoing or?
WILFRED WOEBER: It's going to be on the agenda.
NIGEL TITLEY: We'll do it on the agenda. 67.7, again on Wilfried to check this the Anti‑Abuse Working Group has specified he what's to be been with mail to the sent to the abuse contact and possibly it's format.
WILFRED WOEBER: Actually, I didn't check, unfortunately I wasn't at the Anti‑Abuse Working Group, but I would propose to keep it open and to keep it ‑‑ and I'll try to follow up on that off‑line.
NIGEL TITLEY: To bring to the attention of Routing Working Group the fact that routing data as recorded in the database is very poor.
WILFRED WOEBER: That's a pretty old ‑‑ well old, a seasoned one, put it that way, and during this meeting we actually had a presentation by Job which is slightly relateed in my view, called the presentation thingy. We had another thing happening, I think one or two days ago, with IP address hijacking or supposed IP address hijacking due to the fact that it's easy to record route objects in a RIPE database for IP address blocks where the RIPE registry is not authoritative for the IP address space. So, my feeling is that this is probably a very nice reminder, but my feeling is that we should sort of tackle that as a broader issue, sort of how do we actually improve the credibility and the quality of the data in the routing registry. Is anyone actually having this ‑‑
NIGEL TITLEY: Would Job be willing to take this on?
JOB SNIJDERS: What is your question exactly?
NIGEL TITLEY: Well, the question is this action point. Okay. Alexander Azimov, a couple of meetings ago, gave us a presentation about the quality of routing data recorded in the database, and there was an action raised to actually bring this to the attention of the Routing Working Group. It's really a Working Group Chair liaison type job which is why Wilfried ended up with it. Would you be willing to take this on or not?
JOB SNIJDERS: Sure.
NIGEL TITLEY: Okay. Good, in which case we change the owner to Job and go on with that.
Okay. 68.1, remove the referral‑by attribute. There is almost certainly a presentation on this and in any case I think it's been done. Yes? This particular action. Tim? Referral‑by? It's been removed? Has been removed? Is being removed?
AUDIENCE SPEAKER: Tim. There will be a presentation later, we have a proposed phases to remove it.
NIGEL TITLEY: Right. It's being dealt with later. Right. That's it. Shall I stay up here or come down?
WILFRED WOEBER: Please just continue as you are on the stage anyway.
NIGEL TITLEY: Okay. Working Group Chair selection. Every Working Group at this meeting has to have this mandatory presentation. This one is going to be very short.
The Working Group Chairs collective decided that all Working Groups should have a procedure for particularly refreshing their chairs. It must be written down. In other words, documented. And the deadline, strictly speaking, is the end of this meeting.
For this group, I took the liberty of writing down some principles and writing down that proposed procedure, and my principles are that selection should be done by consensus, it shouldn't penalise people who can't attend meetings; so, in other words, the selection should not take place actually at a Working Group physical meeting. There should be no voting, because we don't do things by voting, and the procedure will come into effect after this meeting, so that we hit the deadline, okay.
This is my proposed procedure. And it's actually been hijacked by a number of other Working Groups so it's obviously reasonably popular. A call for interested parties is made on the Working Group mailing list at yearly intervals, so we get the refresh, so potentially we can refresh all chairs every year. Potentially, I don't see that likely to happen. Interested parties have two weeks to make their interest known. So basically we issue a call for interest, potential candidates respond within two weeks on the mailing list, the existing Working Group Chairs issue a call for discussion, just like as if it was a policy proposal, Working Group members express their approval or disapproval of the presented candidates, being as candid as they like, and after two weeks, the chairs declare consensus, exactly as they would do for a policy proposal.
Now, there are a maximum number of three co‑chairs. This is actually an external rule imposed on us by the Working Group collective. If at the end of the discussion there are more than three proposed Co‑Chairs, a call is made for any of the candidates to gracefully withdraw. If they refuse, then the names are put into a hat and the first three take on the role of Chairs for 12 months. We actually do have a hat.
Scope: Discussions as to colour, shape or ownership of the hat are out of scope.
This policy ‑‑ this proposal was distributed on the mailing list two or three weeks ago. It received five expressions of agreement, strong agreement in some cases and none against. Therefore, I'm assuming that we have consensus on this procedure, but if anybody would like to stand up, Rudiger, and talk about it.
AUDIENCE SPEAKER: Rudiger, sorry for that grumpy ole' grey beard standing up again. Just for my understanding, what parts of the proposed procedure are existing practice and which parts are new?
NIGEL TITLEY: I don't think we have a hat in the existing proceedings.
RUDIGER VOLK: And which year did we have advance queries for interested candidates?
NIGEL TITLEY: We haven't had yet because this is a proposed proposal and not an existing one.
RUDIGER VOLK: So there are parts in the procedure that are new.
NIGEL TITLEY: The procedure is entirely new?
RUDIGER VOLK: Okay, because I was told a couple of minutes ago that the only thing that is happening about these processors is writing down what we are doing.
NIGEL TITLEY: No, that is not the case. Who told you that?
RUDIGER VOLK: Well, people who really should know. And kind of and telling me the way I should go away with questions about the way these proposals and taking up agenda slots on all the Working Groups came about.
NIGEL TITLEY: This agenda slot would be half the length it is if you had not stood up.
RUDIGER VOLK: Kind of... there has already been one session where this agenda item was at the end of the agenda and I walked away because I do not want to waste my time, but kind of... as I have been mentioning in previous sessions, similar topic, I think there are concerns about the way this has been processed.
NIGEL TITLEY: I could understand that. Any other comments?
WILFRED WOEBER: Noted.
NIGEL TITLEY: Any other comments? Is Randy here? No, okay. Can I take then that at least for the present this procedure is agreed? Rudiger?
RUDIGER VOLK: Just one other note. It seems that other Working Groups do not know the time limit that procedure has to be agreed by end of this week.
NIGEL TITLEY: Wouldn't it be nice to have it agreed though?
JOB SNIJDERS: I agree with the proposal, as I said on the mailing list, and we can change it at a later point.
NIGEL TITLEY: We can, we can change it at any time. I'd just like it out of the way because it's occupying a disproportionate amount of time and effort in this and all Working Groups. And for the record, I didn't particularly ask for this to be done. Okay? So I suggest we go ahead with this.
Right. Thank you very much everyone.
Second item in this particular slot is that Wilfried has announced the fact that he's resigning. Wilfried has steered the Database Working Group since its inception, as I understand it, which is a very, very long time. And I think we really ought to say thank you very much indeed to Wilfried for keeping it going for so long.
(Applause)
He's done a marvellous job, he's kept it going, he's produced agendas for God knows how many years, and thank you very much indeed Wilfried.
Finally, we have two additional chairs who have expressed an interest in taking on the job. And that's Job Schneider, Peter Strovinski, they have both volunteered, or been volunteered, with the agreement of this meeting, I would suggest that we adopt them for the next year, we co‑opt them and thank them very much. Do I have any objections to that? Or anyone want to say anything? No? Oh, Wilfried...
WILFRED WOEBER: No. Quite to the contrary, I'd like to extend my gratefulness, my thanks to you people and I wish them really luck and enough time to do a good job and I'm sure they will. Thank you.
(Applause)
NIGEL TITLEY: I will now get off the platform. Thank you. I'm handing back to Wilfried. Wilfried is resigning at the end of the this meeting.
WILFRED WOEBER: And this is a very simple job, I'd just like to ask Tim from the RIPE NCC to come to the stage, and to start with the operational. For this time we stride to segment the presentation by the RIPE NCC into a string of smaller pieces and smaller parts, and I'll leave the management and the splitting up into parts into you actually, with the intention to give you sort of immediate, give you a chance to immediately react to the presentation, so ask questions or to just ask for clarifications or to chime in and give your points of view. Tim. It's yours. Thank you.
TIM BRUIJNZEELS: Thank you. I'd like to start off with giving the operational updates, this can be short, but...
First of all, some statistics. As we show traditionally as you all know the database is used mainly for reads and in a much lower rate for write operations. The servers we have are more than able to deal with the load. We have an additional set of servers set up in Stockholm that are able to serve all reader requests should that be necessary.
Issue tracking is... issues are on a public GitHub repository, as is the gode. So issues can be looked there, can be opened there. At the moment we have 15 open issues and 240 closed and with each release of the software that we do you can track which issuess have been resolved.
Release candidate environment. This is something I'd like to bring to the attention of the Working Group. Of course we do a lot of tests in our development process, even before things go to a release candidate environment but it's there for you, and we really need people to look at it. Because if there are changes, that may affect you, it's important that you tell us if things break.
So, please help us with using this.
Documentation and training.
We have been responding to concerns raised about documentation and new documentation is being put online right now. We have documentation tied to each release, so, as soon as a release goes to the release candidate environment, new documentation is also available, and that version ‑‑ it's versioned, so as soon as that version becomes a production version, that same documentation should still apply.
RIPE academy was announced yesterday by Rumy, so, we have also helped the training services department in setting up a trains instance so people can really do play around with the database and be tested on it.
Abuse‑C end of Phase 2. This has been a long running project. We have reached the end of Phase 2 and we have now started to send out the final e‑mails to a group of LIRs for whose end users the Abuse‑C had to the yet been set up. We plan to keep working on this over the next weeks and we plan ‑‑ we expect to have this finished by the end of the year.
Upcoming work:
There will be presentations on this specifically, so if people have questions about it, details, I'd like to refer them ‑‑ ask you to hold on and we'll talk about it in a bit.
But, we have an action item to deprecate referral by for maintainer and to replace it with changed with last modified and created.
Other than this we have heavily involved with RIPE NCC processes such as supporting new LIRs, supporting transfer processes of which we see more and more. So it's important that we also support the internal organisation to make sure that that works.
And where we can help new LIRs to get started with the database more easily, that's also something we'd like to look at.
Then, an ongoing effort we have is a focus with usability in a much wider context, we are also looking at aligning things on our web presence in general. We believe that if we can provide tools to manage your objects in an easier more intuitive way that will help support better data for people that are currently confused. However, this is really in addition to and not a replacement of any of the existing APIs that we have, because we clearly understand the need for that.
And I think that takes me to the end of this part of the update. So... I would ask if there is any questions.
AUDIENCE SPEAKER: Just a question about the Abuse‑C, because right now there are two abuse contact finders, one is based on ‑‑ and the other is quite heuristic based. If I understand that correctly, if you end up faced with the abuse implementation you abandon one of those, this heuristic one, yes?
AUDIENCE SPEAKER: Hello, cafe, RIPE NCC, no, because the heuristic one only works for resources out of RIPE NCC. If a venue check that heuristic based one which is in Hype Stat, if the resource is within RIPE NCC you can either check for an Abuse‑C, if it's there it will show the use C if it's not it says that users has field in Abuse‑C. So for RIPE database users we only check Abuse‑C. So basically ‑‑
AUDIENCE SPEAKER: Still there are two tools under two different URLs and are you going to combine them, integrate whatever? .
AUDIENCE SPEAKER: We can combine them but basically the two tools, the one which is on database is a subset of the bigger one. The one that's on the database only looks at RIPE database resource, the other accepts any resources. If it's on the RIPE database it will give the same result. If it's outside the RIPE NCC, it says you don't get ‑‑ the other one says we're doing heuristics because they are in different places, one is in RIPE database place and the other is RIPE Stat. But the results for rhyme regional resources are a hundred percent the same so we don't do heuristics for RIPE region resources.
WILFRED WOEBER: Just a question related to the created and last modified. Do you have more detailed slides afterwards?
TIM BRUIJNZEELS: Yes.
Okay. So the next presentation.
AUDIENCE SPEAKER: Tim, one question about your operational updates. About the rest for API, when will it be possible to have API keys instead of maintainer passwords to authenticate with the system? Is it on the road map?
TIM BRUIJNZEELS: It is definitely on our minds but I think we need to discuss how we want to keep track of API keys and that may tie into some of the other discussions about how we want to deal with authorisation and end persons or tooling in general. So, it is something we would very much like to work on, but, yeah, we're looking for feedback from the Working Group on how to do that best.
JOB SNIJDERS: So we should make a note of having that as an action item for the next few months.
TIM BRUIJNZEELS: Yes.
Okay, this one is specifically about the subjects that Wilfried just raised. A while ago, I don't know the exact date. But I actually had a chat about this approach with Job Snijders as well, but a proposal was sent to the list on how we plan to move forward with replacing "changed" with "last modified" and this is a small recap of that.
First of all, a reminder why I don't really want to go into all, into too much detail here, but the changed attribute is not really reliable, it's not enforced, it doesn't really tell you what it's allegedly supposed to tell you.
Long discussion, in any case the Working Group decided that the introduction of a created and last‑modified attribute would be much better. So, the approach we propose is essentially first introduce the new attribute. Then make it currently mandatory change attribute optional and in the end remove it. So Phase One is introduce the new attribute. They will be added to the output. Ignored on input like we do for other generated attributes and change is accepted as today. Tools aren encouraged to start using this new information instead of looking at changed lines. Rudiger, is it okay if I do three slides?
Timeline is indicative, that depends also on the discussion in this room, but this first phase is easy for us to implement so it can be done as early as this December.
The second phase is changing "changed" to become "optional." In that case we start generating warnings, deprecation warnings when modifications are submitted, including changes, and if you don't include changes, then we just accept it. We will mark it as optional in documentation and scheme ace and this is really a point where tools that are passing data should be, should expect that change may be missing all together. So, it's important in your testings and the release candidate environment that I mentioned before.
Phase Three would be to deprecate changed altogether. It will be removed from outputs then. It's removed have the Cima and then submitting change would result in errors. I believe this was discussed in the Working Group group as well, that this was desired to be sure that we really get rid of the thing.
We would propose a longer time period before we go from Phase 2 to Phase 3, possibly after the next RIPE meeting so there's more time to discuss and get feedback on all this. And, again, have a longer extended release candidate phase for this one because, yeah, it's a change that may break your updates. So, again, we would really love that people do test.
That's this part. I have more slides on the referral by, so unless there is something that you really want to talk about here... Rudiger, you'd like to discuss this one or shall I discuss the other proposal as well?
RUDIGER VOLK: I would like to place comment here. I would suggest that we start to ‑‑ we start a habit of introducing the Phase 0 into your timeline, where essentially a short formal document defining what the new schema is is published, discussed and endorsed. That's probably a proposal that will be applicable to some of the other things. The time lines, I actually have to check because at least in our environment, the systems that are interfacing here may be actually pretty hard to change, and that's a concern that I guess will actually also hit some other people.
JOB SNIJDERS: If I may react. Rudiger, we did discuss this on the mailing list. We passed through a Phase 0. We had a formal definition and it is in your mailbox, so I don't understand your comment.
RUDIGER VOLK: Well, I have so much crap in my mailbox ‑‑
JOB SNIJDERS: That is not my concern.
RUDIGER VOLK: Well, okay.
JOB SNIJDERS: I will give you a hug...it's okay.
RUDIGER VOLK: No, for the systems that we are developing here and using, there should be proper documentation that is easily accessible that I can point my developers to and not grab into my mailbox and figure out which of the e‑mails contains the relevant information. And, if I have that, I'm not completely sure whether those guys will come back with some valid feedback. Small chance but, well, okay, the way we have been dealing with it so far, I don't think feeds really well into this.
JOB SNIJDERS: So you would like documentation ahead of the release candidate's documentation?
RUDIGER VOLK: Absolutely. How are you thinking that my heavy development apparatus is going to provide me an updated software version that works on even a two months release candidate to check?
TIM BRUIJNZEELS: If I may I think ‑‑ I don't think it would be a problem for us to write some documentation on this ahead and communicate it with the Working Group.
RUDIGER VOLK: I hope we don't have proposals that are really that hard to document, and make it easily available in the development cycle I think makes sense and actually protect us from the large stack of the incremental changes that have not made its way into the systemic documentation.
JOB SNIJDERS: I see your point. We'll work on it.
WILFRED WOEBER: So for Nigel taking minutes, I think there is an action item for the RIPE NCC to come forward with a document in itself, self contained document relating to this proposal. I think it's not a bad idea to do that actually.
The next question from my end is sort of a technical one. There has been some traffic recently on the Anti‑Abuse mailing list which somewhat relevance to that one for a gentleman trying to find out when a particular object was created. So my question here is, as soon as you start to automatically generate the created tag, are you going back in to your own history of the object which is not directly visible by WHOIS queries and tag this object with the created, which is really the original creation date, or are you sort of starting with the time stamp when we turn that machinery on?
TIM BRUIJNZEELS: I'm not sure if I ‑‑ I think I have an answer to this but cafe you have a comment? Well, Wilfried I think you are referring to objects that may have existed in the past and have gone away and been recreated.
WILFRED WOEBER: That's the even more complicated sort of scenario which I was not referring to. I was referring to objects existing right now in the database where, for one reason or another, the old changed lines have been lost, so, there is no obvious creation date. So my question is, are you going back in sort of in your own internal records to find out when this currently existing instance of the object was created and used as the time stamp for the created.
TIM BRUIJNZEELS: Yes.
WILFRED WOEBER: And forth one I think there is no reasonable mechanism or proposal to find out whether it was the same and just disappeared for a few minutes or so. Don't do that.
TIM BRUIJNZEELS: No, we were not planning to.
AUDIENCE SPEAKER: Jan Zsako from hungry. Actually, I was about to ask about the same question. This also refers to the last changed attribute, whether you want to delete all these changed and last modified attributes you want to have it properly done. But, I also have a comment about the first creation of the object, because now you have versions. But if you look at the first version of a given object, that not necessarily shows you the creation date. Because there are objects which are extremely old in the database and you may not have that information right available. So, it could be quite hard to produce that.
AUDIENCE SPEAKER: From '99 till now we have all the records clear so there is no problem now except in a six month period from September 2001 for six months, so, almost all the objects we should have it. There are a few strange cases there A, for two, three years, between 2002 to I think 2004 or 5, people were able to create and when they deleted personal object for example they were able to recreate them and that caused some issues there, so, creation dates for personal objects might not be accurate but personal objects are not of that much importance I assume. But for INETNUM and for all resources objects we have. If some object is deleted that's a question for the community. For those objects we usually have the original created. But from talking to the people, we put the creation of the current object that you see. If something was deleted and then recreated you see the last objects creation.
AUDIENCE SPEAKER: I fully agree to put the current instances creation date there, but I was actually thinking of objects which were created before '99 so that, in particular that was an AS number I had looked up which was mine, so...
AUDIENCE SPEAKER: That I think it will be an implementation tool, I think we can put a set a fixed date or...
TIM BRUIJNZEELS: Good point.
RUDIGER VOLK: So, back at the mike and rather than process a little bit of content, I would really like to see some sin tactic markup that shows which of the attributes that are output are actually part of the proper object handled by the user and which objects are somewhat system generated and added, and I would prefer to have some special syntax marker there rather than well, okay, we start up and create a list of attributes that we know fall into that class or into the other.
TIM BRUIJNZEELS: Well, I think we will definitely update documentation. But if we need to change syntax I'd like to ask for input on how we should do that.
RUDIGER VOLK: Doing some kind of structured comment might already be sufficient, but I haven't looked deeply into this. But having a simple criteria yen to figure out what class of attribute is this, I think would be a very good idea.
AUDIENCE SPEAKER: So we have that already, if you do minus, it any object type you get a list of the an attributes and if it's auto‑generated. So if you do query minus, it INETNUM for example at the moment you see a printed list auto‑generated with the type of attribute and if it's auto‑generated or manual or mandatory, so you get all of that automatically ought of the system
RUDIGER VOLK: Well, okay. That's ‑‑ that would be schema documentation and what I'm asking for is actually markup in the actual object so that when I process the output of a database, I can easily mask out what is system generated, which I do not want to mess around. And well, okay, think about it.
AUDIENCE SPEAKER: Before I leave. I just wanted to make a comment. Sorry that I come to the mike that much. Tim has taken database over for a few months and I'm just trying to give my ‑‑ it's all his operations and ‑‑
AUDIENCE SPEAKER: It's Peter again. I have a comment on Rudiger's and just two more questions.
Rudiger, are you going to have a special, something like a common attribute, whatever, also for auto‑generated objects like some organisation objects are auto‑generated by the NCC and the others are put them, as far as I remember, by human. So do you want to distinguish them because that could be a nice idea?
RUDIGER VOLK: Kind of, I would not expect that all the attributes of an auto‑generated object that can also occur in kind of a naturally maintained one marked as generated. In that case I would suggest well, okay, define some comment to mark the whole object. That probably would be a good idea, yes.
AUDIENCE SPEAKER: So we can make this an action point or at least an idea for being considered by the NCC and discussed later on?
TIM BRUIJNZEELS: Sure. But like I said I think we need some guidance on how you would like to see this.
AUDIENCE SPEAKER: We can discuss that later.
TIM BRUIJNZEELS: We are welcoming input.
JOB SNIJDERS: We need to discuss this on the mailing list. That's the starting point.
WILFRED WOEBER: I'm not going to contribute my idea at the microphone but on the mailing list. Thank you.
AUDIENCE SPEAKER: Two more questions about this dates of creation. One is going to be about the allocation made by NCC in the past. I'm not sure if I'm correct right now, but there could be such a case that the allocation was made in the past, really in the past and then the object was deleted from the database and then recreated. Would you consider that for such objects like allocations which they had been under the maintenance of the NCC, this creation would be not forth actual object but for the allocation itself? Or some other history would be coordinated?
TIM BRUIJNZEELS: Yeah, at first glance I think that's a good idea. But... maybe that's something to discuss in more detail off line. I don't know... but, you know my gut feeling is that that sounds like a reasonable thing to do for the very old ones where the full history may not exist in the current database.
AUDIENCE SPEAKER: Okay. So, the other part of the same kind of question is for the original registration U RX project. Would you consider including the history of the URX records from other RIRs? This would be a nice idea I think? I know that there is a point in time in which some data will be lost, like 1991, or something like that. But at least some history could be incorporated here, would you perceive that as a nice idea or not?
TIM BRUIJNZEELS: As a nice idea, yes. But I have to see what's feasible because I think when we have it in our own ‑‑ you know, once it's been added to our database, we can actually look at the history. Before that it may not be so feasible. So, I don't want to promise that we can do it and then have to say that cannot. So... I would say let's look into this and report back.
AUDIENCE SPEAKER: Let's discuss that on the mailing list.
TIM BRUIJNZEELS: Yeah.
WILFRED WOEBER: I think so. And thanks to everyone who brought up their personal issues and I think this needs discussion on the mailing list and this may be something which you could roll into this proposal like this is going out to ‑‑ this is how it's going to look, this is going how we are to do it. This is sort of the data we are going to use to populate the thing, and then this is the way the users are supposed to deal with it. Is this sort of reasonable for everyone? I see a couple of heads nodding. May I ask you to go onto the next topic?
TIM BRUIJNZEELS: There was also a referral‑by, which we were also going to deprecate. Now this case is probably somewhat less controversial, because the referral by attribute itself was not very useful. Still, it's mandatory currently. So, we propose a Phase 1 where we make it optional. So that means that it will start to disappear from certain objects, and your tolls need to be able to handle that.
And then the next phase is to actually remove it altogether.
So, this includes ‑‑ well, it's still visible in the history but it's no longer shown in output and it's no longer accepted on inputs.
So, if anybody has questions or comments about this, then we can do them. If it's all good, then... I would ask the Working Group if there is consensus to go ahead with this.
Okay, then we can move onto the next presentation.
TIM BRUIJNZEELS: All right. Personal authorisation. This has been the topic of a presentation at the last RIPE meeting as well, and people have been asking, well if I remember correctly, Rudiger asked at the end of that presentation to come up with a more detailed proposal so that the Working Group can scrutinize it. This question has also been asked on the list. And I'll get to that. First of all, are we, as the RIPE NCC, concerned with all this? This is mainly coming from problems that we see that people have with this. Lots of support requests, time spent in training to explain the authorisation model where people don't really get even to the more complicated setup because they are struggling with doing the simple way first.
And this also imposes some issues when we want to work with user interfaces.
And tools that we need to set up to help the creation of objects.
Now, first of all, I have a disclaimer here the we do not have a set‑in‑stone proposal like this is the way we think it should be done. What we do have is ideas that we'd like to discuss, and the feedback of the Working Group is very much desired. So... that's the disclaimer to start with.
That said, person objects are hard. Person objects must be maintained. So, we recommend people that they set up their own maintainer to maintain that person. We have a tool to help them. But we also have single‑set only account where a natural person has an account set up. So there is different places where people maintain their identity, if you will. The single set on accounts. SSO for short. Set up two factors authentication, and password recovery for these accounts is fairly easy.
If we would have an SSO based authorisation on person objects, what we might do is, in addition, the big cross, don't let it distract you too much, where currently and in the future you will be able to have a maintainer and a person object, we could also allow you then to, we could add something to the bottom of this RIPE access page that allows you to check a check mark, fill in all the details that you need and say maintain a person object for me.
The advantage of that would be that it's easier for a lot of users, and if you need to change you use your e‑mail address or your name you can do it in one place. And note well that this doesn't exclude other authorisation mechanisms that we may want to add to persons either, because we can just have all the necessary fields. If you need BGP, that's also easy to add.
Then, maintainers, are they hard? Well, the concept is a bit difficult to grasp sometimes. They are anonymous, and that makes it more complicated to deal with password recovery.
The updates are accepted as long as the credentials provided match any of the listed credentials. This makes it a bit difficult for us to tell authorised people, like give people authorised people a log in facility for example that says, your colleague actually changed this object, because we do get questions like that and currently it's very difficult to answer those.
Maintainers are not really representative of a specific natural thing, or one specific thing that we might think of like if you have a person, that refers to a person, a route refers to a root but a maintainer object can refer to different types of units. It can be one person in essence, it can be an organisation, it can be a group or it can be a script that's using it. It's not immediately apparent.
And in a lot of security systems, authentication or authorisation are actually separated. So, who you are is separated from what you are allowed to do.
Graphically, this is the current situation, a bit simplified maybe but we have admin contacts in an object that may refer to a role. Then the role can have an admin C referring to a person. There can be a direct link to a person instead. This is allowed by discouraged because it doesn't scale so well of course because then you would need to make a change in all the objects. If you have a group you only need to do it in one place. We have a reference tonne maintainers in there. As I said you can have multioff lines but it's not apparent who is using them.
One way forward could be, and this is I think what was presented by Denis last time. Is, we could use roles as a more natural way of describing a group of people, and in this case people authorised to make changes. So you could have a reference not to a maintainer object but to the role object and then the role object have auth C references like for auth contact or it can be of course any other attribute name, pointing to a personal object that has certainly authentications ands labels. The advantage of this is would be very consistent of how we deal with other group of people in our places like admin contents and tag contents. The disadvantage of this is it might be more difficult to migrate because currently we have maintainers and are set newspaper a specific way and they are not exactly the same as roles although there are similarities of course.
Another approach could be to say, well, let's keep the difference between maintainers and roles, but maintainers can now refer to persons instead. So you don't have to have it all listed there. You can refer to actual.
The advantage of this is probably that the migration path is a lot easier. The disadvantage and I'm also looking for the opinion of people here, is that it might be confusing that for groups of contacts, you use roles and for groups of authorised persons, you use this other object. It could be a bug it could be a feature, it depends on how you look at it I think.
In any case, a more generic question behind this I think is what do we do with the existing maintainers? We can have different mechanisms next to each other, but I don't think that is very ideal because it can add confusion as to what is the best way to do this. We can introduce a new way and deprecate the old way later, but I don't think that's very feasible given the amount of maintainers that we have. So, you know, not just me, but discussing this with many people, I think that the objective is to have something that remains compatible with current.
So, no action should be strictly required by current users, and if there is a migration, then we should be able to automate it in a way that makes sense. Everything needs to be keep working but importantly, the improfits need to be available to new users, because that's the essential thing that we try to solve in the first place, we want to make it offer an easier way to do this for those that can and want to use it.
What about existing tools? Sending updates? Well, currently, you include credentials but you don't explicitly refer to where in the possible maintainers this credentials may be found. We checked this already. And if we changed this model, then we can also update the software to look in different places. So this shouldn't really be a showstopper, this is something we can deal with on the service side. The point is that, your updates will essentially be on affected, it works in the same way there.
Now, this is where it gets hairy of course because, let me quickly go back ‑‑ where I said, if we are to migrate maintainers to roles, the advantage of this might be that it's not confuturesings, or less confuseings because we use roles for groups of persons elsewhere. The disadvantage is of course migration.
So, let me go into the migration a bit, so we know what might be involved.
An option that we could look into is migrating maintainers into role objects and separating out, and I think I would welcome discussion on this ‑‑ separate out the existing authentication lines into some kind of anonymous person object that has the authentications. The advantage of that would be that you use it consistently with how you would do natural persons. Well, you know, as I said this is just an idea at this stage.
How do we deal then with all the attributes? Maintainers have names, there are clashes with roles but not many of them. 364 out of 60,000 is something we can solve I believe. Descriptions are currently mandatory in roles. They would have to be made optional ‑‑ sorry mandatory in maintainers. Updates maintain notify are used, are very useful when you do maintainer like things. So if we were to use roles for this purpose, would you need something similar there.
Of would become a reference to a person with authentication there, most likely ‑‑ well referral by is going to be removed. And bear with me, it's just working out what the main points are if you would do this.
The other way around. A transcripts found in roles but not found in maintainers. Address, well a maintainer is anonymous, cannot say anything about it, the only thing you could say it's unknown, it's not applicable or you could make it optional.
An e‑mail, we don't have an e‑mail field but we do have an update tool, so that is in the security context used so it may be the most logical choice here. And it can be auto‑generated.
Anonymous persons, is another thing to think about, whether that's a good idea or not. Like I said, the advantage from a conceptual point of view is that everything is the same, but I can fully understand that an anonymous person is a big change to actual persons that we have now. So, again, there are problems with attributes here.
Essentially this could be, if we were to go down this path, we can I believe we can hide some of this complexity in that it would be good to filter out of C references like we currently filter out authentication lines anyway, and these person objects would not really be generally interesting to people to look at unless you are the maintainer yourself. So there is something we could do there.
All that said, what may be, and that's the other slide where I said if we just put it on maintainers, the migration path is a lot easier, and I believe it is. You could also argue, no, let's keep the maintainers exactly like they are, with the off lines that they have, but make it optional to refer to a person instead and let the persons have authorisations in turn. The advantage from a maintenance point of view is there would be no migration needed because whatever you have now would work. There are no anonymous persons because maybe they are too confusing and if you want to do we need to think about how we want to do that in general, but it does allow using this new mechanism, so, we can start to refer to natural persons, and where we already have auth SSO in maintainers, we start to see this auth SSO appear in persons, we can probably do quite a bit with tuning to, if we know that reference, we can change the reference to the actual person instead. Or at least help you do that.
There is more to be said about this, I'm sure, so, next steps?
I think it would be really good to have a discussion about this with the Working Group, and we're ‑‑ you know, I'm just trying to highlight ways to do this, but we are really looking for consensus in the Working Group, then we can make a good implementation plan, get consensus on that again and then implement.
So... maybe I'll leave this slide. Because... questions?
WILFRED WOEBER: A comment. Not wearing any other hat than remembering why we did some design decisions in the good old days that led to the creation of the maintainer object.
My first reaction would be the idea of an anonymous person is a no‑go.
The second thing is my feeling is that trying to get rid of the maintainer which is considered to be difficult to understand by replacing it with a role object with two or three or four different colours, and with two or three or four different functions is actually very bad idea and actually my feeling is it would create more confusion and more difficulty to understand the relationship than the thing we are having right now.
The other proposals like trying to separate sort of some stuff which is currently in the maintainer and sort of separating that into something which describes a thing which maintains something else and then pulling out the thing which actually describes which entity has which authority to do, I think that's a potential way forward. But, sort of with my elephant memory turned on, I think much of the perception of the maintainer being difficult is based on the fact that many of the new users are not aware of the fact that we just wanted it to have just as a sort of a macro facility to in one place describe which set of credentials actually are usable and authorised to modify the objects which link to that. And I'm still thinking this is a very simple concept, but obviously in this time and age where everything ‑‑ everyone thinks about new models, it has become difficult
RUDIGER VOLK: Wilfried, dumb question from me. As you are relieved of the Chairman's duty, would you seem ‑‑ would you see a way for writing a simple documentation explanation of what people are missing? People are missing the concepts and actually I would not know where to point them for a good explanation and so ‑‑
WILFRED WOEBER: Good point.
RUDIGER VOLK: For the slide that's still on there, I would make the point, we actually should have in the plan where are we writing and agreeing on the draft document, describing the design, providing an implementation plan quite obviously is something different. For the content discussion, I think I'm very much with Wilfried, and if the arguments for changing things in the area are really that heavy, I certainly would plead for do not remove the maintainer out of the data model. The migration that you would need is not only in the database objects, but also in the organisations and the implementations and the documentation of people.
TIM BRUIJNZEELS: I understand. So I welcome this discussion. If I may go back.
I also included this slide, about a possible different way that may not have those properties. I think what in the end matters to us most of all is that we can have authentication tied into persons and the authorisation separated from that. Because then we can offer people a way to say, you know, these people should be authorised.
JOB SNIJDERS: I too do not know the way forward exactly about the concept of association authentication material with the person is very appealing to me. One example for instance is that I associated with multiple local Internet registries that have lots of objects and many maintainers. And rather than referencing my PGPKEY from eight different maintainer objects, if they were referencing my person object somehow, then it would be much easier for me to roll over keys or change credentials. So, there is ‑‑ for me there would be immediate benefits if we have a, say, a maintainer independent credentials storage. So I look forward to working with you on getting an exact plan together of what it is we want and I agree with Rudiger's remark that cannot really delete the concept of the maintainer as there is so much documentation and knowledge, so we can add something new but cannot take maintainer away I think.
TIM BRUIJNZEELS: Okay. Noted.
Okay. My final slides.
A bit more time. I'll try to keep this short. You asked to say a few words about this. The recovery of access to a maintainer object.
We do get quite a few requests related to this and on the technical side, what we have been doing, you know, we have an operational procedure for this, with used to ask for PGP or then a password and we would update the maintainer take out all the existing authentications, insert the new ones you have provided.
We have worked on this and we believe we have improved the efficiency somewhat, in that now, rather than removing existing authentications, we allow you to add new SSO authentication to this maintainer, and after that point you can make other changes yourself. And in case you do lose your password to just your access account, we have another way to reset just that, so you don't affect anything else on the maintainer.
We have also tried to ‑‑ we have also automated the process where we could. E‑mails are sent to the updated two e‑mail addresses because that's traditionally used with authentication failures. And we have a fallback process that allows the CS to send the link to people as well.
And that's what I had on this right now. So if there is any comments or questions about this?
WILFRED WOEBER: Okay. This seems to be an easy one. And Tim, thank you very much. That is going to give us the next thing and that's, I guess, Job, with his ideas to sort of fire up more activity in the Database Working Group.
JOB SNIJDERS: Thank you. I don't have a lot of concrete ideas. I'm looking for people to participate in this group. As you might have noticed in the last 12 months, there were not a lot of proposals. There was very little activity on the mailing list, and I don't understand why that is. The database is one of the most valuable assets that RIPE has. Why does nobody care? Except Rudiger, I mean.
So, you know, I had some funny pictures to try and energise us a little bit. But what I'm really looking for is who are, who are you, as users of the database, and I'm specifically looking for who here uses the database in a professional way on a daily basis either automated or manual? What do you use it for? Why am I not seeing you on the mailing list with feature requests?
RUDIGER VOLK: If the database was in really bad shape, we would be making bad noises about it probably more often. A system that is in production use and is, well, okay, more low level infrastructure than high end service feature, in my opinion, actually is very healthy if it doesn't need a steady flow of changes and updates and modifications.
So, I would not ‑‑ you would see silence not necessarily as a bad thing.
JOB SNIJDERS: Agreed.
RUDIGER VOLK: And being so old and having a grey beard, of course I'm very conservative and try to shoot down any new thing.
AUDIENCE SPEAKER: Ray, Finland. The thing where we use the database for is what we're supposed to be using it for by keeping the data up to date. It's not about developing new gigs and new stuff on it.
JOB SNIJDERS: The database is about being a curious and making it easier to keeping it curious, that's what I considered developing. Because right now the ‑‑
AUDIENCE SPEAKER: There is also development, I agree with that but the point is, if you are an ISP, the size of ours are bigger, which is quite common, is that you don't have time to weekly make changes to your software, you are busy enough keeping your data up to date, and that should be flexible and easy to be done. Cannot every month ask your management for, oh, I need another budget because the guys found out another row in this database which I have to upload or send or do some API. It's great that there is going to be an API, that's fine. It's even better there is a web page where you can do things. That's fantastic. But since the current systems of many LIRs are using through e‑mail, some of them are really expensive commercial programmes, it's not very appreciated that things are suddenly being cut off in two months time frame. Since you need a lot more time to get your management to give you the budget for it. And that is a problem.
JOB SNIJDERS: If I can summarise your comments. You say large organisations cannot move that fast, therefore the Database Working Group is not moving fast.
AUDIENCE SPEAKER: This is not a point of view or I being fast. It's a point about real life that cannot, if you make changes that is understandable. But things have to be updated, that's fine. But, cannot suspect that anyone just can do these changes as well just as fast.
JOB SNIJDERS: A different sort of question I have for this audience. How come the release candidate environment is not used?
RUDIGER VOLK: Well actually, using the release candidate costs additional effort, and well, okay, at the last meeting outside of the public discussions, for example, I hinted that if I had advance notice, that in three weeks time I should expect that a new candidate comes out and would require testing resources, that would help me if I only get the notice that now something new is here and within three weeks I have to figure out whether I have resources for running tests or not, well, okay, I may find myself out of being able of it. Like, for example, with the current release candidate.
JOB SNIJDERS: You know, now that in January there is a release candidate and in May.
RUDIGER VOLK: Well the thing is actually, I'm very happy that the release candidate is there and we have a much better controlled release process, because we got hurt very, very painfully, and when I discussed the absolute minimum requirements for improving the process, I didn't dare to ask for a test environment because I did not expect that I could actually put in the effort to use it. And so far, I have not had a chance to set up kind of a pre‑recorded testing thing for using the release candidate. At the moment it is kind of manually running stuff, and yes, if we had all the resources that we wanted, like nice and agile guys like you, well, okay, it would of course not be a problem. But we don't have, and not everybody can afford it. And actually there aren't that many people of that qualification around.
WILFRED WOEBER: Okay. Just let me chime in for a second because we have a queue at the microphone. And only about 15 minutes left.
AUDIENCE SPEAKER: Natalie working for RIPE NCC as a trainer, and a lot of our training material and training courses like Tim has mentioned, the academy, but also face‑to‑face training ands with webinars are about the RIPE database. And that has a reason. Because it gets better now, but it didn't ‑‑ it wasn't really intuitive. If you are not used to database relations, then the RIPE database is not an easy one to understand with all the different a transcripts and different functions and relations between different objects. So, from what I see is that people use the RIPE database maybe two or three times a year. And that's it. And then they change jobs and their colleague has to take over, and clean up things. Because people don't ‑‑ they find it difficult to maintain the RIPE database. That's one of the things. It gets better now. I have to say in the last year‑and‑a‑half, two years, have been significant more user friendly changes and we see that also in the training courses that people are now finding it easier and more intuitive to work with it. However, we're not there yet and...I can see that with Tim's presentation that he just did, we are trying to make things easier to understand. But we have to also consider the users only use it two or three times a year so making too many changes is also a bit tricky.
JOB SNIJDERS: Thank you for your comments. I will wrap‑up. Just one question. Are there eye palm developers in the room. IP address management tool developers?
WILFRED WOEBER: Only to a very little degree and by proxy.
JOB SNIJDERS: Zero? That's not a good sign. They should be in this room.
AUDIENCE SPEAKER: So, I am Donaghy Royce man from soft layer. And I want to say that we actually are very avid users of the RIPE database and the RIPE API. I don't have our stats, but I could imagine we are doing 20 to 30 updates regularly. We register everybody single customer, every single customer release in realtime. We have a lot of automation in our platform and that's one of the things so far that for all the good work you guys are doing. We have run into a couple of snags here and there. What other head I‑Palm developer is active on the Working Group mailing list and e‑mails, Tim Garson, we e‑mails when we run into problems and you guys seem to resolve them fairly effectively. So I personally am not an I palm developers but we do have I palm developers in‑house and we do enjoy the API which some other registries will also adopt flexible API.
JOB SNIJDERS: I would like to work with your co‑user in using the release candidate environments.
AUDIENCE SPEAKER: I know we have no south standing issues that don't work effectively in rhyme. So ill put you in touch with him.
WILFRED WOEBER: Before you close down completely Job, I'd like to ask a similar but slightly different question. How many of you are using software from an external party to maintain the data in the database? (RIPE) so all the others are just in the room to read e‑mail or ‑‑
RUDIGER VOLK: What's a third party?
WILFRED WOEBER: Not a home grown thing from your own team, from within your own organisation.
RUDIGER VOLK: Okay. So if you have to ask a subsidiary to spend some budget on something ‑‑
WILFRED WOEBER: That would be an external. So, Job anything else you want to... Tim?
TIM BRUIJNZEELS: Because we would be very happy to work with people more closely where applicable. And you know, I think also when we know that changes are going to happen that are more risky like today, we are happy to report that in time. However, we also do releases that are less risky, if you will, because they don't really change the schemas as such and in those cases, I think we should keep an open mind about how risky this is and how much advance warning and how much time do you need to test this properly because we do of course test ourselves, and it's always the balance between you want new features, you want to be able to do things, so you need to test them, and give people the time to get used to it. So, that's the balance we're trying to find and I would really love to get more involved with people helping us with the testing part.
JOB SNIJDERS: So you can get free professional services from RIPE NCC. Nice.
AUDIENCE SPEAKER: Piotr once again. Just about this soft releases which do not change anything in the credible way. One of those were in the last few moments were somehow interrupted by me because when we were pushed to have an Abuse‑C contacts in the database, there was enormous need to extend the number of role objects. And it came to my attention that the role object was having such an obstacles about having the schema for the person not for the company name, and as far as I know company names could be absolutely different from the person names, at least in our origin. That was something which I inducted and that's the direct answer to your first question, why are we not requesting the features. I was requesting the feature because I need that. So, yeah, that's the answer. And the other answer to the first question, or at least one of the first questions is, that my software is used to that database. So, when I was presenting years ago an idea about internationalisation of database and I was really fond of this idea, and then I abandon it because I changed myself to change all those Polish letters to the English equivalent and I'm right now used to that situation in which I can live with that and that's the way we are not probably requesting features. I can blame myself because I was not pushing on this idea about UETF or internationalisation in general, but that's only my fault and I can promise right now I can be more active on that.
JOB SNIJDERS: Thank you.
WILFRED WOEBER: Thank you Job for trying to tickle other bellies, I think it's appropriate to do that from time to time and to do it again.
The last thing on on agenda we have got some ten minutes left is to ask whether there are inputs from any other Working Group? I'm not aware of any but obviously, Rudiger you do have something?
RUDIGER VOLK: Well, if I understand, we have missing communication from abuse.
WILFRED WOEBER: In the sense of?
RUDIGER VOLK: I think in Nigel's to do list, there was a question that has not been answered for documentation of abuse and in fact I would really suggest that the RIPE NCC stops making Abuse‑C mandatory until such documentation is provided in an acceptable and presentable way. And one of the arguments is forcing population of those attributes without proper documentation means people are forced to put something in without guidance what this is meaning, and that means if we have no documentation that helps users, we are essentially forced to populate the database with crap.
WILFRED WOEBER: Is this formal input from the Database Working Group or is this input from your perception?
RUDIGER VOLK: This is my input and comment and my observation on ‑‑ well when the RIPE NCC forces and copies stuff to objects as Abuse‑C contact, adds Abuse‑C attribute, well my colleagues who have contacts with the customers cannot have ‑‑ have no document to show the customer what he is supposed to do there, cannot help to get the right information in there. So, again, in my evaluation the forceful population of that attribute is essentially meaning we are introducing crap, which of course will be hard to weed out afterwards.
WILFRED WOEBER: Okay. Noted. My question to the community would be, and this includes you, Rudiger, is this actual responsibility of the RIPE NCC to come up with this interpretation document or is this rather a task to be taken care of in database? Because it's, from my personal perspective, it's just a logistics point of view, it's not a database or database schema or such a thing.
RUDIGER VOLK: Well, okay, it's not a schema question. Someone decided that the schema should be extended without providing documentation for it. And kind of, as far as I understand, actually not providing documentation was a conscious choice, which does not change anything ‑‑
WILFRED WOEBER: So then my proposal and that's probably the last one as a co‑chair of this Working Group, my proposal would be to put that back into the Anti‑Abuse, because I feel very strongly that the Database Working Group is more to take care of the machinery and the syntax and that sort of things rather than of the semantics and in particular for that type of object or that type of attribute, I think it's not ours to do anything about interpretation of the value of this attribute. I don't know if anyone wants to disagree. Okay. So, Nigel, I think you have got that into your notes. I think we can ‑‑ cafe?
AUDIENCE SPEAKER: Just a quick history on that it was a conscious time because there was ACMTF going back to 2009, or 2008 I think, the management Task Force which was started exactly for this and one of the outcomes which is clearly documented in the outcome of that Task Force was first they wanted to have to introduce this attribute and second, after that when the attribute is there, decide if they really want to think about a format of the submission, the quality of the addresses. But it was consciously ‑‑ it was not discussed.
And the second part was that the force fullness, just to remind the Working Group, it was also discussed here because we had the experience of 2010‑01 which took about five years and many euros and after that the committee was not aware when they came up with the size of that project, and the community didn't want to repeat that so that was the feedback from the community. So it was all within the community's realm.
WILFRED WOEBER: So my guess is this is an item not for input from our Working Groups but for output to other Working Groups. And I think it would be appropriate to make it a work item for the Anti‑Abuse Working Group to come up with a document clearly designing what the semantics of that are. Job?
JOB SNIJDERS: I was just reminded that we have one additional agenda point, geolocation.
WILFRED WOEBER: I am aware of it. And thanks for reminding me. Input/output from other Working Groups I think taken care of and thanks for reminding me. This gets us to the proposed additional agenda item of geolocation, and I don't know who is going to contribute. Okay, go ahead.
AUDIENCE SPEAKER: On an from the RIPE NCC. We had Tim Robinson from TX RX communication ask for a discussion about geolocation. I'll read out his problem statement.
I'm a new LIR and I am really struggling to get my IP blocks registered or recognised in the UK by broadcasters and so on. His issue is, I want to deploy the new blocks to customers and there seems no way of getting all content providers updated with the correct country. Even DNS lookups from my DNS resolvers or new IP address return whacky records for content providers, for example Telegraaf.uk refers to Akamai in the UK. On my old block it resolves it an A record in London. I think this problem will get worse as IP addresses get moved from one LIR to another and one country to another.
WILFRED WOEBER: Okay. Thanks for the problem statement. Anyone to follow up? Job.
JOB SNIJDERS: I agree with the problem statements. I think all of us have known the pain of moving a block around and customers complaining that the advertisements are in the wrong language. We notice this with every RIPE meeting. We are probably all being served ads for Poland right now and the next meeting in Amsterdam will be presented with fish and chips advertisements. It is clear that there is not a global source of truth about where an IP is located. So there are these databases that companies maintain and we are, as RIPE database, just a small part of that ecosystem and I do not know why the country and location identifiers that are in objects are not parsed semi‑realtime. Maybe we should make it an action point to make it easier to consume the data that the ‑‑ in the RIPE data regarding location. Maybe we need to talk to geolocation providers. But it is clear that we all suffer from this, but I don't know an immediate solution.
WILFRED WOEBER: Yes, we do and I could easily, during the break afterwards, explain to you why the country controlled is still this and why it is not used, but that's an offline discussion. I'm just wondering ‑‑
AUDIENCE SPEAKER: I'm quickly going to reply to that. I fully agree with Job and he is right. The thing is, because I personally follow that up with some of these organisations as well. So make a long story short, it's a chicken and egg problem at the moment because if you have good reasonable amount of geolocation data it's easy to convince them to get the updates from us like quickly everyday or every hour or whatever. But on the other hand, also the providers, they won't put, even the ones who want to put data, they won't go to the trouble of putting it in RIPE database or with us any format because they don't see any immediate effect. So at the moment, it's possible to do it, it's possible to talk with those organisations, Googles and IP location and MaxMinds of the world, but they expect a lot of data and people don't provide data until they see there is an effect. So that's the current situation.
AUDIENCE SPEAKER: Greg. Since I ‑‑ from what I understand of it, it's not a mandatory part of the database. And since it isn't, I would suggest that you just take it out, or add a warning with it in Google style, I'm feeling lucky, because it is more of a pain than more of a use.
WILFRED WOEBER: Thank you. Rudiger?
RUDIGER VOLK: I understand that in the application protocols that are typically used where this information is desired. Well, okay, actually the application protocols allow the server to ask the client what the users attributes are, and the US Army corps in Iraq served from a German telco out of Frankfurt. Well, okay, that's confusing. Well, okay. Checking what the user interface actually knows about what language the user speaks, well, that usually is actually good information and people should be looking that direction much more than into the databases and the illusion that GUIP is really a good thing.
WILFRED WOEBER: Famous last words, I guess.
Okay. Unless there is any other contribution to this AOB ‑‑ go ahead.
AUDIENCE SPEAKER: Actually it's input from our Working Groups.
Routing Working Group. We just had a discussion over there about the fact that we permit introduction of foreign prefixes into the RIPE database to the LIR part, which is something we all agreed to in the past, but there was a discussion also of how this has actually turned out to be used for bad stuff, for hijacking prefixes and kind of providing a veil of legitimacy to the act of this hijack by making sure it's present in some database for instance, the RIPE database. And what can we do about it? We discussed that already some years ago we tried this inter IRR exchange of data. That didn't work. There is no point in trying to revive that. We know where that one ended up. But it turns out we actually currently have a new mechanism that wasn't there when the discussion happened earlier, which is RPKI. So, we were considering, we actually will probably, after talking to Kafe, if he doesn't mind, putting an action item to the RIPE NCC to study and report on the implications of using this as an additional authentication mechanism to prevent unauthorised registration of foreign prefixes in the RIPE database. So at least the database is not providing some sort of validity that's not there. This is not straightforward. We don't even know at this time what we really want to do.
Also, if you could study how this affects things like the integrity. The rules of what can go into a database and what can not, and if it is at all feasible, I think it is, but it's not for me to actually say so, to use this additional mechanism to provide this little bit stronger authentication, it would be a good thing all around. That's the input from the Routing Working Group.
WILFRIED WOEBER: Thanks. May I ask you to come back to the Database Working Group mailing list with some sort of pointer to the Routing Working Group draft minutes or sort of with a problem statement or with this question, because I think this needs more time to work on, we are having left today. But noted and I'm pretty sure that Nigel has taken it as part of the notes. Thank you.
I think there is another ‑‑
AUDIENCE SPEAKER: It's Alex Band from the RIPE NCC. I want to say something with regard to what Rudiger just said and we'll probably be able to come up with 100 reasons or 100 examples on why implementing or trying to implement geolocation in the RIPE database is not going to have the desired effect like having a German network in Iraq. But I don't think that's a reason to not do anything, because you can come up with examples where your solution doesn't work, because I believe that it can work in a lot of other cases. Like the example that we just heard. And I really ‑‑ I would really like to stress the Working Group to just let us try different things in order to solve this problem instead of just saying, well, it's just not going to work anyway, let's not bother. Because that is really the feeling that I'm getting now.
WILFRED WOEBER: Okay. Noted as well. Thank you. Another gentleman, please go ahead.
AUDIENCE SPEAKER: Ian Dickenson from Sky. As a content provider as well as an ISP, I'd like to support that we should consider trying to do something here, because a lot of the geoproviders that are out there provide no decent bulk way for us to provide good quality data. I don't really want to have to track, you know, 19 different places of doing it, each of which require single ranges done via a website. I'd like to put it in the database with the authority and tell them to go and there and actually drive there and I think we could at least attempt to do something more in this direction.
WILFRED WOEBER: Okay. Thank you. Any other comments or inputs?
AUDIENCE SPEAKER: Donaghy Riceman again, I just want to support that last speaker. I think it would be great if we actually made it available as an option and we publicised the geoI IP folks, reach out to the larger providers afterward let them know we're reaching out to the RIPE community and make it clear how to publish information and ask them to consider at least initially ceding their information from a centralised authoritative source. If we can set an example within RIPE registry, maybe we can actually speak to the other registries and have them also offer a mechanism.
WILFRED WOEBER: Okay. It looks to me like we are at the almost very end of this Working Group. So, I'm going to hand over to the new co‑chairs to take over from me together with Nigel, and I'd like to ask Job and Piotr to sort of close it up and ask whatever they want to.
JOB SNIJDERS: Before we formally close this session, I would like to extend my thanks again to Wilfried for being in this position for so many years and helping our community by shepherding changes and management of the database.
So Wilfried, again, thank you very much.
(Applause.)
So now the average age of the chairs has been dropped by two. I look forward very much to working with you guys and sharing the continuity and stability of changes around the database for the next months. Are there any words you would like to add?
PIOTR: Yeah, thank you guys.
JOB SNIJDERS: That wraps it up. Class dismissed.
LIVE CAPTIONING BY MARY McKEON RMR, CRR, CBC
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE
