The session commenced at 9 a.m.
CHAIR: Good morning. Welcome to the usual Friday morning session of the database Working Group. I am Wilfred Woeber. I am trying to keep this session on track and to make us finish as soon as possible. We do not have too many things on the agenda today, but let's start with the more administrative matters.
To introduce a couple of other people for those of you who have not been around for a long time. Over there is Nigel Titley who is one of the two co‑chairs of this Working Group. And you are going to be introduced to Paul Palse from RIPE NCC giving the update about the database activities today.
So, for the logistics, I'd like to extend my thanks again to Nigel Titley who offered to take notes. The other thing to mention here is that we really invite you to participate and not sort of to just listen in on what Nigel, myself and Paul is going to present been please be active and to join in. If you do that, please walk up to the microphones and state your name, that's the minimum we ask you to do, you are also welcome and invited to give your affiliation, organisation or function. You are speaking for.
We also have remote participation which is taken care of by our colleagues from the RIPE NCC. Thank you.
The next thing to do, business formality is to agree on the agenda for this meeting. I have circulated minor update yesterday for the draft agenda to we have draft agenda version two. Is there anyone who wants to propose any modifications to that, additions, reseek /EPBSing, not talking about some stuff, maybe? No? Okay, agenda we are going to work from today and the next action actually is to formally approve the minutes from the previous meeting in Dubai. Minutes have been circulated on the list. The draft minutes have been available from the Working Group web page. So, is there any amendment you want to make, any comment? No? So, the Dubai meeting minutes have been approved by that. And we ask the RIPE NCC, together with Nigel to actually modify the status of the minutes from draft to final (Nigel)
Next thing to do is to review the action list and I'd like to invite Nigel to walk us through the list of open and completed actions.
SPEAKER: Nigel Titley: Action item review: The birthday background is because some of these actions are coming into their second year now, so it's happy birthday dear actions.
Okay. Although actually we haven't got that many so it's actually quite good. 54.1. RIPE NCC, maintainer attribute on all objects. Will Paul be dealing with that later? Right, okay.
Clean up of orphaned objects. Paul dealing with that.
RIPE NCC removal of Revenue serve attribute. Dealing with that later.
RIPE NCC at MNT,‑IRT to the LIR portal. It's done, that one can be put to bed then.
Then there is an action on the Data Protection Task Force, do we have a representative from that taskforce here? Okay. Do you know whether anything was done on this one? We suspect not. Okay. So this one is ongoing. This is just a consideration.
Then finally, 57.1 from the last meeting, implement ASPLAIN which I think is definitely done and you'll be dealing with that later.
That's it. Nice and quick.
CHAIR: Thank you Nigel.
And also I'd like to invite Paul to give the usual traditional RIPE database activities /PRAEPBGSD /W‑Z' said already, within that presentation, we have going to have also (preparation in in information related to some open actions and to the data protection, data privacy taskforce. So Paul, the floor is yours.
SPEAKER: Paul Palse: Thank you. I am Paul Palse, the database manager since January this year. And I will be giving you the database update today.
I'd like to first of all start with the introduction to the database group and then talk you through the action points that we took away from previous RIPE meetings and some statistics and operational data and we have had a Data Protection Task Force meeting this week and I'd like to give you some highlights that we took away from that meeting and obviously after that, there is time for questions.
The database group, for you who haven't seen previous meetings slides. Here we are and hi guys.
So, who are stakeholders in the database department? We obviously have the RIPE community via the various Working Groups and internally, we have the IT department, business applications, DNS, registration services and customer services and we also have legal and law enforcement stakeholders.
So action points: Maintaining ‑‑ making main tainters on roll and person objects and this was action point 54.3. We find that this hasn't seen enough action to our liking, but that's because it has a slightly bigger effect and anticipated, especially in the area of documentation and some procedure changes that need to be coordinated within RIPE departments. There is also some progress to report. We have done the code changes necessary. And when we have finished the documentation part, then we are actually able to deploy our code changes. And we have also added a new boot strapping page for new users that allows them to easily create a first person maintainer.
And I would suggest as a little note, before we roll this out to check that you have written any scripts that automatically generates objects, that once we role out our changes that your scripts don't stop working.
And we'll try to deploy all that as soon as possible after this meeting.
And this is that start up page. I think at the previous meeting there was still a prototype stamp on that, but we have done the work for it. (Prototype)
There has been some talk, and I didn't want to leave that out, about data quality and this is a RIPE wide initiative and obviously the database team is also part of that effort. And we would lays basically like to know if we can still reach all the maintainers of the objects in our database (basically) and we are planning and and I want to emphsize this is a well coordinated effort, we would like to mail out the maintainers and see if they are still responsible for the objects that we have in our database. And if you receive such e‑mail, you can help us by responding to it.
Action point 54.7: The refer server application, attributes deprecation on I‑Net and I‑Net ^6 numb objects. About two weeks ago we have announced we would roll out the syntax changes or the software that enforces the software syntax changes to give you a bit of time to look at your scripts again, that's still used Revenue server attributes, so please change those scripts and we think if about two weeks time we will roll out those changes /TPR‑PBD that moment onwards we won't be accepting /*EF server attributes on on INET and INET 6num any more.
If you need to make up dates, you can decide to either remove the attribute or change it into a remark line. But either way, whatever it your /‑PB preference. And then before the next RIPE meeting we will be running scripts to deprecate the remaining attributes on these objects.
Cleaning up unreferenced person objects. Action point 54.6: /*F we have started to delete these objects in batches the we started off with very tiny batches to see if we got any feedback, and slowly on increased these batch sizes and we deleted approximately a little bit over 120,000 objects so far. And we are planning to increase the batch size. So that we have removed all these objects before the next RIPE meeting. However, we will be keeping this script running so that any personal roll object that remains in the database and remainsed unreference forward a period up to 21 days will be automatically removed from the database.
If you need your unreferenced person objects to remain in our database, then we recommend you to contact one of the RIPE Working Group chairs. And they can add you to what we call the white pages. And obviously those objects won't be removed.
ASDOT to ASPLAIN migration, we did that on the 25th March and was quite a smooth action there and we found that all together about 184, about exactly 184 objects were affected in some way.
Last RIPE meeting we promised to come back with some feedback on an approach on mirroring. This was what I understand is quite a heated discussion last meeting. So, we promised to do some homework here and I would like to start with others mirroring the RIPE database. As an example, we have looked at RADB, that's mainly, or I think only mirrors our routing data and found that they are nearly, aside from I think one known object, they are completely in sync with what's in the RIPE database. This doesn't include personal data, and because transforming, or moving everyone who using our NRTM to person NRTM streams that don't contain any personal data, for instance, our DP‑TF service won't suffer in anyway from this. Then we obviously also have us mirroring other databases. And we understand that mirroring is important to you, especially if it's in ‑‑ if we represent the data in RPSL format.
We have looked at how can we improve the data that we maintain and we basically have to see what we get in. We also need to match up some discrepancies between the scheme outs of the different objects that we get back and hope to, from that moment ‑‑ when we have assessed that, then we can look at how we can improve the data that we are holding.
Various updates: In previous meetings, we have showed you some plans around improving our system architecture. Well, we have done most of the work. This new architecture is based on cluster, it's hardware, which would give us a zero data loss in case of we are holding data in two physical locations, or there wouldn't be any data loss in case of failure. It would obviously improve resilience and facilitate possible growth. And again, this is something that we are on the point of deploying and this will ‑‑ I am it have dent that I could present something at the next RIPE meeting in this regard.
Various updates: Again, we upgraded our, finally upgrade or GnuPG to a new version that allows you to use a newer /HAFRBing algorithms and some fun facts they've /SPWRO introduced, a slightly better way of working with project management. It's an agile software development practice called SCRUM and we are using two weekly sprints. And obviously ones we have deployed are our new hardware infrastructure. It gives us a better platform to think about future enhancements and improvements.
Some operational data: This is the customer service team that sits on the other end of the e‑mail messages that you send and get back. And they obviously take care of the first line support. They will escalate any tickets to the database department and we function as a second line for them.
Some stats on tickets: The blue line is what's between 56 and 57 RIPE meet ‑‑ meeting 56 and 57 and orange is 57 /58 and we see a nice decline. The notification issues, there was a technical reason for that high level, the high number of tickets so we have addressed that and we can, we would see a further decrease in that area.
RIPE database statistics: Whois queries per minute: Basically, I have taken the stats that we showed previously at the end of January 2008, we were at about 4,000 queries a minute and the blue line you see on top of there is a whole year of queries, April to April, and we see a nice increase. And there is a little orange line there as well, and that's our IPv6, our queries over IPv6, and actually it's not so bad, it's approximately 1 percent over that one year of queries we get in over IPv6. A little bit less than 1 percent.
How do you query us? Mostly ‑‑ sorry, this is ‑‑ yeah, we see that proxy queries are actually less popular these days. I will come back to proxying a little bit later in my presentation as well.
Some stats on Whois queries, where are the queries coming from and a question we often get is how do you generate these stats? We use GOIP for this and these are not domain extensions but just country codes. The slice that is don't have percentages with it range between 3 and 2 percent I think.
Queries per month, and in web terms the stickiness of our queries, there is quite a lot of ad hoc queries, only 1 to 10 queries per unique IP address is most popular. Then it goes up to 100 to 1,000 queries. Only 2 percent of queries come back more regularly.
Updates stats: This is running over a six week period. This is running at approximately two successful queries a minute. And we have seen peaks of 30 minutes, which we can easily handle.
How do we receive our queries? 23 percent over e‑mail and 77 percent of IRR syncupdate. There is various inter phases into that syncupdate so that's all represented by this blue area. 67 percent are successful results ‑‑ have successful results. And this is also what we based our previous statistics on and 24 percent fails for some reason. And we mark 9 percent as spam. 0 percent is a very small amount still, request help via our update methods. You actually receive an e‑mail back with help data.
And then up time: Last meeting we presented nice figures. Five 9s. This meeting, my first meeting, I have to report a slight dip in mail updates. But the good news is that this was a glitch in the monitoring system that we found after doing updates, we fixed that so if we didn't take that into account, that line would be nice and flat.
Okay. The highlights from the Data Protection Task Force. I am just going to tell you what came out of that and maybe during the question time, you can give us some feedback on some of the items.
So, in light of not reusing NIC handles, we came up with an idea to stick to letting you choose that two character prefix and we will just automatically generate the sequence number behind that.
We have also taken action points from this meeting and what we would like that do is to see what the impact would be if we enforced the rule that the maintainer needs to authenticate a request to have their persons object connected with a resource that's managed by a different entity. You could think that you know, if we enforce this rule, that maybe people would start duplicating person objects just to work around this system. So, we need to go back, look at that and see what we can propose.
Proxying. I promised you to come back on that. The taskforce was looking at the terms and conditions and you know, there is still quite a few proxy agreements and we were looking at how can we make sure that the queries or the results that are presented via these proxies also adhere to the terms and conditions and in that light, we felt, well how many people, or how many users of our proxy /SR‑FRS are there around? We have done some ‑‑ we have looked into (servers) we found this week actually that there is 89 proxy agreements currently of which 28 have queried the database this year. Of which actually only 18 actually used the proxy service. So they actually provided the right command line parameters to make the query a proxy query. So the question is: Is this something that we should continue to provide?
I think this gets us to the question time.
CHAIR: Okay. Thank you very much for this presentation. May I ask you to go back a couple of slides with regard to the Data Protection Task Force update because I think we, based on the data you gave us, we should actually sort of ask the community about the input. So the first one ‑‑ I don't mind which sequence.
So this is something which we would like to ask you to think about and to come back with input. The idea here is that we would not allow, in the future that you explicitly select particular NIC handle any longer. What the idea is that you could still select the character prefix of the NIC handle. I think most of you know how they look. They may be, A, B, C and then a couple of numbers, a couple of figures dash RIPE so. What you can actually and /TPHAOEPB that, after that proposal, might get implemented, you could still sort of get these vanity character combinations but just for the prefix, just for the characters. And the numerals, the sort of sequence number beyond these, between two up to four characters, that these numbers would be assigned by the robot, and if this number, a particular number has been used once and the object has been deleted, then nobody would be actually be able to use the same sequence number with that particular character combination. That's the basic idea.
What we would like find out here is if anyone has scripting machinery or internal management proxy in place which might be affected by that. Okay. So Peter?
AUDIENCE SPEAKER: Peter Koch: I would just like to add a bit of reasoning behind that. It was not only would nobody be able to manually rereassign these, but they would also no longer automatically reassigned by the RIPE database when you leave out this. The reasoning behind that was, the external references into the RIPE database so people using RIPE NIC handles in their customer database, for example. So to to avoid clashes there. That's the point where you ask for the external scripting, right?
CHAIR: Thank you Peter. That's exactly the background. Thanks for the clarification. Does anyone think that he or she or it, the programme, would be affected by that change? No? Okay. That looks like we would be safe, more or less safe to do that.
AUDIENCE SPEAKER: Wilfried, I don't expect problems here. However, ‑‑ well okay, I have some doubts that we can take safe conclusions from the representation of a user base here. And on other things actually taking care in our procedures that we do not break existing stuff actually should be taken much more serious than in the past.
CHAIR: Yeah, I get that and sort of this is not the final decision. We wanted to test the waters here and as there is no big opposition, I think we'll go ahead with investigate into a little bit more detail like what it would affect and as usual, we would come forward with a proposal how to implement it. Okay. Shane.
AUDIENCE SPEAKER: Shane Kerr, ISC, actually I was going to sit down and let this go but I'd like to speak against being too careful. As we have seen in the past, people don't update their scripts until the changes have been made. So rather than I think historically using a long careful process doesn't actually improve the situation for users. So I would say, I think this is a fantastic idea. Just go ahead and do it as soon as possible.
AUDIENCE SPEAKER: Denis Walker, RIPE NCC: While we are on the subject of NIC handles, there is another situation which we would like to you to consider and give us some guidance on. We get asked more and more these days, people who want a NIC handle in the RIPE database to use in someone else's database and we are expected to manage these not often NIC handles because they are never used in the RIPE database but people just want to create them there and use them somewhere else. The question is whether we should actually allow the RIPE database to be used as a repository for other databases.
CHAIR: Yeah, or the other way around. Instead of some us of have in the past, a NIC handle for example in the ARIN database and it was very handy to use exactly the same handle in the RIPE database or in /OPL /SOER database.
AUDIENCE SPEAKER: George Michaelson from APNIC. I am very hesitant to speak on this issue, because I am not in region and I think these aspects of data management ultimately go to the behaviours that your direct membership want. But I'd like to make a more general observation; that the public good, the public benefit of Whois is the public facing query side. The management aspects are essentially a private good that reflect the ease that your membership have to to prefer update operations and although I value the ISP who is code necks /SEUSimmensely, it has been hugely valuable to us. I sometimes think that this owes referential integrity thing that you have the that is rightation framework inside Whois is probably more of a hindrance than a help and I think what you are doing here is good, and it's improving your management aspects, but at some point, would the database group consider reconsidering this model and perhaps external eyesing all of these issues into other update mechanisms? Because, something here just feels wrong about the complexity of this kind of management process and considerations of what you do or don't allow in cross member authorisation and all of these things. It's getting very complicated
CHAIR: Indeed.
AUDIENCE SPEAKER: It's not to say you are wrong. It's just the observation, this is starting to feel like it's an additionality complexity on the design of something whose public good is immense, but this aspect of data management is really a slightly different thing.
SPEAKER: Paul: Obviously we would love to spend all our time on looking at a new platform and working on new stuff. However we also have to maintain the existing stuff. So obviously that's one of my various points was we are thinking about something new and we want to really think this through and while we do that, we will have to maintain the system.
CHAIR: /SKWROFRPBLG, would you, sort of, as a speaker for the APNIC region (George) for APNIC, would you be interested to join in in such discussions, because I guess you are using very similar code like we do here in this region, so...
AUDIENCE SPEAKER: To be brief and not monopolise time at your microphone. I think there is a convergence of interest across all the registries. The ARIN meeting had a break out meeting that was discussing changing in provisions relating to their /SWEUP activity and /THREUS it's quite clear that technology has moved on from where it was five, ten years ago and many many people now have restful or other management provisioning systems and there is a sense that we have a shared issue here. So, yes, I wouldn't say myself but I am sure we would love to talk to you and you are right, of course you must maintain your current investment and this is an entirely appropriate activity. I don't mean to say don't do this. Sorry.
CHAIR: Okay. Thank you. So I think you are going to hear from our end. Shane?
AUDIENCE SPEAKER: Shane Kerr: George, I'd respectfully disagree that this is complicated. I think the changes that have been going on the database throughout its history have actually all been simplifications. While in principle, this sounds like more complicated than just pick what you want and stick it in the database. In practice, it has a lot of good properties and I think it's actually not a complicated mechanism. It's just fixing some implications of lack of design and lack of really thinking about. I mean the problem the RIPE database solves, it solves and there was was immediate need so there wasn't much thought given to kind of future sticky issues about refer he thinks integrity and this kind of nonsense. At some point you have to think about it and I don't think it's too complicated. So I think it's a totally appropriate level of a change in complication and things like that. So.
CHAIR: I take the point that it might ‑‑ that it's probably about time to do another NS E it, check where the stuff that we have been doing for the last five, six, seven years is still appropriate, or whether there is room for improvement. Okay. So thanks for the feedback to all of you. Could we please go to the next slide?
Just to give you a little bit of background. The only difference between a regular query and this proxy query on the technical level actually is that you register, you are able to register the IP address of your client querying the database and that IP address would be exempt from the /THROT link and blocking mechanisms which are in place to prevent data harvesting. So, the functionality of the query is almost the same or identical to a regular query, but you are allowed to sort of throw lots and lots of queries without getting trapped by the data mining or data harvesting prevention mechanism. And the question here really is whether this has any reasonable use these days or in the future? And there is George again.
AUDIENCE SPEAKER: George Michaelson, regularly manager of systems which perform proxy service queries on your engine. This is immensely valuable to us, immensely, and on behalf of the queries from my region, I thank you you for your continued desires and assistance in that regard. We love the fact that we don't have to be subject to your limits and it makes it much easier for us to offer all‑encompassing Whois services.
CHAIR: Thank you for that feedback. That was actually what we were hoping to hear that someone actually tells us why and how. Thanks for this.
AUDIENCE SPEAKER: Rudigar: Even without looking at the precise function of proxy server, I think if there are limits implemented, there is actually a need for having exemption rules, so well okay, whether it's proxy or well okay, it doesn't really count a lot whether say my regular procedure which are doing bulk queries but not for proxy /SROFRs, but really for using the data, when that reaches the limit well okay, I want to have an exemption so it should be, should stay there.
CHAIR: Actually, if I remember correctly, that /PHEBG./TPHEUFPL is actually different and that is in place too, so you can actually talk to RIPE NCC and ask them the limit or to at least increase the limit. What this one actually does is it includes the real clients IP address into the query string, so it's sort of our database then being able to still look at the original IP address and apply the same throttling mechanism. But the throttling is not applied to the IP address of the proxy server err but it's applied to the end user, did I get that correct? So I think we get the feedback that it's useful to sort of still offer that service, and that's about it.
And the next slide please.
CHAIR: Again, any comments to this report? Peter?
AUDIENCE SPEAKER: No, not for that.
CHAIR: Okay.
AUDIENCE SPEAKER: Hi, risk: Sorry, if this is the wrong place to ask, this is my first meeting so... I would like to know if there is any plan for AS used implementation of IPv6 queries? AS has given report for IPv4 assignments in allocation only as far as I know.
SPEAKER: Paul Palse: Maybe I can ask Denis to give some feedback on that.
Denis: AS used isn't actually managed by the database group. It's a tool which is managed by my business applications department. I am not sure there is anyone here who could actually speak about that right now. But, we can pass the message on and see what feedback comes back.
AUDIENCE SPEAKER: Okay. Thank you.
CHAIR: Maybe /AO*ED like to take it a little step further. Could we please register an action item for the NCC, whoever picks it up, whether it's being picked up then by this group or the other group, but we please have an action item to investigate what's missing. Okay.
AUDIENCE SPEAKER: Peter Koch, DE‑NIC, could you see go back to that slide where you presented the are /REFRB server stuff. Thank you for making that progress on that. The announcements that went out those two weeks ago, I wasn't so sure is this the plan scan can progress in the to actually approach the individual maintainers of those objects or was that to be the general announcement only? The reason I ask and I am partly guilty of this thing coming to this when I had to dig through ancient data and actually use the stuff that was in the rev.srv attributes. These are probably very old objects and slightly in an unmaintained state maybe, some of them. So, how do you make sure that the maintainers or maintainers of the time really get hold of this, because they might not read the database Working Group announcements.
Paul: Actually I think the original plan was not to delete the attribute as such, but change it into a remark line. So, we just say remark colon and then the original attribute. However, on the ‑‑ received also messages hinting towards ‑‑ I mean, if you are just turning this yet into another remark, why not just completely remove it? So, ‑‑ we are not going to e‑mail all the maintainers of these objects and ask them to look at their objects. It's not currently in the plan, so...
AUDIENCE SPEAKER: Okay.
CHAIR: Do you think there is a point in actively trying to contact those people? Because this is really very, very old stuff. It was not used in any way or fashion over, I don't know how many years, but quite a few. So, my personal taking off my hat as database Working Group chair, my personal take on that one with would be that it's more appropriate to silently do away with that during phase 3 and there was a proposal circulated, I think it was Denis circulating the proposal of this three phases, so phase /# where you get sort of warnings, then no longer accepted and third phase if you haven't reacted by then, we are going to walk through the database and simply throw those stale attributes away without converting them to remarks. Because if you want to keep the information, invited to do so on your own during phase 2.
AUDIENCE SPEAKER: /O*ERBGS, okay, that brings us to another interesting issue. So approaching the maintainers, I guess you are right and I would have expected lots of bounces and stuff. But still I just wanted to have this clarified and from my perspective ‑‑ well, that sounds reasonable.
The other question, whether or not to keep the information and change it to remarks or not. I am actually split here. From a purist's point of view, would agree with you, delete these stale attributes and have this a clean thing. Having gone through this interesting task of gathering information on very old assignments and very old objects, the information in there has been kind of helpful indirectly to find pointers to who back at that time was responsible. Like, /O*ERBGS, I recognise the name of this name server which has been out of service for the last maybe 12 years or so but since the rest of the information in the object might also have been very say imprecise, in some rare cases, the rev.srv attributes gave some additional insight. So from that perspective, I'd keep that,.
CHAIR: That's good input, just to have another hint whom to talk to to find out ‑‑ okay, I get it. I think then we are done with the, with this presentation. That was the summary? Thanks again again Paul.
(Applause)
CHAIR: The next item on the agenda is a thing that I have put in. Unfortunately I was not able to attend the previous meeting in Dubai, so I slightly got out of sync with regard to IRRToolSet and could you please do the agenda?
The thing here is that we were talking ASPLAIN and some other stuff and ASPLAIN does have an impact on the tools, on some of the tools actually consuming AS number information and my guys back home alerted me that the IRRToolSet might not be very aggressively maintained these days. So, first of all, I'd like to find out how many of you, how many of us are actually using the IRRToolSet or a subset of that on sort of daily basis? That's a few, but still this is database and not routing and not operations here. So what's your feeling about the maintenance quality of IRRToolSet? Because the background is that a while ago, originally it was designed and implemented in the framework of the routing arbiter project and the RIPE NCC inherited the maintenance of the IRRToolSet, then it went to the Internet software consortium because we thought they would be, they would to a much better job than the RIPE NCC. And just recently, if my information is correct, the ISC moved this thing to maintained by the community. And my worry actually is: Who is the community
AUDIENCE SPEAKER: Shane Kerr: I am the person who actually did most of that moving and things like that. There is ‑‑ well, as of the last three days, there is a website that's not up, but once we get the figure out what's wrong with the host and get it back up, there is a website which is mostly a development website, but it also includes a WIKI and things like that and it has a set of patches that have been merged and some that have not been merged which provide a number of fixes and functionality and things like that. So if you are planning and using the IRRToolSet, I recommend you checkout the latest code from subversion. There is a good chance that you might have problems compiling on your system or have parse bugs and things like that that have been fixed.
The intention was to wait for a couple of fixes before putting out the next official release. And one of those is the 32‑bit ASN support. I don't know actually if that patch ‑‑ the patch has been submitted. But there were some issues that the authors of the patch and some of the ear people on the mailing list were discussing before, they kind of declared it final. I think that's still the case. If you want to give it a try, the patch is available and something that you can download and attempt to use. I don't know if that's with ASPLAIN or with the dot notation.
CHAIR: Is there any one or any organisation sort of trying to coordinate that effort? Or is it just whoever wants to do it is fine but nobody is going to do it in the end?
AUDIENCE SPEAKER: Shane: Right. So the plan was to ‑‑ because ISC frankly doesn't use this software and they don't ‑‑ their community is mostly, it's an open source company so it provides open source solutions. But the most ‑‑ it's not really the normal customer base, the IRRToolSet group. So, there are some people who actively participate on the mailing list, people who generate these patches and things like that. It is no one's full‑time job. I am taking the responsibility to do minor administrative work on the WIKI and things like that. But to be honest, I don't have the time or the interest and I don't think anyone does to do active maintenance on this software.
AUDIENCE SPEAKER: Rudigar: Well, okay, let me give a view from the user side. During the time when I CS was formally fully responsible, there was a long time (ISC) where it essentially was dead. There was actually a user community in the background that was doing patches, but well, okay, the patches didn't actually get integrated and well okay, since the ISC activity was very low, those persons ‑‑ well okay, we don't really know whether they pushed all patches up. So, the move over to the open software community supported thing, in fact is a better basis for getting things done.
Of course, it depends to a large extent on who has, who is contributing what resources? And for my own organisation, these things turned out to be really bad timing because the guy who had been doing lots of work for me, we we unfortunately haven't yet integrated, disappeared about at the moment when the open software of platform became available. But, well okay, I think the current situation is much better than before. Though, if my colleagues from our IT branch of business would start to discuss with me whether this is a reliable and tenable basis for production software, I would have a really hard time to win an argument.
CHAIR: Okay. Thank you. So there any feeling that it might make sense to ask the RIPE NCC again to sometimes have a look at this community maintained thingy? Not taking over the responsibility, because that's not the point I am trying to make. I am feeling uneasy if you rely on a community which doesn't have any structure and any guide dog, because ‑‑
AUDIENCE SPEAKER: It's strange that you would say that at a RIPE meeting. But I don't think there would be too much benefit in asking the RIPE NCC to have a look. I think the main thing missing is sort of a set of clear objectives and then some resources to meet them. So I think if someone has enough interest, they can spend a few hours deciding what they want and propose it to the mailing list. And then either someone will come forward and help them with it or they won't and if they don't, then maybe I think it's appropriate to contact the RIPE NCC. I don't think it makes sense to just say "Well it seems like it's not very well maintained, can you please have a look?" That's my feeling.
AUDIENCE SPEAKER: And /RES: I think what we did in the past and when we were requested to help making this our tool set more up to date and facilitate /TOEFPLT in this area, we ISC to create this platform and we still provide limited financial support, very limited I must say, to maintain this platform. But this is only about the platform. So, how alive it is based on this platform depends very much on people that participate. And that's the substance of any object software project. So we are happy to provide the support for the platform but I think it's up the to community to actually feel this was real fill with this real activities.
AUDIENCE SPEAKER: Rudigar: Andre, thanks to RIPE NCC for actually pushing and making the recent improvement, but well okay, it cannot guarantee success and actually, Wilfred, I stepped up because what I am seeing here is well, looking at the software, it's very /KPHREU aid, it's very large (complicated) and well okay, it's ‑‑ it has been an academic development that was using all kinds of interesting techniques and didn't include any documentation. So any maintainer is facing bad challenges. On the other hand, the overall functionality that is delivered is not necessarily used by all of the users. And there are competing other tools to evaluate our PSL databases that usually have much more limited functionality and for my own purposes, my evaluation always was the alternates do not achieve a level of functionality that I need but I need much less than IRRToolSet. So having a really good software being maintained economically in the community, one of the problems I see is that well okay, this is much too heavyweight a stone to carry around, and one of the things that I feel are somewhat missing also in that user community is that well okay, very little discussion happens of well okay, what are actually the functional requirements and the development requirements. So it might ‑‑ there might be a very good case for taking up a discussion of well okay, what kind of functionality and what kind of interface one would like to make progress with tools that are addressing this area. And may I remind you to the discussion yesterday where we were pointing out that doing interesting future work probably means we have to create some new tools for enabling the next security steps.
CHAIR: Yeah, but then this discussion should probably be in the routing Working Group. What's your feeling?
AUDIENCE SPEAKER: Rudigar: Well we can take it there, we can take it there. My feeling is that the true routing guys usely to do not really look into that kind of software stuff, but well okay, it's hanging somewhere in between. But the notion that it could be a very good idea to consider what requirements in this area are and how to address them. And well okay, even in that context, to ask whether this may require an effort where the NCC can help in a defined way, could make some sense.
CHAIR: Okay.
AUDIENCE SPEAKER: RIPE NCC is in a way supporting IRRToolSet by promoting the existence of it and increasing the user base in the Routing Registry training courses that we do. So for now this is the main tool that we tell people /P /TP* you want to use the Routing Registry there is our configure and we are aware of the existence of our tools. Often during those training courses we tell people did you ever try using this tool they say yeah, but it didn't work. And then they go to the mailing list and they ask questions, ask for support, sometimes they get it, sometimes they get more or less actively involved.
CHAIR: Okay. Thanks for the feedback.
AUDIENCE SPEAKER: So, correct me if I am wrong, but the most common user for auto set nowadays is to get from something like RPSL language to list of prefixes in order to maintain your route filters and there is an effort undergoing here about certification. Somewhere in the future we will get to the point when there will be only to map prefix to auto number systems basic route object and there will be new way to do so using certificates. And I think there should be some efforts, I don't know by whom, to ensure that when at the purchase point our own tool set asks basically the most widely known tools to generate route filters will support it.
CHAIR: Okay. Thank you. Rudigar.
AUDIENCE SPEAKER: Rudigar. One hint to you, actually for the long transition phase for getting the RPKI based stuff in, it has been observed that well okay, there are very simple and effective ways to make RPKI relevant data directly available within RPSL syntax and even semantics. So that well okay, maintaining and keeping an eye on the RPSL tools is actually a helpful thing there (RPSL) and actually for anybody who is interested for making quick progress in that area (RPSL) of course having a path where the existing tools can be directly used is looking like much more promising than to wait for a yet to be defined native set of tools.
AUDIENCE SPEAKER: Okay. Thank you.
CHAIR: Okay? So I think we collected quite a bit of information and we are being to see sort of where we have to do things in the future and how to do that. /*PL /*PL okay. Thanks for the feedback to everyone.
That takes me to the next and last item input from other Working Groups. We already started to talk about DNS related stuff with the reverse server attribute being phased out. What we learned yesterday or the day before in the first session of the DNS Working Group was that the RIPE NCC is currently updating or working on an update or working on an improvement on the system to automatically generate reverse DNS delegation zones name server configurations and there are a couple of things that are related to that.
For those of you who are not fully included in. This is a machinery that allows us to request reverse delegations by registering a domain object into the RIPE database and then on a regular bases, there is a robot which digests these objects and (/KHR*Ued) and does the right thing, which means that some files are generated from that information, that name server configuration /R‑S automatically generated from that informs. And it also provides for us a single point of requesting reverse delegations even for those address blocks where the next upper layer DNS responsibility is not with the RIPE NCC but for example, with ARIN. And that machinery is going to be updated and I would invite all of you to have a look at your experience with that machinery in the past and if you had any issues with that or if you do think there is room for improvement, then I think it's about the right point in time to provide your feedback. We have asked the RIPE NCC to come forward with a description of what they intend to do and how and what they want to achieve, and I presume that piece of information will be circulated both on the DNS Working Group mailing list and on the database Working Group mailing list and we then have to decide where to have the discussion about those things. Peter?
AUDIENCE SPEAKER: Peter Koch, DE‑NIC, and wearing my DNS Working Group co‑chair hat here. Nothing what you said was wrong. Just let me add one additional perspective here. This is also about the cases where there is a reverse delegation object for a /16 in the database and people can now submit database ‑‑ domain objects for subordinate /24s and they do not receive a warning and nothing, but just their user experience ‑‑ I love this ‑‑ is bad, because of course, when there is a delegation on a /16 boundary already there is no way that the NCC could add the /24 delegation as well because that's, that has been going somewhere else completely and that has confused people. We have been in a situation being responsible for /16 actually my /TPWRAEUTing this out and getting rid of this (migrating) and especially in the transition phase, there was some confusion amongst users and that was what and in the Working Group presented to the Working Group and then propose that had there be a mechanism or some changes and this is an action item in Anand) to phrase this exactly or come up with a proposal that probably, in these cases, the /24 domain objects should just be refused or maybe a warning /PWAU /PW*U that is up for further discussion.
AUDIENCE SPEAKER: And re: I just want the to second what Peter said. That was a very particular point from the RIPE NCC they would like to get some community feedback on.
With regards to changes to our provisioning something, they did at least what we are planning is not as radical as it might sound. Basically we are doing some /KPHRAOEPB up and redesign of internal machinery. While still keeping in mind that our database is the main provisions interface and you probably remember where this idea came from, it came from the fact that scan can clean in the what we thought as a community that databases is a very familiar interface for people to work with update their I N M numb updates and other things. It's logical to extend the database function at to cover reverse DNS provisions. Now, things are changing of course and we might think of different ways of update /TH‑G information. Like EPP, like something different, not just database. But the scope of our activities is basically limited to redesign of internal machinery and also looking at the hardening our DNSSEC provisioning system. That's probably the main focus.
CHAIR: Thanks and re. One of the reasons I brought /TUP here, for example we don't have any means at the moment to tell the machinery from which ‑‑ well assuming the case that the RIPE NCC name server is a /SHRAEUPL for a reverse zone, we don't have any mechanisms right now to tell the machinery from which master to pull the zone from. And sort /TP‑F you are touch that go anyway, it might be an opportunity to think about do we need it? If we don't need it, then we don't have to take it into consideration. If anyone needs that, then it might be the right point in time to speak up up. Because for us it actually happened to us for one of our customers and for the moment the only solution was actually to not have a slave at the RIPE NCC because there is nobody to actually convey the proper configuration information. But that's maybe just an exceptional case.
AUDIENCE SPEAKER: Anand Budhev: I'd just like to clarify something there. It's true that at the moment there is no simple way for an end user to specify which master server to pull the zones from. We have had a couple of requests for this from users and we have made manual edits to our configuration to allow for this. So you know, it's possible, it's not impossible, but it's not easy for us to maintain because it's, you know, manual work and something that could easily be overlooked by an engineer for example. So, yes, we would very much like the community to consider you know, allowing changes to the RIPE database scheme for the main objects to allow this feature.
CHAIR: Okay. Thanks Anand. That's about it I think. If there is no other input to that topic, it gets us to any other business. Is there any other business? Anyone you want to bring up here? No?
So then I think we can close the Working Group session right now being early this time. So you are going to have a longer break.
Thank you. See you next meeting. (Applause) (Coffee break)
CHAIR: Good morning. Welcome to the usual Friday morning session of the database Working Group. I am Wilfred Woeber. I am trying to keep this session on track and to make us finish as soon as possible. We do not have too many things on the agenda today, but let's start with the more administrative matters.
To introduce a couple of other people for those of you who have not been around for a long time. Over there is Nigel Titley who is one of the two co‑chairs of this Working Group. And you are going to be introduced to Paul Palse from RIPE NCC giving the update about the database activities today.
So, for the logistics, I'd like to extend my thanks again to Nigel Titley who offered to take notes. The other thing to mention here is that we really invite you to participate and not sort of to just listen in on what Nigel, myself and Paul is going to present been please be active and to join in. If you do that, please walk up to the microphones and state your name, that's the minimum we ask you to do, you are also welcome and invited to give your affiliation, organisation or function. You are speaking for.
We also have remote participation which is taken care of by our colleagues from the RIPE NCC. Thank you.
The next thing to do, business formality is to agree on the agenda for this meeting. I have circulated minor update yesterday for the draft agenda to we have draft agenda version two. Is there anyone who wants to propose any modifications to that, additions, reseek /EPBSing, not talking about some stuff, maybe? No? Okay, agenda we are going to work from today and the next action actually is to formally approve the minutes from the previous meeting in Dubai. Minutes have been circulated on the list. The draft minutes have been available from the Working Group web page. So, is there any amendment you want to make, any comment? No? So, the Dubai meeting minutes have been approved by that. And we ask the RIPE NCC, together with Nigel to actually modify the status of the minutes from draft to final (Nigel)
Next thing to do is to review the action list and I'd like to invite Nigel to walk us through the list of open and completed actions.
SPEAKER: Nigel Titley: Action item review: The birthday background is because some of these actions are coming into their second year now, so it's happy birthday dear actions.
Okay. Although actually we haven't got that many so it's actually quite good. 54.1. RIPE NCC, maintainer attribute on all objects. Will Paul be dealing with that later? Right, okay.
Clean up of orphaned objects. Paul dealing with that.
RIPE NCC removal of Revenue serve attribute. Dealing with that later.
RIPE NCC at MNT,‑IRT to the LIR portal. It's done, that one can be put to bed then.
Then there is an action on the Data Protection Task Force, do we have a representative from that taskforce here? Okay. Do you know whether anything was done on this one? We suspect not. Okay. So this one is ongoing. This is just a consideration.
Then finally, 57.1 from the last meeting, implement ASPLAIN which I think is definitely done and you'll be dealing with that later.
That's it. Nice and quick.
CHAIR: Thank you Nigel.
And also I'd like to invite Paul to give the usual traditional RIPE database activities /PRAEPBGSD /W‑Z' said already, within that presentation, we have going to have also (preparation in in information related to some open actions and to the data protection, data privacy taskforce. So Paul, the floor is yours.
SPEAKER: Paul Palse: Thank you. I am Paul Palse, the database manager since January this year. And I will be giving you the database update today.
I'd like to first of all start with the introduction to the database group and then talk you through the action points that we took away from previous RIPE meetings and some statistics and operational data and we have had a Data Protection Task Force meeting this week and I'd like to give you some highlights that we took away from that meeting and obviously after that, there is time for questions.
The database group, for you who haven't seen previous meetings slides. Here we are and hi guys.
So, who are stakeholders in the database department? We obviously have the RIPE community via the various Working Groups and internally, we have the IT department, business applications, DNS, registration services and customer services and we also have legal and law enforcement stakeholders.
So action points: Maintaining ‑‑ making main tainters on roll and person objects and this was action point 54.3. We find that this hasn't seen enough action to our liking, but that's because it has a slightly bigger effect and anticipated, especially in the area of documentation and some procedure changes that need to be coordinated within RIPE departments. There is also some progress to report. We have done the code changes necessary. And when we have finished the documentation part, then we are actually able to deploy our code changes. And we have also added a new boot strapping page for new users that allows them to easily create a first person maintainer.
And I would suggest as a little note, before we roll this out to check that you have written any scripts that automatically generates objects, that once we role out our changes that your scripts don't stop working.
And we'll try to deploy all that as soon as possible after this meeting.
And this is that start up page. I think at the previous meeting there was still a prototype stamp on that, but we have done the work for it. (Prototype)
There has been some talk, and I didn't want to leave that out, about data quality and this is a RIPE wide initiative and obviously the database team is also part of that effort. And we would lays basically like to know if we can still reach all the maintainers of the objects in our database (basically) and we are planning and and I want to emphsize this is a well coordinated effort, we would like to mail out the maintainers and see if they are still responsible for the objects that we have in our database. And if you receive such e‑mail, you can help us by responding to it.
Action point 54.7: The refer server application, attributes deprecation on I‑Net and I‑Net ^6 numb objects. About two weeks ago we have announced we would roll out the syntax changes or the software that enforces the software syntax changes to give you a bit of time to look at your scripts again, that's still used Revenue server attributes, so please change those scripts and we think if about two weeks time we will roll out those changes /TPR‑PBD that moment onwards we won't be accepting /*EF server attributes on on INET and INET 6num any more.
If you need to make up dates, you can decide to either remove the attribute or change it into a remark line. But either way, whatever it your /‑PB preference. And then before the next RIPE meeting we will be running scripts to deprecate the remaining attributes on these objects.
Cleaning up unreferenced person objects. Action point 54.6: /*F we have started to delete these objects in batches the we started off with very tiny batches to see if we got any feedback, and slowly on increased these batch sizes and we deleted approximately a little bit over 120,000 objects so far. And we are planning to increase the batch size. So that we have removed all these objects before the next RIPE meeting. However, we will be keeping this script running so that any personal roll object that remains in the database and remainsed unreference forward a period up to 21 days will be automatically removed from the database.
If you need your unreferenced person objects to remain in our database, then we recommend you to contact one of the RIPE Working Group chairs. And they can add you to what we call the white pages. And obviously those objects won't be removed.
ASDOT to ASPLAIN migration, we did that on the 25th March and was quite a smooth action there and we found that all together about 184, about exactly 184 objects were affected in some way.
Last RIPE meeting we promised to come back with some feedback on an approach on mirroring. This was what I understand is quite a heated discussion last meeting. So, we promised to do some homework here and I would like to start with others mirroring the RIPE database. As an example, we have looked at RADB, that's mainly, or I think only mirrors our routing data and found that they are nearly, aside from I think one known object, they are completely in sync with what's in the RIPE database. This doesn't include personal data, and because transforming, or moving everyone who using our NRTM to person NRTM streams that don't contain any personal data, for instance, our DP‑TF service won't suffer in anyway from this. Then we obviously also have us mirroring other databases. And we understand that mirroring is important to you, especially if it's in ‑‑ if we represent the data in RPSL format.
We have looked at how can we improve the data that we maintain and we basically have to see what we get in. We also need to match up some discrepancies between the scheme outs of the different objects that we get back and hope to, from that moment ‑‑ when we have assessed that, then we can look at how we can improve the data that we are holding.
Various updates: In previous meetings, we have showed you some plans around improving our system architecture. Well, we have done most of the work. This new architecture is based on cluster, it's hardware, which would give us a zero data loss in case of we are holding data in two physical locations, or there wouldn't be any data loss in case of failure. It would obviously improve resilience and facilitate possible growth. And again, this is something that we are on the point of deploying and this will ‑‑ I am it have dent that I could present something at the next RIPE meeting in this regard.
Various updates: Again, we upgraded our, finally upgrade or GnuPG to a new version that allows you to use a newer /HAFRBing algorithms and some fun facts they've /SPWRO introduced, a slightly better way of working with project management. It's an agile software development practice called SCRUM and we are using two weekly sprints. And obviously ones we have deployed are our new hardware infrastructure. It gives us a better platform to think about future enhancements and improvements.
Some operational data: This is the customer service team that sits on the other end of the e‑mail messages that you send and get back. And they obviously take care of the first line support. They will escalate any tickets to the database department and we function as a second line for them.
Some stats on tickets: The blue line is what's between 56 and 57 RIPE meet ‑‑ meeting 56 and 57 and orange is 57 /58 and we see a nice decline. The notification issues, there was a technical reason for that high level, the high number of tickets so we have addressed that and we can, we would see a further decrease in that area.
RIPE database statistics: Whois queries per minute: Basically, I have taken the stats that we showed previously at the end of January 2008, we were at about 4,000 queries a minute and the blue line you see on top of there is a whole year of queries, April to April, and we see a nice increase. And there is a little orange line there as well, and that's our IPv6, our queries over IPv6, and actually it's not so bad, it's approximately 1 percent over that one year of queries we get in over IPv6. A little bit less than 1 percent.
How do you query us? Mostly ‑‑ sorry, this is ‑‑ yeah, we see that proxy queries are actually less popular these days. I will come back to proxying a little bit later in my presentation as well.
Some stats on Whois queries, where are the queries coming from and a question we often get is how do you generate these stats? We use GOIP for this and these are not domain extensions but just country codes. The slice that is don't have percentages with it range between 3 and 2 percent I think.
Queries per month, and in web terms the stickiness of our queries, there is quite a lot of ad hoc queries, only 1 to 10 queries per unique IP address is most popular. Then it goes up to 100 to 1,000 queries. Only 2 percent of queries come back more regularly.
Updates stats: This is running over a six week period. This is running at approximately two successful queries a minute. And we have seen peaks of 30 minutes, which we can easily handle.
How do we receive our queries? 23 percent over e‑mail and 77 percent of IRR syncupdate. There is various inter phases into that syncupdate so that's all represented by this blue area. 67 percent are successful results ‑‑ have successful results. And this is also what we based our previous statistics on and 24 percent fails for some reason. And we mark 9 percent as spam. 0 percent is a very small amount still, request help via our update methods. You actually receive an e‑mail back with help data.
And then up time: Last meeting we presented nice figures. Five 9s. This meeting, my first meeting, I have to report a slight dip in mail updates. But the good news is that this was a glitch in the monitoring system that we found after doing updates, we fixed that so if we didn't take that into account, that line would be nice and flat.
Okay. The highlights from the Data Protection Task Force. I am just going to tell you what came out of that and maybe during the question time, you can give us some feedback on some of the items.
So, in light of not reusing NIC handles, we came up with an idea to stick to letting you choose that two character prefix and we will just automatically generate the sequence number behind that.
We have also taken action points from this meeting and what we would like that do is to see what the impact would be if we enforced the rule that the maintainer needs to authenticate a request to have their persons object connected with a resource that's managed by a different entity. You could think that you know, if we enforce this rule, that maybe people would start duplicating person objects just to work around this system. So, we need to go back, look at that and see what we can propose.
Proxying. I promised you to come back on that. The taskforce was looking at the terms and conditions and you know, there is still quite a few proxy agreements and we were looking at how can we make sure that the queries or the results that are presented via these proxies also adhere to the terms and conditions and in that light, we felt, well how many people, or how many users of our proxy /SR‑FRS are there around? We have done some ‑‑ we have looked into (servers) we found this week actually that there is 89 proxy agreements currently of which 28 have queried the database this year. Of which actually only 18 actually used the proxy service. So they actually provided the right command line parameters to make the query a proxy query. So the question is: Is this something that we should continue to provide?
I think this gets us to the question time.
CHAIR: Okay. Thank you very much for this presentation. May I ask you to go back a couple of slides with regard to the Data Protection Task Force update because I think we, based on the data you gave us, we should actually sort of ask the community about the input. So the first one ‑‑ I don't mind which sequence.
So this is something which we would like to ask you to think about and to come back with input. The idea here is that we would not allow, in the future that you explicitly select particular NIC handle any longer. What the idea is that you could still select the character prefix of the NIC handle. I think most of you know how they look. They may be, A, B, C and then a couple of numbers, a couple of figures dash RIPE so. What you can actually and /TPHAOEPB that, after that proposal, might get implemented, you could still sort of get these vanity character combinations but just for the prefix, just for the characters. And the numerals, the sort of sequence number beyond these, between two up to four characters, that these numbers would be assigned by the robot, and if this number, a particular number has been used once and the object has been deleted, then nobody would be actually be able to use the same sequence number with that particular character combination. That's the basic idea.
What we would like find out here is if anyone has scripting machinery or internal management proxy in place which might be affected by that. Okay. So Peter?
AUDIENCE SPEAKER: Peter Koch: I would just like to add a bit of reasoning behind that. It was not only would nobody be able to manually rereassign these, but they would also no longer automatically reassigned by the RIPE database when you leave out this. The reasoning behind that was, the external references into the RIPE database so people using RIPE NIC handles in their customer database, for example. So to to avoid clashes there. That's the point where you ask for the external scripting, right?
CHAIR: Thank you Peter. That's exactly the background. Thanks for the clarification. Does anyone think that he or she or it, the programme, would be affected by that change? No? Okay. That looks like we would be safe, more or less safe to do that.
AUDIENCE SPEAKER: Wilfried, I don't expect problems here. However, ‑‑ well okay, I have some doubts that we can take safe conclusions from the representation of a user base here. And on other things actually taking care in our procedures that we do not break existing stuff actually should be taken much more serious than in the past.
CHAIR: Yeah, I get that and sort of this is not the final decision. We wanted to test the waters here and as there is no big opposition, I think we'll go ahead with investigate into a little bit more detail like what it would affect and as usual, we would come forward with a proposal how to implement it. Okay. Shane.
AUDIENCE SPEAKER: Shane Kerr, ISC, actually I was going to sit down and let this go but I'd like to speak against being too careful. As we have seen in the past, people don't update their scripts until the changes have been made. So rather than I think historically using a long careful process doesn't actually improve the situation for users. So I would say, I think this is a fantastic idea. Just go ahead and do it as soon as possible.
AUDIENCE SPEAKER: Denis Walker, RIPE NCC: While we are on the subject of NIC handles, there is another situation which we would like to you to consider and give us some guidance on. We get asked more and more these days, people who want a NIC handle in the RIPE database to use in someone else's database and we are expected to manage these not often NIC handles because they are never used in the RIPE database but people just want to create them there and use them somewhere else. The question is whether we should actually allow the RIPE database to be used as a repository for other databases.
CHAIR: Yeah, or the other way around. Instead of some us of have in the past, a NIC handle for example in the ARIN database and it was very handy to use exactly the same handle in the RIPE database or in /OPL /SOER database.
AUDIENCE SPEAKER: George Michaelson from APNIC. I am very hesitant to speak on this issue, because I am not in region and I think these aspects of data management ultimately go to the behaviours that your direct membership want. But I'd like to make a more general observation; that the public good, the public benefit of Whois is the public facing query side. The management aspects are essentially a private good that reflect the ease that your membership have to to prefer update operations and although I value the ISP who is code necks /SEUSimmensely, it has been hugely valuable to us. I sometimes think that this owes referential integrity thing that you have the that is rightation framework inside Whois is probably more of a hindrance than a help and I think what you are doing here is good, and it's improving your management aspects, but at some point, would the database group consider reconsidering this model and perhaps external eyesing all of these issues into other update mechanisms? Because, something here just feels wrong about the complexity of this kind of management process and considerations of what you do or don't allow in cross member authorisation and all of these things. It's getting very complicated
CHAIR: Indeed.
AUDIENCE SPEAKER: It's not to say you are wrong. It's just the observation, this is starting to feel like it's an additionality complexity on the design of something whose public good is immense, but this aspect of data management is really a slightly different thing.
SPEAKER: Paul: Obviously we would love to spend all our time on looking at a new platform and working on new stuff. However we also have to maintain the existing stuff. So obviously that's one of my various points was we are thinking about something new and we want to really think this through and while we do that, we will have to maintain the system.
CHAIR: /SKWROFRPBLG, would you, sort of, as a speaker for the APNIC region (George) for APNIC, would you be interested to join in in such discussions, because I guess you are using very similar code like we do here in this region, so...
AUDIENCE SPEAKER: To be brief and not monopolise time at your microphone. I think there is a convergence of interest across all the registries. The ARIN meeting had a break out meeting that was discussing changing in provisions relating to their /SWEUP activity and /THREUS it's quite clear that technology has moved on from where it was five, ten years ago and many many people now have restful or other management provisioning systems and there is a sense that we have a shared issue here. So, yes, I wouldn't say myself but I am sure we would love to talk to you and you are right, of course you must maintain your current investment and this is an entirely appropriate activity. I don't mean to say don't do this. Sorry.
CHAIR: Okay. Thank you. So I think you are going to hear from our end. Shane?
AUDIENCE SPEAKER: Shane Kerr: George, I'd respectfully disagree that this is complicated. I think the changes that have been going on the database throughout its history have actually all been simplifications. While in principle, this sounds like more complicated than just pick what you want and stick it in the database. In practice, it has a lot of good properties and I think it's actually not a complicated mechanism. It's just fixing some implications of lack of design and lack of really thinking about. I mean the problem the RIPE database solves, it solves and there was was immediate need so there wasn't much thought given to kind of future sticky issues about refer he thinks integrity and this kind of nonsense. At some point you have to think about it and I don't think it's too complicated. So I think it's a totally appropriate level of a change in complication and things like that. So.
CHAIR: I take the point that it might ‑‑ that it's probably about time to do another NS E it, check where the stuff that we have been doing for the last five, six, seven years is still appropriate, or whether there is room for improvement. Okay. So thanks for the feedback to all of you. Could we please go to the next slide?
Just to give you a little bit of background. The only difference between a regular query and this proxy query on the technical level actually is that you register, you are able to register the IP address of your client querying the database and that IP address would be exempt from the /THROT link and blocking mechanisms which are in place to prevent data harvesting. So, the functionality of the query is almost the same or identical to a regular query, but you are allowed to sort of throw lots and lots of queries without getting trapped by the data mining or data harvesting prevention mechanism. And the question here really is whether this has any reasonable use these days or in the future? And there is George again.
AUDIENCE SPEAKER: George Michaelson, regularly manager of systems which perform proxy service queries on your engine. This is immensely valuable to us, immensely, and on behalf of the queries from my region, I thank you you for your continued desires and assistance in that regard. We love the fact that we don't have to be subject to your limits and it makes it much easier for us to offer all‑encompassing Whois services.
CHAIR: Thank you for that feedback. That was actually what we were hoping to hear that someone actually tells us why and how. Thanks for this.
AUDIENCE SPEAKER: Rudigar: Even without looking at the precise function of proxy server, I think if there are limits implemented, there is actually a need for having exemption rules, so well okay, whether it's proxy or well okay, it doesn't really count a lot whether say my regular procedure which are doing bulk queries but not for proxy /SROFRs, but really for using the data, when that reaches the limit well okay, I want to have an exemption so it should be, should stay there.
CHAIR: Actually, if I remember correctly, that /PHEBG./TPHEUFPL is actually different and that is in place too, so you can actually talk to RIPE NCC and ask them the limit or to at least increase the limit. What this one actually does is it includes the real clients IP address into the query string, so it's sort of our database then being able to still look at the original IP address and apply the same throttling mechanism. But the throttling is not applied to the IP address of the proxy server err but it's applied to the end user, did I get that correct? So I think we get the feedback that it's useful to sort of still offer that service, and that's about it.
And the next slide please.
CHAIR: Again, any comments to this report? Peter?
AUDIENCE SPEAKER: No, not for that.
CHAIR: Okay.
AUDIENCE SPEAKER: Hi, risk: Sorry, if this is the wrong place to ask, this is my first meeting so... I would like to know if there is any plan for AS used implementation of IPv6 queries? AS has given report for IPv4 assignments in allocation only as far as I know.
SPEAKER: Paul Palse: Maybe I can ask Denis to give some feedback on that.
Denis: AS used isn't actually managed by the database group. It's a tool which is managed by my business applications department. I am not sure there is anyone here who could actually speak about that right now. But, we can pass the message on and see what feedback comes back.
AUDIENCE SPEAKER: Okay. Thank you.
CHAIR: Maybe /AO*ED like to take it a little step further. Could we please register an action item for the NCC, whoever picks it up, whether it's being picked up then by this group or the other group, but we please have an action item to investigate what's missing. Okay.
AUDIENCE SPEAKER: Peter Koch, DE‑NIC, could you see go back to that slide where you presented the are /REFRB server stuff. Thank you for making that progress on that. The announcements that went out those two weeks ago, I wasn't so sure is this the plan scan can progress in the to actually approach the individual maintainers of those objects or was that to be the general announcement only? The reason I ask and I am partly guilty of this thing coming to this when I had to dig through ancient data and actually use the stuff that was in the rev.srv attributes. These are probably very old objects and slightly in an unmaintained state maybe, some of them. So, how do you make sure that the maintainers or maintainers of the time really get hold of this, because they might not read the database Working Group announcements.
Paul: Actually I think the original plan was not to delete the attribute as such, but change it into a remark line. So, we just say remark colon and then the original attribute. However, on the ‑‑ received also messages hinting towards ‑‑ I mean, if you are just turning this yet into another remark, why not just completely remove it? So, ‑‑ we are not going to e‑mail all the maintainers of these objects and ask them to look at their objects. It's not currently in the plan, so...
AUDIENCE SPEAKER: Okay.
CHAIR: Do you think there is a point in actively trying to contact those people? Because this is really very, very old stuff. It was not used in any way or fashion over, I don't know how many years, but quite a few. So, my personal taking off my hat as database Working Group chair, my personal take on that one with would be that it's more appropriate to silently do away with that during phase 3 and there was a proposal circulated, I think it was Denis circulating the proposal of this three phases, so phase /# where you get sort of warnings, then no longer accepted and third phase if you haven't reacted by then, we are going to walk through the database and simply throw those stale attributes away without converting them to remarks. Because if you want to keep the information, invited to do so on your own during phase 2.
AUDIENCE SPEAKER: /O*ERBGS, okay, that brings us to another interesting issue. So approaching the maintainers, I guess you are right and I would have expected lots of bounces and stuff. But still I just wanted to have this clarified and from my perspective ‑‑ well, that sounds reasonable.
The other question, whether or not to keep the information and change it to remarks or not. I am actually split here. From a purist's point of view, would agree with you, delete these stale attributes and have this a clean thing. Having gone through this interesting task of gathering information on very old assignments and very old objects, the information in there has been kind of helpful indirectly to find pointers to who back at that time was responsible. Like, /O*ERBGS, I recognise the name of this name server which has been out of service for the last maybe 12 years or so but since the rest of the information in the object might also have been very say imprecise, in some rare cases, the rev.srv attributes gave some additional insight. So from that perspective, I'd keep that,.
CHAIR: That's good input, just to have another hint whom to talk to to find out ‑‑ okay, I get it. I think then we are done with the, with this presentation. That was the summary? Thanks again again Paul.
(Applause)
CHAIR: The next item on the agenda is a thing that I have put in. Unfortunately I was not able to attend the previous meeting in Dubai, so I slightly got out of sync with regard to IRRToolSet and could you please do the agenda?
The thing here is that we were talking ASPLAIN and some other stuff and ASPLAIN does have an impact on the tools, on some of the tools actually consuming AS number information and my guys back home alerted me that the IRRToolSet might not be very aggressively maintained these days. So, first of all, I'd like to find out how many of you, how many of us are actually using the IRRToolSet or a subset of that on sort of daily basis? That's a few, but still this is database and not routing and not operations here. So what's your feeling about the maintenance quality of IRRToolSet? Because the background is that a while ago, originally it was designed and implemented in the framework of the routing arbiter project and the RIPE NCC inherited the maintenance of the IRRToolSet, then it went to the Internet software consortium because we thought they would be, they would to a much better job than the RIPE NCC. And just recently, if my information is correct, the ISC moved this thing to maintained by the community. And my worry actually is: Who is the community
AUDIENCE SPEAKER: Shane Kerr: I am the person who actually did most of that moving and things like that. There is ‑‑ well, as of the last three days, there is a website that's not up, but once we get the figure out what's wrong with the host and get it back up, there is a website which is mostly a development website, but it also includes a WIKI and things like that and it has a set of patches that have been merged and some that have not been merged which provide a number of fixes and functionality and things like that. So if you are planning and using the IRRToolSet, I recommend you checkout the latest code from subversion. There is a good chance that you might have problems compiling on your system or have parse bugs and things like that that have been fixed.
The intention was to wait for a couple of fixes before putting out the next official release. And one of those is the 32‑bit ASN support. I don't know actually if that patch ‑‑ the patch has been submitted. But there were some issues that the authors of the patch and some of the ear people on the mailing list were discussing before, they kind of declared it final. I think that's still the case. If you want to give it a try, the patch is available and something that you can download and attempt to use. I don't know if that's with ASPLAIN or with the dot notation.
CHAIR: Is there any one or any organisation sort of trying to coordinate that effort? Or is it just whoever wants to do it is fine but nobody is going to do it in the end?
AUDIENCE SPEAKER: Shane: Right. So the plan was to ‑‑ because ISC frankly doesn't use this software and they don't ‑‑ their community is mostly, it's an open source company so it provides open source solutions. But the most ‑‑ it's not really the normal customer base, the IRRToolSet group. So, there are some people who actively participate on the mailing list, people who generate these patches and things like that. It is no one's full‑time job. I am taking the responsibility to do minor administrative work on the WIKI and things like that. But to be honest, I don't have the time or the interest and I don't think anyone does to do active maintenance on this software.
AUDIENCE SPEAKER: Rudigar: Well, okay, let me give a view from the user side. During the time when I CS was formally fully responsible, there was a long time (ISC) where it essentially was dead. There was actually a user community in the background that was doing patches, but well, okay, the patches didn't actually get integrated and well okay, since the ISC activity was very low, those persons ‑‑ well okay, we don't really know whether they pushed all patches up. So, the move over to the open software community supported thing, in fact is a better basis for getting things done.
Of course, it depends to a large extent on who has, who is contributing what resources? And for my own organisation, these things turned out to be really bad timing because the guy who had been doing lots of work for me, we we unfortunately haven't yet integrated, disappeared about at the moment when the open software of platform became available. But, well okay, I think the current situation is much better than before. Though, if my colleagues from our IT branch of business would start to discuss with me whether this is a reliable and tenable basis for production software, I would have a really hard time to win an argument.
CHAIR: Okay. Thank you. So there any feeling that it might make sense to ask the RIPE NCC again to sometimes have a look at this community maintained thingy? Not taking over the responsibility, because that's not the point I am trying to make. I am feeling uneasy if you rely on a community which doesn't have any structure and any guide dog, because ‑‑
AUDIENCE SPEAKER: It's strange that you would say that at a RIPE meeting. But I don't think there would be too much benefit in asking the RIPE NCC to have a look. I think the main thing missing is sort of a set of clear objectives and then some resources to meet them. So I think if someone has enough interest, they can spend a few hours deciding what they want and propose it to the mailing list. And then either someone will come forward and help them with it or they won't and if they don't, then maybe I think it's appropriate to contact the RIPE NCC. I don't think it makes sense to just say "Well it seems like it's not very well maintained, can you please have a look?" That's my feeling.
AUDIENCE SPEAKER: And /RES: I think what we did in the past and when we were requested to help making this our tool set more up to date and facilitate /TOEFPLT in this area, we ISC to create this platform and we still provide limited financial support, very limited I must say, to maintain this platform. But this is only about the platform. So, how alive it is based on this platform depends very much on people that participate. And that's the substance of any object software project. So we are happy to provide the support for the platform but I think it's up the to community to actually feel this was real fill with this real activities.
AUDIENCE SPEAKER: Rudigar: Andre, thanks to RIPE NCC for actually pushing and making the recent improvement, but well okay, it cannot guarantee success and actually, Wilfred, I stepped up because what I am seeing here is well, looking at the software, it's very /KPHREU aid, it's very large (complicated) and well okay, it's ‑‑ it has been an academic development that was using all kinds of interesting techniques and didn't include any documentation. So any maintainer is facing bad challenges. On the other hand, the overall functionality that is delivered is not necessarily used by all of the users. And there are competing other tools to evaluate our PSL databases that usually have much more limited functionality and for my own purposes, my evaluation always was the alternates do not achieve a level of functionality that I need but I need much less than IRRToolSet. So having a really good software being maintained economically in the community, one of the problems I see is that well okay, this is much too heavyweight a stone to carry around, and one of the things that I feel are somewhat missing also in that user community is that well okay, very little discussion happens of well okay, what are actually the functional requirements and the development requirements. So it might ‑‑ there might be a very good case for taking up a discussion of well okay, what kind of functionality and what kind of interface one would like to make progress with tools that are addressing this area. And may I remind you to the discussion yesterday where we were pointing out that doing interesting future work probably means we have to create some new tools for enabling the next security steps.
CHAIR: Yeah, but then this discussion should probably be in the routing Working Group. What's your feeling?
AUDIENCE SPEAKER: Rudigar: Well we can take it there, we can take it there. My feeling is that the true routing guys usely to do not really look into that kind of software stuff, but well okay, it's hanging somewhere in between. But the notion that it could be a very good idea to consider what requirements in this area are and how to address them. And well okay, even in that context, to ask whether this may require an effort where the NCC can help in a defined way, could make some sense.
CHAIR: Okay.
AUDIENCE SPEAKER: RIPE NCC is in a way supporting IRRToolSet by promoting the existence of it and increasing the user base in the Routing Registry training courses that we do. So for now this is the main tool that we tell people /P /TP* you want to use the Routing Registry there is our configure and we are aware of the existence of our tools. Often during those training courses we tell people did you ever try using this tool they say yeah, but it didn't work. And then they go to the mailing list and they ask questions, ask for support, sometimes they get it, sometimes they get more or less actively involved.
CHAIR: Okay. Thanks for the feedback.
AUDIENCE SPEAKER: So, correct me if I am wrong, but the most common user for auto set nowadays is to get from something like RPSL language to list of prefixes in order to maintain your route filters and there is an effort undergoing here about certification. Somewhere in the future we will get to the point when there will be only to map prefix to auto number systems basic route object and there will be new way to do so using certificates. And I think there should be some efforts, I don't know by whom, to ensure that when at the purchase point our own tool set asks basically the most widely known tools to generate route filters will support it.
CHAIR: Okay. Thank you. Rudigar.
AUDIENCE SPEAKER: Rudigar. One hint to you, actually for the long transition phase for getting the RPKI based stuff in, it has been observed that well okay, there are very simple and effective ways to make RPKI relevant data directly available within RPSL syntax and even semantics. So that well okay, maintaining and keeping an eye on the RPSL tools is actually a helpful thing there (RPSL) and actually for anybody who is interested for making quick progress in that area (RPSL) of course having a path where the existing tools can be directly used is looking like much more promising than to wait for a yet to be defined native set of tools.
AUDIENCE SPEAKER: Okay. Thank you.
CHAIR: Okay? So I think we collected quite a bit of information and we are being to see sort of where we have to do things in the future and how to do that. /*PL /*PL okay. Thanks for the feedback to everyone.
That takes me to the next and last item input from other Working Groups. We already started to talk about DNS related stuff with the reverse server attribute being phased out. What we learned yesterday or the day before in the first session of the DNS Working Group was that the RIPE NCC is currently updating or working on an update or working on an improvement on the system to automatically generate reverse DNS delegation zones name server configurations and there are a couple of things that are related to that.
For those of you who are not fully included in. This is a machinery that allows us to request reverse delegations by registering a domain object into the RIPE database and then on a regular bases, there is a robot which digests these objects and (/KHR*Ued) and does the right thing, which means that some files are generated from that information, that name server configuration /R‑S automatically generated from that informs. And it also provides for us a single point of requesting reverse delegations even for those address blocks where the next upper layer DNS responsibility is not with the RIPE NCC but for example, with ARIN. And that machinery is going to be updated and I would invite all of you to have a look at your experience with that machinery in the past and if you had any issues with that or if you do think there is room for improvement, then I think it's about the right point in time to provide your feedback. We have asked the RIPE NCC to come forward with a description of what they intend to do and how and what they want to achieve, and I presume that piece of information will be circulated both on the DNS Working Group mailing list and on the database Working Group mailing list and we then have to decide where to have the discussion about those things. Peter?
AUDIENCE SPEAKER: Peter Koch, DE‑NIC, and wearing my DNS Working Group co‑chair hat here. Nothing what you said was wrong. Just let me add one additional perspective here. This is also about the cases where there is a reverse delegation object for a /16 in the database and people can now submit database ‑‑ domain objects for subordinate /24s and they do not receive a warning and nothing, but just their user experience ‑‑ I love this ‑‑ is bad, because of course, when there is a delegation on a /16 boundary already there is no way that the NCC could add the /24 delegation as well because that's, that has been going somewhere else completely and that has confused people. We have been in a situation being responsible for /16 actually my /TPWRAEUTing this out and getting rid of this (migrating) and especially in the transition phase, there was some confusion amongst users and that was what and in the Working Group presented to the Working Group and then propose that had there be a mechanism or some changes and this is an action item in Anand) to phrase this exactly or come up with a proposal that probably, in these cases, the /24 domain objects should just be refused or maybe a warning /PWAU /PW*U that is up for further discussion.
AUDIENCE SPEAKER: And re: I just want the to second what Peter said. That was a very particular point from the RIPE NCC they would like to get some community feedback on.
With regards to changes to our provisioning something, they did at least what we are planning is not as radical as it might sound. Basically we are doing some /KPHRAOEPB up and redesign of internal machinery. While still keeping in mind that our database is the main provisions interface and you probably remember where this idea came from, it came from the fact that scan can clean in the what we thought as a community that databases is a very familiar interface for people to work with update their I N M numb updates and other things. It's logical to extend the database function at to cover reverse DNS provisions. Now, things are changing of course and we might think of different ways of update /TH‑G information. Like EPP, like something different, not just database. But the scope of our activities is basically limited to redesign of internal machinery and also looking at the hardening our DNSSEC provisioning system. That's probably the main focus.
CHAIR: Thanks and re. One of the reasons I brought /TUP here, for example we don't have any means at the moment to tell the machinery from which ‑‑ well assuming the case that the RIPE NCC name server is a /SHRAEUPL for a reverse zone, we don't have any mechanisms right now to tell the machinery from which master to pull the zone from. And sort /TP‑F you are touch that go anyway, it might be an opportunity to think about do we need it? If we don't need it, then we don't have to take it into consideration. If anyone needs that, then it might be the right point in time to speak up up. Because for us it actually happened to us for one of our customers and for the moment the only solution was actually to not have a slave at the RIPE NCC because there is nobody to actually convey the proper configuration information. But that's maybe just an exceptional case.
AUDIENCE SPEAKER: Anand Budhev: I'd just like to clarify something there. It's true that at the moment there is no simple way for an end user to specify which master server to pull the zones from. We have had a couple of requests for this from users and we have made manual edits to our configuration to allow for this. So you know, it's possible, it's not impossible, but it's not easy for us to maintain because it's, you know, manual work and something that could easily be overlooked by an engineer for example. So, yes, we would very much like the community to consider you know, allowing changes to the RIPE database scheme for the main objects to allow this feature.
CHAIR: Okay. Thanks Anand. That's about it I think. If there is no other input to that topic, it gets us to any other business. Is there any other business? Anyone you want to bring up here? No?
So then I think we can close the Working Group session right now being early this time. So you are going to have a longer break.
Thank you. See you next meeting. (Applause) (Coffee break)