db-wg

Note: Please be advised that this an edited version of the real-time captioning that was used during the RIPE 56 Meeting. In some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but it should not be treated as an authoritative record.

RIPE 56 Database Working Group 4:00pm, Thursday, 8 May 2008

CHAIR: Folks, welcome to the working group session of the database working group. May I ask the people on the right-hand side to close the doors, please. My name is Wilfred, I am usually trying to keep this working group on track. On the screen over there, you can see the draft agenda for today in the afternoon. The version 2 of the draft agenda has been distributed one-and-a-half days or two days ago, the most recent update on the working group mailing list, because we have received another offer of a presentation by our colleagues from NCC. So we are going to have the regular stuff in the beginning with the administrative issues, then as usual, the update on things going up going on around the database stuff by [unclear], then I have put onto the agenda an item which allows us to follow up on activities that may have an impact on database stuff from the outside. I am not sure whether we really have to spend too much time on any of those three things. Then, we are going to have the high availability software presentation by the colleagues from NCC, and then as unusual, the input from other working groups, questions and any other business. Is there anything you want to add or delete from the draft agenda or any other modifications? No. So, I guess this is now the agenda for this meeting.

Then, as usual, Nigel Titley has volunteered to act as the scribe to take notes, thank you very much for this one. And the third minor item here is remote participation, I actually have to admit I didn't updated on whether we have this Java thing OK. So if there is anything coming in, please just wave your hand or whatever, and try to grab our attention. And as usual, we welcome everyone trying to do remote participation.

Next item here, sub item is approval of the minutes. The draft minutes from RIPE 55 have been available for quite a long time, both on the mailing list as well as on the website. Any comments regarding the record of the previous meeting? No. OK. So, these are the final minutes for last meeting. And the last minor item here well not minor but sub item here, is actually to take Nigel Titley to take us through the review of the list. I don't know, do you have any (action list).

NIGEL TITLEY: Hopefully this won't take very long because we actually cleared off a lot of action points last time. OK. There is a couple of very old actions. 54.3, I actually looked at this one and wasn't entirely sure what it was about. Are you going to be covering this one?

AUDIENCE: Yes.

NIGEL TITLEY: Probably not all of them. Revision of white pages facility. Next one was addressed to the data protection task force. I don't know is there anybody here representing the data protection task force.

WilfrIed: I don't think I am in a position to represent the data protection task force but the OK, do you want to do that? Well, actually, this country attribute was not in the centre of our attention in this framework, but it is certainly something which is going to receive more attention, I guess, in the future. For the moment, we have been focusing not on the individual attribute or not on the individual item, but rather, on the overall framework. We are going going to have rep. up and run down a list of activities on Friday morning, tomorrow morning, in the plenary, like what is coming out in from this Database Task Force, Protection Task Force thing and my guess would be as soon as we are along our way with those major things, then we can go back and try to look at these rather minor activities.

WILFRIED WOEBER: I was going to say that this action point in one form or another has been sitting with this working group for about 3 or 4 years. So, I would suggest that if we don't kill it soon, we ought to do something about it. Wilfred: My proposal would actually be to label it overtaken by event and just close it. And then revisit it again in a different framework

NIGEL TITLEY: OK. Good. That would be nice. Again, you are summarising, right, OK. And I have noticed in the agenda that you are dealing with that one. And presumably you are dealing with that one. Peter, is Peter Koch here? Have you come up with anything on this action point? It was on the minutes. You gave a presentation on it, I think, at the last database working group. Possibly you were suffering from a hangover at the time.

PETER KOCH: Thank you, Nigel. No, actually not. I completely missed the bus on this, so just feel as I wouldn't be here shall sorry.

NIGEL TITLEY: That is all right. We will leave it

PETER KOCH: I don't recognise it, I know we talked about the changed line but

NIGEL TITLEY: The point was that the semantics of the change line was sufficiently fuzzy as to make it not terribly useful and you were going to come up with a

CHAIR: Maybe even we tacked the wrong name on because I remember Richard Cox had quite focused opinion on

NIGEL TITLEY: Peter had the presentation.

PETER KOCH: I had the presentation and I don't remember having received the action item but that may have been the very problem. I am sorry about that, I missed it in the minutes.

CHAIR: We are going to take it off line with a proposal either to keep it or to

NIGEL TITLEY: Fine. No problems. No problems. And again, I assume you will be dealing with this. OK. So we have actually finished on the action items, which is wonderful.

CHAIR: Nigel, thank you very much. And the next presentation is by Jos, the usual database update, what is going on around the operations of the database, what is going on with development software stuff and a little bit of statistics.

JOS BOUMANS: And a lot of pretty pictures. Good afternoon. Let's take you through the presentation. Some of you probably know this already, it's a database group, we will tell you a lit about us and our projects and our commitments we have been working on, what is going on operationally both on the whois side and our other services as well support side. At RIPE 55 we raised the point about evaluation of our services some are proving more useful than others and we will take you true had a that that and at the end room for questions and some talking points.

First is first, this is us, these are the six happy people that make the RIPE database and all 9 other things available for you and you may that I the database working group for us /S* is a very important stakeholder, it's not the only one. As of late doing a lot of work with the data Protection Task Force and to basically come up with the terms and conditions of the RIPE database. A lot of legal entities have asked for our support in resolving disputes and so on and also we do a lot of internal support but last and not least, we have the DNS working group who relies on us for provisioning DNS systems. A lot of work from us. Just because you don't see us very actively on the DB mailing list does not mean we are sitting quiet at all. Some projects we have been doing over the last 6 months, the most mostly highly visible is the nonvisible NRTM stream. Various requests from various ISPs to get realtime updates of our database. There used to exist already as full NRTMs, full mirrors of our database including all the personal data that goes with it. Obviously for data protection reasons and privacy reasons, we don't just want to hand this out as is so we have adopted this NRTM stream to remove all the personal information, which is displayed in the little orange box in the middle as an update would come in with a lot of personal information but when you request the NRTM stream we remove this and thus you get just the operational data, which allows to you make decisions on how you want to build your routing policies, for example.

This is available for all end users, anybody who is interested in this stream can obtain it and the link is at the bottom where you can request it. There is a small yearly fee for it, but again, it's open for everybody to use.

There will be a DPTF presentation at the closing plenary, as Wilfred highlighted and the most important thing that relates to the penal people here is the database terms and conditions which have been finalised. The main points of interest of that are that obviously everyone has to adhere to the terms and conditions which previously was not the case, and that we have now restricted it so only maintainers have the right to update the database in effect saying data must be maintained.

The previous definition of the purpose of the RIPE database was for agreed Internet purposes. Agreed Internet operations thank you, and that it was why it was vague enough, did not allow us to store personal data for people, clearly defined in the closing plenary that will be discussed. And last but not least, there was not a continuing main date from the RIPE community for to us remove data from the RIPE database. The statement was it's not our data, it's your data. Again unfortunately under data protection regulation we cannot say that and have changed it that we can change data when we are so required by law. Again, if you are interested in this please do attend the closing plenary, there will be much more detail there.

On to the action points, I will trust that Nigel has a little tick list to make sure I address all of them. Thank you, Nigel. Mandatory MND by, the request made illustrated on the picture on the right-hand side is that every object should ideally be maintained in the RIPE database. Many of them have this already, some of them have it as an optional attribute, personal objects being one of them, this is one of the most contentious issue a lot of personal data in the database /KHROEB is claiming ownership for. We completed the code as requested, we unfortunately found two issues that are proving to be significant; one is the chicken and egg situation. As you see on the right-hand picture the green little arrow shows a link we have always had. The left side arrow, the red one, is one that we are now forcing on people, which means you end up with a Catch 22; the maintainer must reference the person and the person the remainder, which one comes first? This goes exactly against the design and the logic of the database code when we try to implement this we found quite a few issues in that, which means before we can deploy anything we must do much more rigorous testing. Obviously we are still committed to the change and ever so sorry we didn't complete it just yet [unclear] make sure we can do this and other such changes we are vastly working on improving our test framework, we have a few projects underway to make these these more extreme logic cases well tested and in the end come with a stable code release that does allow you to stipulate mandatory maintainership.

REV SRV deprecation. The request was to clean INET 6 num objects. Unfortunately that does rare database schema change, it's into the very big deal but it does require quite a bit of down time of the updates and we looked at the problem scope, about 4 percent of inetnums scopes that have this, release it at the same time as we will doing the mandatory MNT-by, there is not much operational issues that occur from this.

White pages, which I think is the prettiest picture in the whole presentation. We can deploy them shortly after RIPE 56. We will introduce new org type, they all have one of a few defined organisational types. We will add one called the white pages, we will add an organisation called the RIPE community. The working group chairs have unanimously volunteered to be the maintainers of this, more or less, and this also gives them the right to add even more maintainers to this organisation object or MNT refs, can make the references between an organisation and a personal object. And this allows anybody who wants to be associated with the RIPE community organisation to be associated with it. And it also means that you, the community, can decide who is suited for this. The important part of why these white pages request came up is we do have a request to clean up unreferenced personal objects. Obviously this would make you referenced and there are not being cleaned up.

And while we are on the topic, we have 178 million personal objects in the database right now. Most of them are referenced luckily, very clear ownership and about 400,000 remain unreferenced. We did a big clean up in January, mailed to the mailing list as well, where we talked to some of the bigger offenders that created this and asked them what was going on. They changed their procedure to make sure they didn't have any more unreferenced personal objects and we cleaned up the ones already created. So we have 400,000 remaining that we should clean up.

We made a proposal on how to clean that up. It was amended by the community, in a slightly different way and it called for the database keeping track of when a references changes. Essentially when you send in a first object, it is not [unclear]. When you second in a second that points to the first one it is reference and thereby should be exempt from clean up and asked to keep track of this. Reference may exist not, exist, exist, not exist. We tried to implement that code and unfortunately we ran into the same issues as we did with mandatory MNT by, not designed to have these type of triggers where an object over here changes which may have impact on object over here. We would take to come to you with alternative proposal to get same result in a slightly different way. Start can deploying the white pages, thus everyone who is currently on reference and willing to be part of the right community and in the database to become referenced. And we would like to monitor these objects from outside the database. And if it is unreferenced for quite some time we are proposing three weeks, but this number is just a proposal, if you prefer more or less we can do that, we will remove them. The difference here is that we would look at it periodically rather than when an action happens. So the risk that you would have are flapping objects. Imagine you have a referenced object, the reference goes away, we look, it is unreferenced. Reference comes back, reference goes away, we look, you are now twice unreferenced. From analysing our update logs this almost never happens. This also means that the worst case scenario is that a person object that you have entered you have to reenter. So we believe the risk to be absolutely minimal to implement this proposal and also means we can do this outside of the database logic meaning we don't have any of the issues that we described before. At the end of the presentation there are a few talking points I suggest this is one of them and we would like to get your approval to go ahead on this.

You have heard me talk about it doesn't go with the logic of the [unclear]. And that is what we have to think about, the logic of the database. We are finding now that small proposals like clean up unreferenced objects or make a maintainer [unclear] mandatory is having very big impacts on the infrastructure. This released eight years ago and designed about 11 years ago. We are talking to a slightly older beast and we see that many of the things that were originally part of the database design, the features, the things it meant to address, are no longer issues. We see many things in there that are vastly beyond the original scope. What we would like to do is pause and reflect. To see who the current stakeholders are, if they are still the stakeholders from back then. We know we have a few know ones, legal agencies being one of them and some requirements that we have to produce certain data. We also see that the use of our community has completely changed, again highlighted by the proposals that come from here every so often. We would also like to reflect on the information contained in the database. Information we may into the need. Poem objects comes to mind. Happy to be overruled on that one. We also have certain information not in the database that we believe should be there or at least that is being requested to be there and to reflect on the data requirements on the validity of the data, the accuracy of the data and so on. So we would like your permission to pause and reflect on this and come back to you at the next meeting with some data that we found on this, some statistics on the use cases that we had and analysis and suggestions on how to proceed. Again it's a talking point for later on.

On to another feature, action point 55.1. This is not one technically for the database group but it came from here so I will address it. It is to add the MNT IRT to LIR Portal. This requires mutual referencing, just like organisation objects work, and this is not implemented in the current LIR Portal. There is no such thing as mutual reference because the entire is designed to be one way so you need the authorisation of the person that you want to reference as your IRT contact. They have attempt today look if there is an easy way to implement this and currently it is not. There is a rewrite scheduled for this type of behaviour for early this year or beginning of next and they have added it to the feature list. We hope that is an acceptable schedule for you. If not, please speak up, and they have asked me to to let you know you can mail them, if you want to have any discussions or questions about this particular feature.

On to something much more easy for us, last meeting we asked to you deprecate CVS access to our source code. We found that on any given month /PB we had anywhere between five and ten checkouts of about five unique IPs of this source code. The CVS was a little bit of overhead and we have heard from several sources saying if we find it hard to get to your source code it's supposed to be easy available and we don't find so. We have changed to produce nightly snapshots, for us of us into SVN, a snapshot of a trunk and we have been tracking how it's been done. We deployed this last January, and as you see we now get about 500 downloads of these per month which is vastly more accessible than the five we had previously.

I guess that we have been rather busy, luckily. But it wasn't always with the database working group. Top of our priority was the DPTF work and just in general, the legal agency assistance. And I think I mentioned that the closing plenary will have a lot of details on what the database group has been involved in when it comes to the DPTF. We have been working very hard to make the services more available and more resilient. I will be talking about that in quite a bit more length. The good part of that work if we do our job well you will never know with ask it. The same goes with test improvements, make some stable come owed, make sure the code remained stable as I showed before the DNS working group is also quite a good input for work for our database group and there is two projects they have released and I think I announced in the DNS working group presentation earlier this week which is the sign ENUM zone and ELAN.

Onto the pictures I promised, most of you who asked for support on use of the RIPE database will mail to mailing list called RIPE DBM, customer services, four friendly people and their manager who will be helping you with your questions, and this is the type of things that they are dealing with. And the trends we have explained before, but it's very nice to see a few of them either becoming bigger or smaller. The one we are happy with the amount of updates or I should say questions regarding updates has dropped quite a bit. Just before the last meeting, we have released a database update reference manual and we are assuming that we did quite a work there since the questions of how to do an update dropped. What went up notification issues and abuse reports and this is direct result of targeted spam. There is a lot of systems that will mail any type of mail but not a valid update to auto DBM with a from address bag company ticketing machine, that is where the notification issues come from, or a person, that is where abuse reports comes from and auto DBM will always reply to you and say "I couldn't process your update," and people come to us and say what is RIPE database, and why are you mailing me? Miscellaneous also went up, because we don't have any current separate reporting questions, that makes up the bulk of the difference we had before. We will be better reporting in the next few presentations.

IRT objects have been an interest to this community since I have started at the NCC, one of the first changes we did was make the returning of IRT object as default. And here is an update of how they are being used. We get slightly more every time we come, and IRT objects are there to provide you with an abuse contact so the IRTs we particularly care about are the once have mailbox attribute. What is is a little bit odd, even though the absolute number went up, the IP coverage went down and that is because we actually have more address that is we are giving out than IP addresses being maintained by an IRT, even though the absolute number went up the relative number went down. We implemented dash C as a default returning me an IRT object if possible. Just before the last meeting. At that point we had about 60 queries per month with dash C included in them and there was some concern about backwards compatibility. We see on average 20 queries with capital C don't give [unclear] an IRT object. This was to make sure existing tool sets kept on working. All in all I would say a very smooth change.

Then about Whois queries. We are averaging currently 94 queries per second the peaks are at 162 and it was quite a load on our system, especially if you compare it to when I start working at the NCC early last year our average was 33 so we have actually gone up 200 percent in queries in a little bit over a year. This is why it has kept us busy, we had to upgrade our infrastructure to deal with the increased demand. The demand did not come from IPv6. If you are interested in these pretty pictures go to one of our services and you can see who is querying for what and how often and why no, not why but how often and by whom.

This is how our queries are currently being distributed. Most people as you can see use what we call whois and 18 percent of our traffic comes through proxies people who have a whois box and they also go to port 43 on our side. About 2 percent of our traffic comes from the web page, it's the little box on the front of ripe.net to do a whois query. 2 percent may not look very much but it's still 5 million queries per month. On the right-hand side you will see how the distribution go. We have assumed 500 is a reasonable amount of data to pull some statistics on, so you see actually that the country doing most queries is still the US, it includes some big international copies that have interest in Whois data, our own community only comes second and therefore and thereon.

The amount of queries that people do sees about 87 percent of them do less than 10 per month, and basically 99 percent does less than 1,000 in a month. We only have very few heavy users but we do have several of them go above one million per month and our biggest culprit being 2.2 million in one month. If you do at and lot of these pie charts after a while you start seeing things that aren't really there, but that aside.

Successful whois updates. We have an average of two per minute since as far as our logs go back. But the spikes are more interesting. Right now peaks of around 60 per minute after couple of weeks. It's really a trend that goes like this, continuously. These spikes used to be about 20 per minute, and as the gentleman from NTT I am sure will tell you is the extreme spikes around 240 a minute. Again, if you think this is pretty [unclear] to DB con stat and you can see about these things. People tend to update the Whois RIPE database through sing updates. It's our TCP IT connection you can make. Used to be a 50/50 split between syncupdates and mail updates, and you see that syncupdate sincerely vastly gaining traction here, only about 5 percent use our web updates feature. Of those, about a quarter of them fails, it is very often authorisation or syntax problems. We were expecting more spam on the box but it's only about ten percent and happy to say most updates at least go successful.

On to the most interesting thing, the evaluation of services, we are running quite a few of them, some more known than the others. And we took a look at who uses them and what information they give and if that is still useful and current. And the first of them is IRIS, who knows of ire RIS, just out of curiosity? Who actively uses it? Careful if you raise your hand here. There was a prototype done in 2004 and the way that IRIS works is every routing registry should also participate because the idea behind is ask it will find out who is the most suited to answer your query. So everybody should participate. Unfortunately, very few did. The company that launched the code base behind this, a nice Java product, is Verisign and they have withdrawn their service currently. We get under one query a day on it or whoever two people as I raised their hands to say they used it one of you is fibbing. Again our suggestion in this case would be to deprecate the service. Again, that is talking point for later on so if you have any strong opinions on this or a heavy IRIS user in disguise speak up. The next service is called RRCC the routing registry consistency check. What it does is look at data in RIS which looks at real world routing and compares to the right database which has the I deal picture or how things should be and if any mismatches and get a report and why this mismatch occurs. It's quite a matured service about 1,400 queries a month on this but it has two drawbacks currently: And they are both IPv6 related. There is no IPv6 connectivity to this service and there is also no IPv6 content, so inet6nums and route sixes are simply not in this system. Luckily they are in RIS so the proposer at the NCC say let's integrate this and [unclear] it as stand alone [unclear] the features remain and you get the added bonus of having IPv6 [unclear] content available.

The next one is the mirroring of routing registries. And this is a bit of a complex one, so with my love of drawing pictures I drew you one that describes it. If you look at the top left grey button it says RRDB, some routing registries mirror oh, it's convenient to query. Unfortunately, none of the routing registry export all their data. The downside with not doing this you don't know what isn't being exported, you only know what is being exported. So there are that first box we are losing some data, we just don't know what. There is also no protocol for this. It's simply a stream of text. This makes it very hard for nonRPSL database because the RIPE is, at least we understand RPSL but ARIN's database isn't, it's based on merit. So when output changes, the conversion breaks down, again there is no protocol. This happens every time this index is changed. The RIPE NCC does this about twice a year and so do the routing registries. At this point, data gets more stale and stale because we can't parse the new syntax. So the RIPE database doesn't get up date so when you a query us for this we are actually out of sing and more out of sync by every day. To make this data available in the RIPE database it has to fit in, the RIPE database contains RPSL. There is no one on the planet that completely implements the spec, and only the RPSL spec. Unfortunately, that means that to convert from behalf we get to RPSL we have two things that can happen: One is we don't recognise a certain attribute. At which point we have to drop it or it does not fit in an RPSL database. In worst case it's not enough like that we can parse it or mould it at which point we have to drop it. This means you actually don't get certain data because we had to drop it, again making us serve stale data. When conversion breaks down we have to reload from a fresh, this takes time and again stale data. That is all half as bad as you are a casual user who just wants to query for multiple source toss see what is going on or maybe you had a vague idea where [unclear] number is located. It gets trickier when internet exchange are using this and treating as authoritative to build the routing policies which several do. We regular get tickets on RIPE domain with people saying what is going on, my website is not visible in the UK, and what actually went on is that they had some route defined, which we had mirrored, and a UK IPS took from our database and made the routing policy and it all worked and they updated their route, in a way that was not compatible or wasn't exported or and didn't make it to our database. Therefore the UK IPS kept using the old route which was no longer valid and all the traffic went to nowhere. So it causes real operational issues. And the big lesson to learn here is only the bit in the yellow box is something that we can influence. So even if we do everything we can in our side, get the post impossible RPSL to be compliant and accept any attribute that could possibly exist the other two issues remain. And on top of that, when people treat it as an authoritative source, they often forget we only mirror seven out of 40 routing registries, so we do not have all the answers. We just have some of the questions.

Looking at the usage pattern of when people used a dash A for query all your sources and dash S for a specific source, we look at if their queries make any sense. And we find actually that two-thirds of queries don't make any sense because they used a dash S attribute wrong. Either use a source that doesn't exist, at which point an error comes back, or they only query for source RIPE which is the default. You were querying the RIPE database after all. About a quarter uses dash A wrong because they ask for things that can only ever exist in the RIPE database, like personal data. So it leaves about 12 percent of the queries that actually do sensible queries and get output from us. If you look at the right-hand side, you see what they are querying for. And that is mostly IP information and AS numbers, a few routes and a couple of domains. Again, domains doesn't make much sense because we only have domains in our database that aren't in addr.arpa in the right database. For APNIC and AfriNIC have some that are in addr.arpa. Because of this five percent of routes being queried, we do think there may be some overlap with the working policy working group, so presenting these slides and asking them if they are practically using this to build routing policies and if they are aware of the issues that exist with NRTM. We would like to ask the same question here: If there is anybody here that has a valid use case for the dash A and dash S flag that use this is and relies on this, and what they think we should do.

I would like to highlight that, these 12 percent of queries are .4 percent of all queries, so when looking at statistical significance of our mirror databases, it's not all that big but it doesn't mean they are not important to someone.

So, we have a few possible solutions when it comes to routing registries. We could keep going as is, obviously. The drawbacks I think are obvious; we know they are incomplete, we know they are error prone, they are even misleading because they give you stale data, they give a limited view we only offer 7 out of 40 and operational issues come from them, it doesn't mean they don't have any value. We would like to hear about that value. We could obviously on only respond to the one source we know we are authoritative for, RIPE. Which means in the end we would deprecate or dash A and S and let them mean nothing only let you query RIPE. The third option is something that has been put under the name of joint Whois. In effect, we would have a referral service. If you ask us for something that we don't understand, we can go and try and query the other routing registry for you. Internet nowadays is good, it's fairly reliable, most whois servers are up most of the time. Because of what we describe before this is not something we would want to implement in the core Whois server code but imagine ourselves having a proxy object website that let's you do this. The big change is relies would be in the form of the remote routing registry not in the RIPE DB format, so if the answer comes from a nonRPSL database get the same answer. This is a talking point for later on, if you have some input please save it. Not all bad news. We have some useful services as well that we would like to improve. On the left we are actually proud, 100 percent up time on our query. We have done reasonably well on mail updates, a total of 36 minutes of outage over nine months. We have done a little bit less good on syncupdates, that has been out for a little bit over five hours and this is one we think we can improve. We take it serious.

The reason for syncupdates being out of band with the other ones is if you look at the top, updates currently go to one single server. And behind is one single database, meaning if that one SIG server is not available or database you cannot do any updates. The reason we have 100 percent up time for queries is it's not one SIG server. So, we like to go to the meddle described in the bottom of the pictures where both going to multiple servers and multiple databases at the end. And for your amusement, I have a little picture that will illustrate what will happen if one of those go away. Currently we have one, we are now going to four. Machine will fail, it will be noticed by the monitoring programme, a spare master will take over and replication will continue with the spare master. Now, the takeover is not quite as quickly as that movie goes but we expect an outage of about one to two minutes tops when that happens. Meaning we can raise the bar for uptimes quite a bit.

I think that concludes most of what I have to say when it comes up to updates and so on. But we do have a few talking points and Wilfred if you would like to guide us through them I would very much appreciate that.

CHAIR: Yes, I think that is appropriate, thank you. First of all for this very elaborate and very well structured presentation.

JOS BOUMANS: You are welcome.

CHAIR: So you have already come up with sort of a list of items to talk about, I have already take answer couple of notes so let's work from the slide here first of all. So clean up of the unreferenced objects. Is there any comment, is there any input you want to provide us with regarding the proposed way forward?

JOS BOUMANS: Here is the full proposal again.

CHAIR: Or we just suppose to do it as

JOS BOUMANS: Sorry?

CHAIR: What exactly the feedback

JOS BOUMANS: If you have any concerns about our alternative proposal, we would love to hear them. Otherwise we would like you to say, go ahead, do that instead.

CHAIR: That would be my first reaction because it seemed obvious and reasonable and sensible and complete, or whatever the proper English term for that is.

JOS BOUMANS: Shall we assume a silent majority is agreeing majority

CHAIR: We could also ask for a show of hands. Who is this favour of this proposed solution to the problem. Anyone having major issues with this? No. Unanimous.

JOS BOUMANS: Excellent. Thank you very much.

CHAIR: The next thing I have written down on my list is the country stuff and the time stamps and the change lines and my proposal actually would be to sort of defer those things until we are past our thinking break, and then sort of come back to the other things. Then there is the IRIS stuff. I think the reaction and the feedback to you would be obvious but of course we have to ask the group here, does anyone see any problem in retiring this and simply turning it off? Leo?

LEO VEGODA: From ICANN. I don't have a problem deprecating it if people really want to but I was just wondering if, instead of deprecating it, you were to say freeze feature upgrades to the Whois service and put any new features into IRIS, it might become more attractive and people would use it. As I understand it, there is only one server implementation and one client implementation but if IRIS is as good as it's meant to be you could write your own server, distribute a new client, put features into it, make it attractive and people would use it.

JOS BOUMANS: That is very accurate observation and it would be wonderful world if we could. The sad reality is IRIS is meant to work with many people implementing it and it's the same with IPv6, it only becomes interesting when everybody is doing it and unfortunately nobody is doing T the code base is stale, it hasn't been updated in years. The prototype and this is what we are running, prototype code, hasn't been updated since 2004. We hotfix it every now and then when a remote URL is changed, and we are doing all this maintenance work, mind you it is feature frozen completely for one query a day, and a little see receipt that I didn't say in this presentation is that half of these one queries a day are what looks like to be ping checks from the author of the code.

CHAIR: One of my comments would be, Leo, I do see your point but I think the point is made in the wrong group because we do have it and there seems to be all the others not having anything, so the if we want to have it we would rather have to preach to the others.

LEO VEGODA: I was more thinking along the lines there is only the one implementation, so it's not going to move forward to standard until there is another implementation, if there is any support for at all this seems to be the obvious place to put the support, otherwise, yeah, turn it off, but I mean, it does seem a bit it seems that if all the effort went into, you know, developing the protocol it, seems a bit sad to abandon it, if it is as good as it's comment to be and it seems that all this effort went into developing it and then it's just sat there to rot and maybe if it is all that good, it would be worth putting the earth into developing a separate implementation of serve and client. Or maybe it's a rubbish protocol and we should just turn it off. I don't offer an opinion on that (effort) I am just thinking that if it's any good at all, then you know, someone has to develop the other implementation.

CHAIR: Yes true, but if I remember correctly this was mostly targeting the domain business players, is that correct? And it was just sort of also used or extended or modified to fit the resource registry thingy. Is this true or am I on the wrong horse?

AUDIENCE: That is very true because most of the requirements that came from the domain business I think. Another thing to respond, another little secret: There is not much of the implementation that we have, we have a proxy, IRIS server is not the server itself, it process queries from the RIPE database, it just presents RIPE database in crisp format. So when we say deprecate, we are not deprecating a huge code base, so I think even IRIS or CRISP is ever to take off, I think we need a major development, anyway.

CHAIR: Does anyone happen to know any deployment in the domain area?

PETER KOCH: I would have actually [unclear] he esteemed colleague Marcos was in the room coauthors of relevant documents. DENIC is currently or in the phase of deployment of an IRIS domain availability check implementation and that will, as far as I understand, include a client implementation that is intended to be made available for free open source, whatever the legal team comes up with. I am not sure how much that will help in this arena because, as far as I understand, and that is not much in this protocol space, AREC and the domain scheme remembers kind of different, the basic underlying scheme, the XML and Irish stuff is similar. Could imagine that someone interested in this would have some code to work from. Of course, I can't promise that there will be many more queries than one query a day, so I just throwing this in as a data point. There is a slow uptake in this. Any domain or registry domain registry community, but something is happening there and I can't actually give you a due date at the moment for release of this service but it is, well, I am audio taped here. So it should be it should be available sometime this year, that is the last I heard, but don't take my word for it. The issue at hand is that switching this off would probably only disappoint a few people that are actually querying here. I am more concerned about the message that is sent by this, right, because this whole Irish thing was intended as a Whois replacement and we know that the basic intent was to have kind of authentication in there to serve the various needs of these clients, well let me say stakeholders at the danger of sounding ICANN-ish who would have different or different views, like law enforcement and stuff. So if the message is all RIPE is deprecating IRIS, that might be might raise flags or concerns that we want to be aware of, but I trust that Josh will be able to come up with very diplomatic wording and language to address these concerns.

JOS BOUMANS: Can I give that a go now? The key words on the slides are it's a prototype, the prototype type came from Verisign, do not have that service up and running as it is. That code has not been touched since 2004. We have merely had [unclear] run to go proxy to our database. None of it is ours, and it has never gone beyond the prototype stage F at�a.m. point IRIS takes off and we need to hop on the bandwagon, this is not a we will never do IRIS. We are saying this prototype is used by no one, almost no one, and do you really want to us spend time and effort making sure it is available as all our our services or do you prefer us to work on the things that have a much higher user requirement.

AUDIENCE: Also deprecate the system, from the beginning this was a solution in search of a problem. It was designed to solve a problem that someone else had, that then for political reasons was the rest of us and if clearly no one has moved to it and it was demonstrated already that things like serve this had service perfectly well, clients would give you the same data with much less effort in form it's a you were familiar with and you didn't need to redesign your tools to cope with that. This clearly shows basically that it's ready to be put to sleep.

CHAIR: So then trying to wrap it up here, I guess sort of the bottom line is that there is no resistance that you turn that off, but package that fact with the proper explanation and maybe attach to it sort of the decommand, that as soon as this is going to become more important in the future, that we will again look into this and go ahead and do the right thing.

JOS BOUMANS: Absolutely. I can't stress enough this is not IRIS the protocol, this is this prototype implementation of IRIS.

CHAIR: So. Can you take us back to your talking list, please.

JOS BOUMANS: Integrate RCC with RIS. I don't think we need to jump back.

CHAIR: Yes. So anyone having a problem with RRCC going away in the packaging, it is available right now and becoming available again probably before going away in the old way.

JOS BOUMANS: Absolutely, this service will always be there.

CHAIR: Coming back into framework of RIS.

JOS BOUMANS: With free IPv6 content and connectivity added to it.

CHAIR: I think it's a very good idea so anyone having problems with that? No. OK. Mirroring the routing registry stuff.

JOS BOUMANS: I will jump back to the pretty pictures.

CHAIR: I think this is more or less the stuff that should be discussed tomorrow in the routing environment.

JOS BOUMANS: Absolutely but if there is anybody here who has some valuable input we would love to hear if, especially if they can't neighbouring tomorrow morning.

AUDIENCE: When you described this part what I missed was a bit more concrete data instead of so much certain objects, certain data, certain mirrors. When I have used different sources, I have used it, for instance, quite often in the case of the when looking for objects in the ARIN database, because I got fed up of not being able to decide style searches on their database, whereas if you went to this I could

JOS BOUMANS: Sorry from the IANA database?

AUDIENCE: ARIN.

JOS BOUMANS: ARIN [unclear] ARIN, yes.

AUDIENCE: Also because the other big and more or less useful routing registry is [unclear] and unless I have lost track of it follows RPSL quite close and so I am guessing all of its data is there and if not I would like to know which data is being lost because I actually do use it.

JOS BOUMANS: Andre, you want to go first or shall I? OK. The question you ask is one we would like to have an answer to, as well. You are asking me what don't you have, what didn't you see. I don't know. What we do see is when an object comes by from, for example, RADB that, points to something that should have been there but wasn't, this raises an error. When something is being removed that was never there to begin with, and at that point we realise that something wasn't exported by RADB. This happens regularly.

AUDIENCE: This has happened I think since day zero of when the routing registries came out and we decide today work together in mirroring and the solution has always been go talk to them and figure out what is going on. Is this on purpose, is this some accident that happen, what is up? Why have we not followed through with the incorporating with merit.

JOS BOUMANS: We do cooperate with them and talk with them usually the fixs are not trivial, if they were they would be fixed. We are talking about quite a bit of staleness we incur until we find out what the problem is

AUDIENCE: Can you quantify this?

JOS BOUMANS: In terms of year we have a mirror going out of sync, is that the number you are looking for?

AUDIENCE: Well I would like to know which mirrors are affected about this, if you haven't find the reasons, enumerate them. If the incidents are frequent, then yes I would like to know the frequency.

JOS BOUMANS: You are asking me to make some very unpolitical statements here. All of them.

AUDIENCE: I am not prepared to decide on yes or no for something without having data to be able to base that decision on something.

JOS BOUMANS: No problem. All of them go out of sync. They go out of sync once or twice a month. Sometimes the fix is trivial and we can repair it from getting a fresh dump from them. Some of the registries have these dumps available to fetch when we need them. Some don't. At least two registries of size and I will not name any names in this in this case, have dump that is are knots referencing complete, they will not load. They are trying to figure out why stale but it's not a high priority because their Whois system works. Best effort basis. Because there no protocol no way of being sure what you missed. This is inherent flaw of NRTM, the idea. So that is one that I can't give you. What I can give you is that as soon as we turn on the mirroring stream again we will become more stale and out of date that every second that passes, because we know we don't get all of them. And this is enough to give us on a few weekly bases at least, one person or usually one ISP or internet exchange coming to us with questions saying, what is wrong? Why is my stuff not showing up in random country? So we know that at least when they notice it, it's become a real problem. That is all the numbers I have for you right now.

CHAIR: Andre.

AUDIENCE: I rather have a question, actually. Just to check that there is no confusion; though the slides said mirroring routing registry are we talking about only routing registries or other sources? Because out of seven source that is we mirror, four of them are actually other area databases, and I think with them, we have most of the problems.

JOS BOUMANS: That is correct.

AUDIENCE: So is it does it cover well, especially when you show during Whois in the next slide, I think during that will not solve the problems of the routing registries because there are no way to actually see in which routing registry a particular route or particular routing registry object is published. Well, John who serves well for area registries. So I think if we are talking about just mirroring and I think that is the scope of this proposal, we should make it more clear, more explicit.

JOS BOUMANS: In that case we need mirror all the other RIRs except LACNIC who did do not allow, we mirror JPIR and ARIN RR as well and from our joint from our RIR colleagues, we mirror the routing data.

AUDIENCE: From LACNIC. We do have a joint whois in our database, basically like a front end to our Whois query every time you query 43 we do the if 44 just normal Whois. One of the things you have got to be careful, whoever you are proxying for them you have got to contact them because many of those database they have control on the amount of queries they have so as we have with you people, you have got to contact them be sure, they know they are going to receive a lot of queries from that particular pool of addresses.

JOS BOUMANS: Thanks for the hint, indeed we are aware of this and again since mostly mirroring other RIRs we will understand what the scope of the problem is and there is general consensus we can't do much better than doing currently.

AUDIENCE: Andre's point of distinguishing between registry data and routing registry data, well OK I wanted to make that as well; I am a little bit confused about your answers well, OK, you were telling the real problems show up when obviously someone has been used the routing registry data that is mirrored that failed, I don't I don't remember running into any problem of a kind being reported to me, and I am heavy user, though well, OK, yes, when using the RIPE database I usually restrict very much to what mirrors I am using and mostly none.

JOS BOUMANS: That would neatly you out of the problem

AUDIENCE: Though for me it is a very valuable service that there is a collection of the more trustworthy nicely looking registries being mirrored on RIPE.

JOS BOUMANS: Why specifically mirroring if I may ask? What is the end problem you are trying to solve?

AUDIENCE: Well, once in a while, one of our customers doesn't have all the routes registered in the same RIPE database, and once in a while so I have to actually allow a search path that includes a couple of registries, and, yes, well OK, if you if you do if you do some internal referral and return RPSL, please, I could deal with it, I wouldn't dish probably would not note, but obviously I would need RPSL.

JOS BOUMANS: OK.

AUDIENCE: And I would and I probably and I probably would view it as a pretty hard problem to deal with any syntax errors that are tunneled through from a referral, because I would first hit you about, well, OK, your objects are messed up, so well, OK, for the routing well, OK, I am not really I am not really sure from what I am hearing from you whether the stale data problem is really so much a problem on the routing registry side; I was hearing you, you were saying it's essentially registry data, where we all know there is also the bad problem that, well, OK, the formats are not really that well aligned.

JOS BOUMANS: Yes. Let me address the two questions I heard. One is I want to you make something that is not RPSL into RPSL. Yes, we would love to, but unfortunately, that is not reality. Yes can you make an orange into an apple, we try our best, part of the problem it simply doesn't fly. We can do our best but you will never get any better data than the originating source can give us, so in that case you say well it's the best effort thing. Also accept we will make mistakes and therefore give you wrong or incomplete data. This is something that concerns us, [unclear] we have been, people have come back to us and saying you broke stuff, because we thought we could trust you, thought you were authoritative and complete and we are really, really not. Other than that, is it about routing data or not. This is the division of what people query for the the yellow bit of the 7 percent domains you can discard you see the majority of please give me an AS number, a route or an IP address, so yeah all operational data, not maintainers, personal objects, who is responsible. Does that answer your question?

AUDIENCE: OK. Yes.

CHAIR: I think we should stop with this particular topic right now, right here, and revisit it tomorrow in the routing working group. And sort of this was the first time you showed that to us as a problem. I think all of us are going to need a little bit of time to think about the impact and what the proper reaction is. So, we should probably also take this one to the mailing list and not just to the online working group tomorrow morning.

JOS BOUMANS: Absolutely. These are the three options that we see that we can provide, if you see anything else, obviously we are just as interested in that. We don't have all the wisdom.

CHAIR: We are going to collect feedback tomorrow and I will suggest that we should also activity try to collect feedback on the mailing list or both, depending on the outcome tomorrow do we have anything else on your version.

JOS BOUMANS: Future of the RIPE Database. Give us a bit of breathing room. We can work hard on implementing new features in a system that is having a hard time accepting new features or look at what the next best thing is and provide you with input to make a good balanced decision on that. We don't both at the same time.

CHAIR: The last is the reliability stuff. Could you please put up this chart slide one again because I am not happy with that one. Because I think it is grossly misleading because if you looked at the slide, you get the impression that the sync update reliability is about one-third compared to 100th and that is definitely not the case. If you look at the figures on the right-hand side and if you do the maths in your head and if you try to generate a new pen tour, a new chart in your head /ARBGS virtual picture, would you not be able to see any difference in these 3 bars because all that have is beyond 99.9 something.

JOS BOUMANS: That's correct.

CHAIR: That is the reason why I said it was misleading. So I think you deserve really big upper case capital letters, thank you, for providing that type of service to the community.

(Applause)

CHAIR: Thank you for the update. If anyone of you has any more input after thinking about those issues, please come back to us either in person in the afternoon or tomorrow as long as we are here together in Berlin or even better please come back to us on the database working group's mailing list, which takes me to the next item on the agenda and that is the follow up for all of us on these three aspects which I have collected. I don't know whether there is anything left for us here today in the afternoon to talk about or to think about. The Data Protection Task Force issues have been touched upon already, there is going to be summary report tomorrow after the Routing Working Group meeting at the closing plenary, so I would really invite all of you to be present and if you are not yet on a plane or on a train or on your way home, it's going to be interesting. Then, a while ago, on the Anti-Spam and I think also on the Database Working Group mailing list, we had discussions on the issue of contact data quality and we had some sort of requirements discussion. I just put it there, just in order to put the question mark in front of us: Is there anything we have to do or we should do? Unfortunately, I had to miss the meeting of the Anti-Spam Working Group or whatever it is being called in the future so I don't know whether there was any there was any discussion on that issue? No. OK. So I think it's not it's not a hot topic for the moment and we don't have to spend time on that. On the stuff of the Resource Certification Task Force we already had at least one, I think Nigel you gave two, summary presentations on that issue. I have just put it here on this list again because I want to make sure that we don't miss anything which comes from that activity and has an impact on database operations, database software, whatever. Is there anything we should be aware of with regard to resource certification? I see two gentlemen queuing. Go on, please.

AUDIENCE: Thank you. At RIPE 55 I threw you a curve ball on something really rather different kind of topic but nonetheless relevant to database. I posed the rhetorical question: What are you doing to protect against the corruption of the database by people claiming lawful authority to do so. So the right by law to come in and require you to delete a record or something. Now, from the description of what is being on in in the Resource Certification Task Force, this seems to come into further focus. Incidently the reaction I got to my question, my rhetorical question, was oh, gosh, that sounds like an interesting thing, maybe we should think about that. We hadn't thought about that yet. I don't know if anything more has gone on on that. I certainly have contribute today it, sorry. But the Resource Certification Task Force thing seems to potentially make it more urgent to think about this because one of the features that was described in the very source certification task force's work is not only would the NCC be able to sign a certificate to, so that you could prove your holdership of some address space, but would also be able to revoke that certificate. And that in a moment we don't really have policies of the if condition then revoke address space, because we don't really have a very ready ability to revoke address space and make those changes in the database. Now, I mean we could make those changes but nobody really would check it for that, so I don't know quite whether this is exactly the best way to raise this but I think in terms of linking together the Resource Certification Task Force work and the database work and considering these kind of issues, that new capability and then well, what safeguards would you want to put in place around that, would you, for example, want to have a full record of all transfers that were publicly inspected, would you want top highlight those requested somebody by other than the holder of the address space? And so forth. There are real policy issues there that need to be brought out and I would suggest should be brought out in a timely fashion.

CHAIR: Thank you for bringing this up, this is a very good refresh of my memory. Just not directly related answer or reaction, we started to think about similar procedures and trying to write down or think to the bottom of what is going to be necessarily required, what would be the steps, in the framework of the data protection, Data Protection Task Force thing. If somebody requests the removal of his personal data and he or she happens to be the last contactable contact for that, and we already have draft very very good draft documents, what the reaction to such a request should be. That is not directly related to the thing you are bringing up but I think we start to do that type of thinking and I guess we should also pretty soon start to think on similar procedures or the potential problems and outcomes regarding the issue you have again refreshed me. OK. Thank you for that one.

AUDIENCE: I just shortly want to mention that one of the activities and outcomes of resource certification work is policy proposal 2008-04 which will result in creating more data for the database using essentially existing structures and will, OK, the thing will be discussed for the content and for most important for the cases tomorrow in the Routing Working Group, but OK, there is some relation to the database.

CHAIR: Do you expect anything to sort of to hit us unexpectedly within the next, say, between now and RIPE 56?

AUDIENCE: Well, OK, actually my hope is that at the next RIPE meeting, we should be able to show how the RPKI assigned data is reflected in RPSL and in VIRR, including the RIPE routing registry.

CHAIR: OK. Thank you. Anything else to these? No. Done. So, I am happy to invite our colleagues from NTT to give the presentation or an update, extended presentation on an issue or topic we already heard last time. The floor is yours.

YASUHIRO SHIRASAKI: Good evening. I am from NTT Communications and today I would like to talk about the outcome of a new syncer for version 3. (Since we used as a base of our IRR which is the core module of our antiprefix hijacking system and we are working on redundancy of IRR with no implemented syncer module and downtime.

So we choose active and stand by and introduce syncer module for stand by whois server. Syncer module periodic checks and re when incremented. And here is some graph which is an update statistics of last year. The peak was 240 updates per minute and average was two updates per minute.

And we have tested our our IRR with syncer module and and NDB cluster and this is dual site topology. We put IRR into 1,500 the RTT between the site was 8 we measured the total time elapsed in addition and of hundreds of objects and the region of the origin of the objects. And we had the IRR achieved approximate read 200 updates per minute on and 300 on the rate operation.

On the dual site 20 add operation per minute and the rate operation per minute were achieved. This is for the 500 kilometres distance and the synchronized updates.

And downtime minimisation is related to rerouting the of Whois server. For example, rebuilding in a boot sequence takes more than five minutes for RIPEDB. It causes service interruption. Even though the system is redundant with syncer module. If database supports MVCC mechanism no such interruption but doesn't support it right now. So we just made a work around. The work around achieved 14 percent shorter locking time but total time of laboratory rebuild was not changed. This was measured with RADB as target and this work around the requires more memories on SQL node.

Now, DB updates issues Whois queries on updates several times. For example, when we add single queries four times, to get data to, get our data in generic to get object in the same function and to get R data in object modification function. So we have tried to optimise queries in DB updates.

This is original queries when we add up light object and similar queries are issued three times. Simply wrap with begincommit statement 1.4 percent. And omitting useless sub table creation, 20 percent. And optimising of ID table creation, additional 4 percent. As a total, add operation accelerated 150 percent and the rate operation accelerated 48 percent from the base code. In a single site configuration. We are now trying to measure in dual site configuration. So, we are now ready to send to RIPE NCC babe team for and we are happy if we could improve the /HRAO*EUP DB. Thank you.

CHAIR: Thank you very much. So,.

AUDIENCE: Private citizen, I am very impressed with what you have done. And I would like to again as a private citizen make clear that I RIPE the RIPE NCC is currently and I suggest you send in your resum�, as the database managers thank you very much and will definitely take this.

CHAIR: So you are going to get an employee instead of code maybe. Any other comments. I am not in particular specialist in database technology but this is something I have seen and heard in many different environments that tweaking database, tweaking stuff is really giving you better performance times if do you it the right way.

YASUHIRO SHIRASAKI: Yes, because as in his presentation, the original implementation is 7, 9 years old and I software was implemented in the years ago, so that now the situation is different, and we can do much more thing since when the original code was created. That is the reason we can accelerate the code.

CHAIR: OK. Any other comment? No. Then thanks again, thanks for take the trouble to give us an update.

CHAIR: The next thing on our agenda here is trying to find out whether there is any open issues and input/output with other working groups. This time around I haven't received any indications either formally or in person during the coffee breaks so I guess there is nothing to do on that one which gets us to any other business. Anyone wants to speak up or no. Done with that one, as well. So I can actually say thank you for being here, thanks to all the people presenting, giving us their insight and giving us their points of view and comments and have a nice evening and maybe see you again, many of you, some of you, most of you at RIPE 56. Thank you very much. Session closed.

(Applause)