These are unedited transcripts and may contain errors.
Database Working Group
Thursday, 17th of October, 2013, at 11 a.m.:
WILFRIED WOEBER: Good morning, folks. Welcome to the meeting of the database Working Group. My name is Wilfried Woeber and together with Nigel Titley we are trying to keep this Working Group in the lane and on track. Thanks for showing up, although there is competition from a parallel Working Group.
On the screen in front of you we are displaying the draft agenda, the proposal how to structure this meeting. There was sort of last minute update to version 3 just earlier this morning.
To start out with the administrative matters, we have to do the clerical thing, first of all my big thanks to Nigel who has volunteered to take notes and to our scribe support from the RIPE NCC. Also thanks very much for the very professional transcripts on the screen here. I know that this is not an easy job with all our jargon and abbreviations and the dozens of different words of what is supposed to be the English language. Thank you.
Next thing to do is to finalise the agenda. This is the proposal and unless I hear requests to add to that or to remove some stuff, this will be the agenda we are working from. So any proposals? I think we have got one thing in addition under AOB, one or two, let's see.
Then, the formalities, approval of the minutes from the previous meeting, the minutes were circulated right after the meeting itself. They have been available on the mailing list. I don't think that we received any comments or requests for corrections, so unless there is something that pops upright now within the next 20 seconds, these are assumed to be final.
Some little bit of housekeeping. If you have use the microphones, please state your name and, if it is useful, your affiliation or the number of hats you are wearing because this session is webcast and we can also receive participation, contributions from the network.
And the next thing to do is to ask Nigel to walk us through the open action lists and if you could, please, put up the slides, thank you.
NIGEL TITLEY: Hello there. We were very good last time and cleared off all the action points from the previous meetings, but we picked up five more, so I am just going to quickly run through these.
So, 66.1, this is on the RIPE NCC, and this was to, they gave us a presentation on design ?? on dummification of the database. This is removal of personal identification information and they were to return to community for some clarification of this, and I think they are presenting on that in their ?? in the next section.
66.2, this is a proposal for change in the aut requirements for route object changes for both aut?num and the INET number to just the number owner, I think. And again this is being addressed in the presentation.
66.3 rises a proposal for single sign?on authentication, using your RIPE NCC single sign?on information to actually use as authentication when modifying objects, again being addressed in the next item.
The next is on myself, Peter and Wilfried to raise the issue of internationalisation with the RIPE NCC Services Working Group Chairs. I didn't do anything about this. Did you, Wilfried?
WILFRIED WOEBER: Well, we did not get around to formally address the Working Groups in the sense of writing to the mailing lists. But we had quite a few hallway discussions regarding this item and what it probably would take to get us from here to there if we even want to get there. And this is one of those things that may easily be covered under my item UTF 8 which is a separate item on the agenda. So I think we ??
NIGEL TITLEY: We can regard this as discharged can we, or not?
WILFRIED WOEBER: I would keep it for the moment and let's see what the feedback is during this meeting.
NIGEL TITLEY: Right, and finally, 66.5, on the RIPE NCC to check all their systems are UTF 8 ready and I think they announced on the mailing list they are. Whether we use this or not is for discussion by this group. So that is it, actually. We are doing reasonably well. Thanks very much, everyone.
WILFRIED WOEBER: Thank you, Nigel and may I ask the RIPE NCC folks to continue with their presentation.
JOHAN AHLEN: Welcome, everyone. We are now going to give you a database update from the RIPE NCC database team. Not everyone here knows who I am, so I will start with that. I took over after cava in the beginning of June when he was promoted to CIO. He did an excellent job. It's been a really smooth transition for me too, the hand?over was a pleasure, so into this and ready to go.
First, some numbers. So I am not only new thing in the department; you are all aware that the entire database has been rewritten. It's now Java. We have 2500 units and integration tests, in the legacy code this was 0 so that is a huge improvement there. This is written by developers for developers, super useful. Last time I looked, we had 1,500 end?to?end tests, this is up from 1,000 in the legacy code. These tests cover real use cases and are written mostly by our business analyst, very cool.
Some operational stats: You can go to this link to dig deeper into these numbers. I checked yesterday, actually, and we have about 430 queries per second. This is pretty good. We are up a bit. We can handle the load, and can handle much more than this, so it's cool.
Now, one of the first things I did in my new role was to come up with a new and improved release procedure. The reason for this was that there is a demand or there is a real strong use case from our users that they need to know when to expect changes and what will change, for instance, what will be the impact, so that they can prepare their operations and maybe adjust their implementations.
We always, in the past we tried to ?? or we always, actually, announced what would happen and when, but it wasn't really strict and sometimes we failed in proper announcements, so with this, we have a more formal definition, and so, we have a strict testing period. We decided to put this at a minimum of two weeks, and this should, should be in most cases enough time for our users to test their software and adjust, if necessary, but of course, if the change is big and if the change has a big impact we can also extend this test period to longer. Two weeks is the minimum.
What we are also doing now, we are still working on this, but we have started using the GitHub issue tracker to show what is currently going on, what are the open issues, are there work arounds, which release will they be in. We are new at this and start just a couple of months ago, please bear with us and expect some more improvements on this one.
Now, it's not enough to have this headsup; I mean, the testing period is not only for you to know when something will happen; it's also for you to accept what will happen. The current test set?up, it's not very well suited for this purpose. It's an excellent test environment if you want to play around, if you are at the training course and you want to try something out without making a mess, this is perfect. But, for testing your implementation towards our new releases, it's not good enough. So, what we propose to do is to set up additional test set?up, right after this meeting we will tackle this one, with as close as possible to the real data and set?up. I am not sure we can reach 100 percent and be, have an exact match there but we have to investigate what is possible here.
I wanted also to say, I forgot to mention that the release proceed that we defined in June, it's been working fairly well. There has been some shortcomings and a week before the meeting, we sent a proposal to the mailing list with some improvements to make. This ?? we also invited to a session that was held on Monday, to discuss this, open for anyone in the Working Group. And actually, what we see here is the outcome of that discussion. A lot of good suggestions came there, and we will, for sure, I mean, implement those, and the test set?up was widely discussed, so it's important.
So one of the issues that we found with the release procedure that we proposed in June is the definition of "emergency". We introduced a concept of emergency releases. Now, emergency is relative. What is an emergency to one user might not be an emergency to another, and it's very, very difficult, if not impossible, to define this. So, it took an emergency to actually find out that this was not really a good way forward. So, what we would like to propose now is that we get rid of the concept of an emergency release and, instead, have two types of releases: Major releases. These are, could be big releases. We introduced new features, we changed existing functionality, operational improvements, etc. We keep the test period, two weeks or more. Any impact communicated, any change communicated, you will know what is coming.
With minor releases, on the other hand, we only do bug fixes, and these bug fixes is, for instance, if a user contacts us and says, well, we have found a bug here or we think we have, it's affecting our operations, could you please fix it, at that point we will fix it right away in a minor release, only that fix, nothing else introduced, no new functionality, no changes to existing functionality, unless it's broken, of course, and we will deploy it as soon as we are done. Right away. Transparency in everything we do. Issue track will contain down to the details, you will be able to follow the lines of codes changed there and this removed the concept of an emergency. We don't have to evaluate the requests so much as ?? so much more than actually listening to the user and if the user actually has, yes, some operational issues with this bug, then we will do it, but if the user says that this can wait until the next major release, then of course we will wait. So we will leave it in your hands.
So, I touched a bit about communication. We will improve this, for sure. One of the things we discussed on Monday was documentation related to new releases. And this is not good. It has not been good. It was an action point ?? not an action point but it was also discussed during the last meeting, that we will take care of this, and I will come back to the documentation later because we have a lot of ideas there and we recently did a major review of the query and update manuals, we will touch on that as well in a second.
Now, I'd like to move on. I think you are all aware that the database software is OpenSource. It has been for many years. Waved long?term collaboration with APNIC, actually they have been using our software software and they moved with us to the new redeveloped software. We are seeing a lot of benefits with this. Together, we are shaping the code, we are improving it and fixing issues and talking to each other about how we can do this better, and actually, we have been developing features together, so RD'd up from the WORDS Working Group is a very good example where APNIC did a very good job; and to be honest, you know, a lot of credit for them on this one. We presented together at IETF in Berlin a working Beta of this and we will get back to more on this later in the presentation about what is coming.
It's not only APNIC, we see users are interested in contributing to the code, so the new via attributes submitted by Job Snijders submitted this to us himself and wanted us to tad to the new release. This is cool and we really like this initiative. We will get back to the attributes in a second as well because it's currently in the pipeline. But you don't have to be a developer if you want to contribute. So if you have an interested of a feature it could be a grand feature or a small feature, please contact us. It could even be a test case that you would like us to add to the code, tell us what you want, we will let you know what is technically possible and help you out with the development resources there as well. So please let us know.
There is lass possibility to run the database locally. It's distributed under BSD licence, so feel free if you find a need for this, then just download the code, compile it and start it. Instructions, we added instructions recently how to do this on GitHub and to give you an idea of how accessible this is, we have prepared some USB sticks with a virtual machine running an instance of the database software, containing some dumbified data, we will be giving these out at the end of the session in the back of the room so please grab one. There is a read me file there describing everything, fire it up and all these ?? all the protocols are available. Play around with it and see what you think. And it's very nice shiny USB key, if you don't like the virtual machine, then that is fine.
Action points: I will now let Denis Walker, our business analyst, take over, he has been with RIPE NCC for ten years, a familiar face to most of you.
DENIS WALKER: I think a lot of you have probably seen me already. The first of all, we will go through the action points. 66.1, RIPE NCC to return to the community for clarification dummification design goals. We will talk a bit more about this later in the presentation so we will come back to this one.
66.2, RIPE NCC to raise the proposal for AS authentication on the database mailing list. I wrote an article on RIPE labs clarifying how the RIPE database works as an Internet routing registry. We published on the RIPE Labs and covered a lot of these points, some of the particular issues but how we allow copies of AS numbers into the RIPE database, it gives the impression that the route objects are actually authorised by these AS numbers but in actual fact we bypass the authorisation. So there are concerns here about the way this authorisation is done. We didn't actually get any comments or feedback on that so perhaps if you can go back and have a look through that article and we will take it from there.
66.3, this is about the single sign?on. This is an ongoing, again we will talk about it more in this presentation, a separate action point.
66 .5, UTF 8, technically this is feasible. It requires very minimal changes to the database to have it fully UTF compliant but I believe Wilfried will talk about this and the implications of doing this because this isn't just a technical issue.
What have we done since RIPE 66:
We have a working implementation of RDAP, the Registration Data Access Protocol, which was developed with APNIC. We demonstrated at the IETF meeting in Berlin. We have a Beta service available. That is an example of how you would use this to query for a specific IP address. Give it a go, just change that to your own address and see the Jason responses you get back from it.
This is an ongoing project, it's still under development, the RFCs aren't completed yet so it's work in progress, although we have a Beta available, it will change as the requirements and the development process goes on.
We said last time we had these met at that data tags. These are tags which we can add through the software, they are not user addible yet. We have marked everything as either RIPE registry resource or RIPE user resource so you can see which part of the data and database are managed by the RIPE NCC, for example, the allocation objects, and which part are managed by users, all the assignments make from the allocations. So it's just a way of showing which ?? who is responsible for which part of the data.
You can see this data with certain queries where extra flags give you the option to display the tagged information if it's there.
You can also filter on these tags as well, and we will put up a web page showing what tags are currently in use and what they mean.
We also mirror the other four RIRs databases' operational data and we do this based on their delegated stats so. What we now do is, we have ?? this is the RIPE GRS service, the global resource service. We build a copy of the RIPE database and the operational copy of the other four RIRs, these are rebuilt every day, the only data that goes into these databases is what is in the appropriate delegated stats file for that RIR. So in effect, this is a complete global resource service showing all the address space and AS numbers, there should be nothing missing and no overlaps. We added an extra query flag minus minus resource. If you do a Whois minus minus resource and give an AS number or an IP address, we will look through this set of five databases and we will return the one authoritative answer for you.
What else have we been doing? We have included a dry?run in the updates. Currently it only works with a single object if you put one object in update and include this pseudo attribute in the same way as would you put "delete" or "password," you put "dry run." We do all the checks, the syntax checks, business rule, authentication, but we just stop short of actually updating the database. You get acknowledgement back showing what would have happened, where any errors would have been generated, we also include if it's modified, give you the diff to show you what would have changed in the object as well.
We could improve this, if you find this is a useful service, we could make it work on multiple objects but technically that is a lot more challenging. Have a play with it, see if you think it's worthwhile. If you like the feature, let us know.
We have also added minus minus diff versions to the set of query flags now for history, so now you cannot only get the history of any non?personal object type object in the database, but you can also now compare two versions, so you can see what changed over time very easily.
Also by default now, all notification of ?? notifications where an object has changed will show you the diff. Previously, it said this object showed you the old version as being replaced by this object and show you the new version. Well, certainly for something like aut?num with 10,000 lines that is a bit difficult to manage, so what we do now the first bit is showing you the difference and then we know you the complete new object as it is in the database.
Also, since the last meeting, we have, we were asked about why do we return objects which are syntactically incorrect. The policy we used to have was, it's not our data, so we never like touching users' data, even if we changed the syntax we never used to go through and fix all the data within the database so there is quite a lot of objects in the database that wouldn't part the syntax rules that we have today. So if you actually want to see which those are, we have now added this minus minus valid syntax option so you can do any query, add this flag, and you will get rather than getting the objects that are syntactically incorrect you will get a comment saying that that object has been omitted because it's syntactically incorrect. It might be useful if we did the reverse of this so you can do a query and return just the objects that are syntactically incorrect so you can check out your own data and see which would fail if you tried to submit it now as an update.
The restful API has been integrated fully into the Whois code, whereas before it was a Beta service it's now production quality.
Please give it a try. I think you will find over this that this becomes a very powerful way of doing updates and queries for the RIPE database.
We did a standardisation and clean?up of the representation of IPv6 addresses. We used to allow many different form mats of these addresses into the database. Now, it's basically the shortest version and we did clean up those that were apparently wrong in the database.
We have done a major review now of the query and update reference manuals. It's a while since we did this major review. We think we have got it pretty much up?to?date now but we will talk a bit more on documentation later. We are still not happy with what we have got so we will be working a lot more on this.
OK. A few of the unresolved features that were outstanding for the last couple of years. This is about data dummification, which is one of the action points. We published a document on RIPE Labs which explains what we were trying to do and why we want to do it. We got a few comments but nobody really objected to it; there were a few issues that were mentioned. We would like to go ahead and implement this in one of the up coming major releases so have a look at the RIPE Labs article, remind yourself of what it is we are trying to do and let us have any feedback or comments that you might have.
There is also proposal made at the last RIPE meeting to replace a lot of these static objects, we have things like 0/0 but we don't control the whole IPv4 address space so we shouldn't really have this object in the database which gives that impression. It also has references to IANA and things in there and they actually do get some abuse complaints because people query non?RIPE address space, get this 0/0 object and think, IANA is the company that has this, I will send them a complaint.
Also have these /8 objects, we have AS blocks which are pretty much meaningless in many senses. So, what we want to do instead of having these static objects sitting there in the database, which as we get into a market, and particularly if you start into RIR transfers, these static objects don't really cover reality. So what we want to do now is, if you query for anything like this, rather than have these static objects sitting in the database which we will return to you, we would rather return information to you from the delegated stats, which is much more up?to?date than these objects that have been sitting there for years.
So we are not getting rid of this information; we want to change the way the way in which we present this information to you. But we'll put forward a more detailed implementation plan to the mailing list and explain what it is we are trying to do here.
Another thing we mentioned at previous RIPE meetings, add a flag to request personal data. In other words, we think, logically, it's actually wrong to, by default, always return personal data whether you want it or not. What we have now is you do a query, you don't actually want personal data, but we know you don't want it but we'll give it to you anyway because you didn't add a flag telling us not to give you what you didn't want and we knew you didn't want so the logic is kind of weird. So, we would rather have it so that you ask for something, we give it to you and it's very explicit. But this is a change to default behaviour, we know it's a sensitive thing. We did get some rejections to the idea of changing default behaviour, but nobody really objected really to the change in the logic. So, we would like a bit more feedback from you on this.
Also, related to that, the way we block people, because of the data protection laws we can't allow you to have unlimited access to personal data objects. So there are limits, it's defined on our website, our terms and conditions. So, the way it works now is it's all or nothing, so if you reach that limit, we just cut you off. You can't even query route objects or do anything, we block you out completely. This is the way it's been for the last ten years but really, this is not a good idea, either. So what we would like to do, when you reach this limit, we simply don't return any more personal data objects to you, but all the operational data, nothing will change, you will still get all that, and if you hit this limit halfway through a query output, we will simply stop providing any more personal data objects in, but all the rest of the operational data will still come through and there will be some comment at the end saying you have reached your limit and no more personal data is available until, for the next 24 hours.
We would like a little bit of feedback on that as well from you.
Some upcoming features:
We realised from a lot of the feedback we get from you that people sometimes struggle with this authorisation of route objects because you need multiple people to submit it with different passwords, different PGP keys, whatever. And it does sometimes get difficult. You can do it in different ways, with MNT routes but that means you have got to change your data to add the other person's maintainer on the MNT routes, so it still gets complicated. What we are trying to do is provide a means where we have partial updates, so we have two people need to authorise the creation, one person submits the object with the authorisation they have, we stick it in a queue and wait for a week, if within that week we get some of the other parties submitting exactly the same object with the missing bits of authorisation, we match the two up, everything passes and we create the object and notify both parties that it's been done.
We'd like to put this out on the test database and let you have a try with it and see what you think. I think in some ways it does get around this idea of either having to use NMT routes everywhere or asking people to add passwords or sign e?mail that you pass around between people. But we will see how it goes.
We had this request for these input via attributes, it's only a draft RFC but we have seen support pour it on the mailing list so we are quite happy to do it on ?? put it on the test environment and let you try it out.
But any change to an aut?num obviously does need good communication because these things are important for routing issues, so we will be talking a bit more about that in the routing workshop. Do you have a question?
AUDIENCE SPEAKER: Rob Evans. Interesting to see your proposal just there for changing the authorisation for route objects because that is something that has come up time and time again and never really been able to get that much traction of doing it correctly so I would be grateful if you could also mention that this afternoon.
DENIS WALKER: Yes. I can do, yes. Adding abuse?c, we have listened to the feedback we have got from members through our customers. We appreciate that some of you are struggling to work out how to add this. We thought it would explain it quite simply but not to everybody. So we have basically provided a much simplified way of doing T it just does a standard thing so you log into LIR Portal, go into a page, one field and type an e?mail address in it and click a button and that is it done. Behind the scenes, we will then create the role objects, put the abuse mailbox in it, add that reference to the abuse?c and we do it all for you.
The deadline for adding this was end of quarter 3, but because of the feedback we have got, we thought it would be a good idea to extend to the end of November. Shortly after the RIPE meeting we will put this up on?line and hopefully a lot more of you will be able to add it.
We will talk a bit more about that in the Anti?Abuse Working Group this afternoon.
Single sign?on, which was another of the action points:
We haven't actually moved forward with this since the last RIPE meeting. Basically, what we would like to do is now have RIPE access, which gives you the single sign on. We want to allow you to be able to use that sign on authority to update objects that you are responsible for. We will do a more clear implementation plan and put that out to the mailing list shortly after this RIPE meeting.
And now I will give you back to John Ahlen who will talk about documentation.
JOHAN AHLEN: Yes, so, as Denis mentioned and I mentioned it as well, we did a major review of the documentation and updated it to be as good as we can. The current ?? this solved the urgency or the emergency with out of date documentation but it's not good enough. During the review, I mean, one of the big things we found that it's very difficult to maintain this documentation, it's huge, it's 100 pages, technical information wrapped in descriptive text. We can do better here. So, that is one thing.
It's also very difficult for you to read. It's difficult to find what you need. You have to search through this, and it's not intuitive. So, the style and the content definitely needs a rethink here. One of the good, really good points that came out of the meeting on Monday where we discussed the release management was to link documentation to the version so that you can see exactly, yeah, what it relates to.
Another point, it's not on this slide, but of course when we add a new feature, documentation will join. We won't put anything in production unless the documentation is there as well. So, the coming time after the RIPE meeting here, we will work together with our coms team to try to improve this as much as possible. What the format will be in the end, whether 100 page PDF file or some other medium, I don't know. It's all about presenting this in a clear and easy to use way and of course it has to be easy for us to maintain so it gets done without too much overhead.
Now, I would like to talk about the survey, that was also talked about in the RIPE NCC Services Working Group yesterday. A lot of valuable feedback here. 3,000?plus respondents. Overall, we scored pretty high. It's an important service, of course. Some valuable points in here. A lot of respondents ?? I am showing two here, so let's start with those, and a lot of respondents mentioned that if you are a newcomer it's very difficult to understand an updated ?? and update the database. We are well aware of this and I have in my next slide, I will get into details about this one.
The second big request was to allow for bulk updates, the ability to synchronise maybe from your own servers. This one we have to investigate. I think we will for sure have something there, but it has some implications and we need to see what is technically possible, there is some security concerns here that we have to address and I think we will come up with a plan and a proposal on this one to the Working Group soon, as well.
Now, database, difficult to use. Yeah. User experience improvements. A lot can be done here. This relates not only to the actual software and how you interact with the protocols and the user interfaces but it's also about everything surrounding this, how the users find out about the database, where do you come in contact with it. How can we improve these points? Working Group mailing list is one way. Can we add more ways, feedback, forums, trainings, feedback from trainings, survey, is one for sure, we will try to identify all these channels and really work with them and improve that.
So, what we would like to do here is to improve the overall experience and that includes the website as well. When you go to ripe.net/dB, can you find what you want. Here we need your input, not only yours, the newcomers, listen to what new people say and do something about it.
So, the third outcome, improved websites, better user interfaces, simplify, intuitive, and I think, I hope in the coming service that we will notice this and users start saying that, wow, it's actually easy to use.
Now, second big project coming, resiliency, the RIPE NCC now has a hot node in Stockholm in case of a major incident in the Amsterdam region. This node is always active and one of the first services that will move there is the database. We are looking at hard wear requirements now. There might be some software changes to allow for this. For instance, the current back end has some limitations when it comes to the set?up so we will investigate that as well. We will get back to you on this as soon as we have something.
Now, questions?
WILFRIED WOEBER: Thank you very much. So, you beat me by 20 seconds when I ask you to speed up. So this is a broad overview with right focus on things that already have happened and plans how to improve the management of the software and all of those things. There are a couple of things where you already have asked for feedback and this question actually goes to all of you, even to those of you who are sort of looking into their screen reading their e?mails, all of you who are interested in one way or another or user of the database machinery, you are invited to join in. There is one thing which is still under heavy discussion, and that is the aspect of roll out of software and the communication and that sort of things, the lead times and sort of what the details of the procedure are, and Ruediger has one or two slides which are related to that topic, correct?
RUEDIGER VOLK: Yes.
WILFRIED WOEBER: May I ask the technical people to put up that slide and Ruediger to give us his point of view.
RUEDIGER VOLK: Let me first start to say since end of June, I have seen lots of effort and real improvement on the side of the NCC in this regard. However, looking at the whole thing right now, including discussion on Monday and final review of the slides that were presented, I, unfortunately, have to report I am not feeling happy enough and, unfortunately, I feel I have to, I have to present a kind of a critical user view. There is one old time commentator running around meetings who many times said OK the RIPE NCC doesn't have the mindset for operational responsibility, and I discounted that a lot of times. However, fairly short after the last RIPE meeting, we had an incident that made me re?evaluate, unfortunately, under very painful circumstance. At that point, we had a really major impact due to an unannounced change of the RIPE database software for our network. I had to figure out that at that point I look back and I forget, damned, we had three incidents like this, impact wasn't that hard to our users, within less than 12 months, and in the procedure of dealing with that incident, we unfortunately made some observations that were really twisting my mind, including, including ?? after ?? said yesterday we have been most of the time announcing software changes, in the process of dealing with a reported software failure with document, exact documentation of the failure, not having received for three or four hours any response and not seeing any status change on the service status page of the RIPE NCC, indicating that something was wrong, I got a message and I am citing that literally, that included: "Please note that we improve the database code often and we do not send out announcements when the updates have no visible effects on the users." Well, OK, there may have been some updates that did not have visible effects predicting visible effects to users, of course is kind of a prophecy miracle, but, so, let me turn to how to proceed and what requirements are.
And well, OK, in the intense discussions we had after the incident, at some point in time I quickly did a set of minimum requirements for getting into a stable state of software, where I would hope I could adapt my processes so that I can rely on the RIPE database, meaning if those requirements cannot be fulfilled, I have to say, to me, it looks like I cannot rely and I have to find ways to do without the RIPE database, which is, of course, kind of questioning why I am a member of RIPE NCC. So, what are the requirements, and unfortunately, Joe /HAPB in the things that you presented, you are exactly not meeting this. All scheduled changes must be announced appropriately at least a week in advance. Well, OK, for major releases in your current plan, you are a little bit more generous, doing minimum requirements I was being as strict as I possibly could. Appropriately, implies I need to have sufficient information to make an assessment and that takes time and effort on my side, of what impact to expect out of the change. Unscheduled changes have to be announced as soon as possible. I guess that will be met now. And the hint that as soon as possible is only post facto, well OK, I guess that is not to be discussed and not really an issue, but the last point I think is where we diverge. "Unscheduled changes must not happen unless to fix bugs with operational impact" and you have to do a careful evaluation of the known and likely impact of the existing bug and the risks and the impact created by the change. And I remember I sent out a question to some knowledgeable colleagues about, well, is there anything unreasonable in these requirements, and I did not really get an objection, and for meeting, for meeting the requirements of people who are actually using operationally with automatic processes the database, I think this is really something very close to the limit that is needed. And yes, I can see the last bullet means that you have to do something extra and you want to avoid it, but that is ?? kind of you cannot really escape that.
The other thing is, I didn't attend the Working Group meeting last time in Dublin, it was more important to be in the other room, and I was very annoyed to figure out afterwards that there, cava reported yes the database has been up all time and he didn't report how many bugs were actually reported and had to be fixed, while the database was up. I very definitely request to include in your efforts to make things transparent, to report about the bugs. I rather would like to know whether, well OK, I am the only guy who is hit by stuff that has operational impact, that is going ?? that would be important information for me and, well, may make me change what I am doing, but kind of the trust in getting a reliable service here has been fundamentally removed for me and my management. And for getting to something where I actually can trust and can rely on automatic stuff working along, actually leads a lot of input that proves to me that we are ?? that we are getting better.
WILFRIED WOEBER: This is actually the point where I'd like to take the hook, because we have listened to these criticisms and these requirements and we have had quite a few talks in the hallways during the Monday informal get?together which was open to everyone walking into the room, I might want to add, and I think everyone in the room and in particular on stage, they are hearing what you are saying and my proposal to actually go ahead is to implement, as soon as possible, all these improvements that have been presented already and if you really feel that this is not good enough, after a reasonably short or long time, observing the effects of this improvement process, I think we have to take it back to the mailing list because there is one thing to sort of bring it up in dedicated meeting or during this get?together here, but sort of the user community of the database is much larger than that and we have to find some way forward. OK.
Ruediger, short if possible, please.
RUEDIGER VOLK: Yes. Kind of, kind of ?? I very seriously request that what you are doing should include a very serious effort to minimise the number of unannounced ?? and "unannounced" means ?? an announcement with a working day time, does not allow the usual operator to actually do an assessment and check things and so on. Absolutely minimise the number of changes that happen without at least a week's announcement time.
WILFRIED WOEBER: OK, we have got that request.
SHANE KERR: I don't want to extend this painful session any longer than necessary, but it occurs to me that Ruediger is putting forward a lot of requirements that are very operationally orientated for the RIPE NCC. It seems to me like it's basically crossing over into the services area.
WILFRIED WOEBER: Indeed, and that was the reason why I tried to point the other community to this presentation here.
SHANE KERR: Yes. I don't know how much discussion ?? it doesn't really seem database related to me at all, to be honest. Of course, it's about the database peripherally.
WILFRIED WOEBER: You are right. And we could easily take that suggestion and put it on to the draft agenda for the next meeting Working Group session. This would be perfectly fine for me because we always understood that we are responsible for the nuts and bolts but the usage is ?? the use of the services is sort of affecting a much broader community. Thanks for reminding us. Any other questions or comments?
JOHAN AHLEN: No, I just wanted to comment on Ruediger's presentation here quickly, and I agree with Ruediger, most of these points are actually covered by what we proposed earlier in our presentation and the place where we divert is the last point here. Within parentheses, "The careful evaluation of known and likely impact of the existing bug." Yeah, impact. What is impact? Is it, if we have one user, his business depends on this? But we have 99% of the users they don't care about this issue. Is it on a ?? does that warrant a change? And, you know, this is where we are struggling. And in my proposal, I want to remove this completely. We fix bugs, right away, if the user tells us that this affects my operation, we take it super seriously, go right ahead, fix it, put it in production right away with announcement that this bug exists and that this release is available in production. We skip the test database set?up. The change is minimal so this is where we are discussing. I mean, we will of course run through all our tests that we have, our own pre?test environment, we have tests confirming that this issue has been fixed, in the code. It's a minimum code change because I mean, put yourself in the shoes of a user where you are affected by this. I mean, your operation is down. How would you want us to deal with that problem?
WILFRIED WOEBER: I think we have rehashed that more than once. I think we had enough explanation, sort of, what the different views are and also what the reason is that the two parties here do have different points of view and I think the only reasonable way is to try to improve as many improvement ?? to implement as many improvements as possible and try to make it as high quality as possible and have a look at what is left to be tackled. There are two, at least two gentlemen queuing the mike, go ahead please.
AUDIENCE SPEAKER: And I just want to repeat the message that I have sent to the Working Group mailing list about the quality of policy data.
WILFRIED WOEBER: This is a different agenda item. Sorry. We are coming back to that maybe under any other business but we have to really have a look at the schedule and we have a couple of presentations still on the agenda. Sorry.
AUDIENCE SPEAKER: OK.
WILFRIED WOEBER: Maybe later.
AUDIENCE SPEAKER: Bill, right now if I am in the right place of the agenda, my question was to the Denis presentation, I have no opportunity to ask. It's the question of same background about these personal data. You mentioned that there is an idea about when you hit the limit, you will not be blocked of getting the normal data, but you will be blocked with receiving the personal data, yes? Am I correct?
DENIS WALKER: Yes, currently the blocking is all or nothing so once you hit the limit of personal data objects we block you from everything.
AUDIENCE SPEAKER: I understand. The real question is: Are you going to dumbify the NIC handles when you ?? when someone hits the ratio and will be allowed to receive an operational data or not?
DENIS WALKER: The NIC handles in author objects won't be dumbified, no, but we simply won't return any more person or role objects within than 24?hour period.
AUDIENCE SPEAKER: Because some people recognise NIC handle as a personal data at that and that is why the question was raised by me. So, yes.
DENIS WALKER: I believe there are some people who do think NIC handles are personal data but our advice is that we are OK doing that.
AUDIENCE SPEAKER: The same question to the situation you describe us, we will return only the data you ask for, for example, if you are going to ask for INET num you will always only response with that personal data, if I correctly understood it?
DENIS WALKER: Yes, again, the default behaviour now is if you simply query for an INETnum, you will get the personal objects, the role objects, the organise objects and you didn't ask for that and we don't know whether you really want it had or not unless you put in a flag that specifically says "I don't want this information."
AUDIENCE SPEAKER: If you change the default to only return the data you are asking for, so the question is also, are you going to dumbify the NIC handles or not?
DENIS WALKER: No.
AUDIENCE SPEAKER: OK. Thank you.
WILFRIED WOEBER: OK. Any other comments to this presentation and to the operational impact? Then, thanks again. We are moving on to the next item on the agenda, and given the fact that we have used quite a bit of our Working Group time on this agenda item, I propose that we swap the next two ones and ask you to present the geolocation thing or information first and then I will go with UTF 8 afterwards.
AUDIENCE SPEAKER: I am Zoltan Szamonek. I am a software engineer at Google. I am working on improving BGP. I am going to present here an existing practice that we use at Google already. Giving providers ISPs the availability ?? so ISPs will be able to publish their IP to geolocation mappings as a feed, and that can be used by all the geolocation providers, including content providers like Google.
So why are we doing this? Many ISPs are coming to us telling us that their users are getting redirected to wrong countries, they are getting incorrect language data and they want to fix this.
They also usually say that they try to update the Whois database or talk to RIPE and that had no effect for several weeks. I am of course ?? update they went through but the user issues are not fixed.
There are also technical conferences like this one here, which use the same IP block over and over again but from different locations, so last time it was Dublin and now it's Athens and previously this used to be a problem.
Our goal is to provide a way for these IP owners to actually provide the data in an easy to access format.
One more thing here: What we have seen is that it's relatively easy to get geolocation data for IPs once the IPs are in use but what if the IPs are getting reassigned or the meetings moved to different locations? So this also gives the possibility to update the locations in advance, preparing for, for example, this meeting.
Our goal was not to give something complicated that ISPs would struggle implement, but to give a very simple format and to provide some kind of guidance as how to do this. So this is the format that we propose. We would like to have a CSV file that has an IP range and some location. The location is optional, it includes country region, city, post code, but that is about it. So the IP range is required, it can be a single IP address or a CIDR block and then the provider of this data can actually tell us which country it is. If it's important it could specify region, city or postal code with respect to privacy. We do not want to do other geocode information because that might be potentially misinterpreted and used as precise location down to house level or even below. Even if there are some accuracy, metrics are added to that.
We also notice that using geographical coordinates like latitudes and longitudes are harder for ISPs to provide, at least smaller ones. So just giving a two letter country identifier, it seems very easy.
So, these are some examples. The RIPE meeting here now uploads the feed, well hosts this CSV file on meetings.right.net talking about the IP ranges and the locations of the current or next RIPE meeting. We use this one to get the data a couple of weeks in advance and prepare most of our systems for this change. Previously, we got the comments a couple of times that the RIPE meeting has started and Google was still thinking that the meeting is in its previous location.
The alternative would be that Google would say that yeah, this is owned by RIPE so it must be Amsterdam. I don't think either the previous location or Amsterdam or Netherlands will be really good user experience.
We have an RFC draft available through this link that describes in more detail the format and the goals what we are trying to achieve. And thank you very much. Are there any questions?
WILFRIED WOEBER: Thank you very much. Yes, I do have a question. I didn't read this draft yet. The assumption is that anyone who wants to tell you about geolocation has to push it to Google, is that correct? Or what is the idea how to sort of communicate this information?
MR. SAMMON: So, what we would prefer is that the owners of the IP blocks host the web server, FTP server and place the CSV file. This would allow the interested parties like MaxMind and other providers as well to just go there and update their data sets accordingly.
Currently, the way of publishing the URLs for the FTP or HTTPS allocations is not very well implemented. We are getting individual requests from ISPs that we have published a URL here, so this would be one place for RIPE to actually help here. If the ISPs can have a central place to publish this ?? these references, then that could ease discovering the data a lot. We think that it would make sense to keep the data itself on the ISP's premises so that they have control, they could update them and delete it if necessary.
WILFRIED WOEBER: OK, thank you.
ROBERT KISTELEKI: Robert Kisteleki, fellow Hungarian. There is going to be a presentation at the MAT Working Group in the afternoon about a geoIP infrastructure idea that we have, so if you are interested, please come to the MAT Working Group as well.
The other thing is, please stay away from ranges, so I really hope when you say "range" you really mean prefix?
Both are doable but one is more painful.
ZOLTAN SZAMONEK: Useful but harder to manage.
AUDIENCE SPEAKER: Exactly.
AUDIENCE SPEAKER: Carl from RIPE NCC. Because we appreciate feedback from different members especially, and people who get addresses through RIPE NCC or other RIRs and I just wanted to point out this is a real issue, solution I don't know if that is the best for solutions but some people have real operational issues because they ?? they are LIR is located on boarder and they provide services to two countries but there is so many issues and they report back to us, we are the RIR in charge we cannot do anything, we point them out to some commercial data providers which I think is good, if this is a business around this that should be stated but the reality is the IP holder only has relation with RIR and we can verify that relation so if we can do something in that area I just wanted to emphasise that will be really good for the end user because this is an issue that we get many complaints from, particularly end users, they find us and say why it's happened.
WILFRIED WOEBER: Thanks, there is two sides of the coin, one is the tech neck if I canal implementation and how to manage the accuracy of the data and granularity of the data, so with everyone who happens to have an INETnum object in the database be able to run his or own own server and advertise that? Or would it be controlled by the food chain of address management? There are a couple of things we probably have to take to the Services Working Group again.
AUDIENCE SPEAKER: From the RIPE NCC. I have a question from a remote participant. And the question is from Jan, from the Netherlands. The question is: What is the current way to fix a wrong geolocation within Google since some weeks we are registered wrongly, what this previously always been good? Google, YouTube, are the only geolocation that is currently not working correctly.
Zoltan Szamonek: This would be one way to fix the geolocation, the owners of the IP blocks or ranges would publish a feed in this format and tell Google about it. There is another way, there is a help centre article and actually a forum out there for Google where users can report these issues. And then we are looking at those.
WILFRIED WOEBER: Ruediger you gave up?
RUEDIGER VOLK: Yes.
WILFRIED WOEBER: First of all, thank you for the presentation because it is exactly on time because in the database we, since a while, we do have some mechanism to register geolocation information and this has never been marked to the wide audience and it was more like experimental feature, if I might use this IETF term here.
So I wonder how many of you are aware of the fact that there is mechanics around to register geolocation information for INETnum objects? Raise your hands, please. So this is more than I had expected.
And how many of you are actually sort of messing around with it? Two. It's a way forward ?? the way forward probably is to issue that broader field of activity maybe to the Services Working Group again, because personally, this is not the position of the Working Group, that is my personal opinion. I don't like to have mechanisms in the database sitting around and hanging around which nobody uses or for which we don't have a clear understanding what they are meant for. So I think we are done with this one and thank you for the presentation and I will try to talk to you afterwards during the rest of the meeting.
The next thing is probably rather brief and short and it's follow?up ?? following up on this UTF 8 thing, giving you a little bit of background why some of you thought a while ago that as a community and as the RIPE NCC, we should start to investigate whether our machinery is UTF 8 compatable or UTF transparent, and this is just a technical requirement. The real issue here is if we are technically able to register data which is presented, which is registered, for example, in cyrillic
Script or Greek characters or if you think about stuff that is going to come up with the next probably 6 to 12 to 18 months with ICANN putting a couple of 100 or maybe more than 1,000 new top level domains into operation and some of them will be actually in non?Latin script, then there is a good chance that someone wants to put stuff into the database which is no longer simply Latin script. There is also the simple fact that we are aware, I guess, that the NCC service region is covering a geographic area which has more than one script and more than one language so this technical capability of dealing with UTF 8 characters is one side of the other but the other side is actually what are we asking people to do, and sort of what is the environment where the sources of data can get guidance, what they should put into the database and on the other hand, on the consumer end, if you want to query the database or take information from the database or maybe even from NCC's sort of internal business database, the question is, has everything which is related to contracts and that sort of things still in English language or is there a use case for becoming more user friendly maybe or even more correct or more authoritative, because Peter from the University of Technology has alerted us more than once already that even in the sort of Latin script area with sorts of funny characters there and dots on top of single characters like I am carrying on my name, Johan is carrying on his name, there is a difference whether you omit that stuff or you actually do it correctly. Whatever. The definition of correctly is. So this is just a heads?up to give you a little bit of background and this takes me to any other business. And one of the any other business is provided by Ruediger.
RUEDIGER VOLK: Sorry to annoy everybody before lunch, but Denis was talking about the efforts of the database team to make registration of abuse contacts easier. One thing that is still missing there is some documentation that tells people when they are compelled to provide that e?mail address that has to go there, what actually to expect in messages that will go there and how to react to them. It looks really like bad style to compel people to provide e?mail addresses and then say OK, you obviously know what to expect and there will never be any question about it, that is at least unrealistic for either very large organisations whose functions are spread out and the poor guy who has to manipulate the database information is quite certainly not the person and not in the department and far away from the department that would be doing the abuse stuff, and calling within a large enterprise OK chart for ?? we need the contact for this and so on, does not work very well when there is no documentation of what is supposed to be handled there, and also, for small ones that commonly do not do full?time networking and so have minimum knowledge about what happens on the network.
AUDIENCE SPEAKER: RIPE NCC. To give a quick reply because I was involved in all the discussions for that. There was an AC MTF abuse contact management task force which came up with the basic ideas and that evolved with the policy which led it to this new attribute, that was discussed in details. I agree there is an implementation issue there because if you have a very big organisation or very small organisations, there is no clear format. But this was specifically discussed there and I think Wilfried was also part of that, and there is even some standard for markets one was being discussed at IETF and others, but the task force explicitly decided not to get into that and they had reasons for that so it was put on the table and we just implemented what was came out of that.
WILFRIED WOEBER: Sorry, this is the technologies and this is the nuts and bolts and yeah, I fully agree. Still, I can see that there is maybe room for improvement at the interface, at the user interface, either pointing to sort of a block of text or adding a question?mark button and if you don't know what to put there, you get a pop up or whatever. So my feeling this is more a coms issue that is nuts and bolt.
RUEDIGER VOLK: Documentation is the communication problem.
WILFRIED WOEBER: We heard it, we have got it.
RUEDIGER VOLK: If the communication there doesn't work, my suggestion for a valid input on being compelled to put something there, is to put an e?mail address that has an auto responder that say we are pleased to see your message, we value your message, unfortunately we haven't been explained what to do. Thank you.
WILFRIED WOEBER: OK. Again, I think the documentation issue is understood, the other thing is probably services and operations and philosophy and religion.
DENIS WALKER: RIPE NCC. The policy was very short and very clear. The policy was for the RIPE NCC to provide a mechanism to have an abuse e?mail address. The policy did not in any way cover what would happen if somebody sends an e?mail to it, but I think this is more for the Anti?Abuse Working Group and it was very clear, that, as I understood it, this was going to follow on from this. This is the first stage, we need to have ?? I mean, we had these things before but we had them all over the place. The idea was to rationalise it and to have one clear place to put this and this is an improvement and then we move forward.
PETER KOCH: So I would like to suggest that you significantly talk past each other right now. The ?? I was part of that task force, which I may regret.
WILFRIED WOEBER: You are not alone.
PETER KOCH: So what I hear Ruediger saying is that once the object maintainers have been requested, arm?twisted, whatever, to put something in there, they should get a clue of what actually might happen. They may actually see a lot of whining end up in their mailbox, which is a problem. The fact that Denis was addressing it at the task force and the Anti?Abuse Working Group explicitly abstained from expressing expectations or even make mandatory requirements into the policy for what ought to happen, and these are two different issues. Of course, it's good to abstain from making these suggestions or requirements, but the communications part that Ruediger was mentioning, I think that is kind of important there.
So, that is kind of a warning sign, so be aware that when you put that address in there, you may end up in tonnes of weird complaints and delete might actually be the right response.
WILFRIED WOEBER: Understood.
NIALL O'REILLY: University College Dublin. I don't really want to prolong the discussion, but I need, for the record, to mention that the rationalisation that Denis was describing as an improvement is not necessarily seen by all of the community as exactly an improvement.
WILFRIED WOEBER: Noted. And even written down and on the screen. Thank you.
So, I think the queue is empty so we can go to the next item on the agenda and I think that is any other business, and I think there is two items left out of the three that I have accumulated.
The point to the geolocation presentation and activity in the MAT Working Group has already been delivered so this is off the list. I am having a small item here and that is letting you know that the Chairpersons collective, including the Chair of RIPE, since quite a while, has started to discuss the management of Working Group Chairship, and there is quite a bit of misunderstandings and different points of view during this discussion amongst the Chairpersons' community.
My personal feeling is that it might be more useful to have such a discussion in the community at large or at least or at the Working Group that might be affected, instead of during the upcoming lunch in five minutes from now, but that is just to let you know that this is happening at the moment, has been happening for a couple of weeks, a couple of months, and you might want to think about how you want this minute, this Working Group or maybe some others, how you want your Working Group managed and whether you want to have enforced chairship, chairperson ship rotation, some ideas like you want to maybe to have a nomination committee or an external contractor to managing Working Groups on a very neutral basis. I am, on purpose, exaggerating here a little bit, but I am personally feeling extremely uneasy following up on this discussion. And the thing I wanted to let you know is that as soon as you think that I have done this job long enough or maybe even too long, please catch me in the hallways and let me know or talk to my co?chairpersons and let me know by that path. It is definitely nothing I want to cling to because I am earning truckloads of money for doing it.
With that out of the way, I think I can get to the last one that may be still on the agenda, I think starting yesterday we had an exchange of a few e?mail messages with regard to the consistency and data quality of the routing registry in the RIPE database. I think there was the gentleman earlier trying to inject his comment by way of walking up to the microphone and I think this would be the appropriate point in time to do that, because any other business, it was not formally on the agenda previously.
So, please go ahead if you are still interested to do so.
AUDIENCE SPEAKER: Thank you. So, there was a very good numbers, there is a number of users, there is a number of queries at every moment, but at the same time, the quality of policy data isn't as good as the number of users. There is only ?? as I was writing in the mailing list, there was only a 10% likelihood that you would retrieve good policy data from RIPE DB, and at the same time, on one hand, you have a situation that people are believing in this data, from end users to network engineers, they share references, they share references not at ?? system holders but to RIPE stats and RIPE DB. And there is no opportunity just to say we are not just checking the syntax, you have to verify this data. You have to find opportunity to do it. And on other ?? so one opportunity is to rememberify this data and another opportunity delete it at all because you are making people ?? people are Mick of making mistakes.
WILFRIED WOEBER: I sort of like the idea to simply delete the route registry from the RIPE database because it would really solve one of the discussion items we had on the agenda today but I am poking fun at it of course. So thank you for this problem statement. Again, I think this is something that we as a database Working Group community should keep in mind, but again, it is operational and it's, as you are referring to routing registry object or information, I guess this is mostly in the ballpark of the routing Working Group and I think we should make sure that we move this discussion or at least include this routing Working Group community in this discussion trying to find out what the problem is, how big it is and how we can tackle it. Thanks for bringing it up. And this leaves me one minute before the formal end of this Working Group meeting to Johan showing you something of fun.
AUDIENCE SPEAKER: I wanted to remind you that you should pick up a USB stick in the back of the room. Everything you need to run the virtual machine is on here, plug it in, follow the "read me," I think you might install virtual box, port 1043, pretty, shiny. This one is for Wilfried.
WILFRIED WOEBER: And as I got one of that stick technology, that particular one, with the metal skin, be very careful, they are known to short out your USB connector if you are not really careful when inserting this thing into the slot. Thanks Johan.
AUDIENCE SPEAKER: That was the plan.
WILFRIED WOEBER: So, thank you, thank you, everyone, thank you in particular to the people employees from RIPE NCC for doing all the legwork before the meeting, for the presentations, thanks to all of you and a heartfelt thank you to the techies sitting in this corner and helping us with running this Working Group meeting as smoothly as we were able to do.
Have a nice lunch and see you in Warsaw in Poland.
Goodbye. Thanks.
(Applause)
