These are unedited transcripts and may contain errors.
Notice: Use of undefined constant steno - assumed 'steno' in /var/www/html/ripe-60/steno-transcripts.php on line 24
Database Working Group, Thursday 6th May 2010, 9 a.m..
WILFRIED WOEBER: Let's get started. Good morning folks. My name is Wilifred Woeber. Together with Nigel Titley we have the guide team for this Working Group, database Working Group. Welcome to the early morning session after a long evening session for some of you, I heard.
On the display, you can see the draft agenda, the proposed agenda for today. The most recent version, version 2 was also circulated on the mailing list a couple of days before the start of the RIPE meeting. We do have a rather light agenda this time, so we have got enough spare time to actually have discussions regarding one or the other of these items here. To start with the logistics. As usual the welcome, as usual my thank you to Nigel Titley who is again doing the scribe, and he also will guide us through a review of the open action list.
A little bit of logistics. As by now you will probably know already, this session is webcast, so whenever you move to the microphone to contribute, please state your name and in which capacity you are speaking. There is also an interface to remote participation to Jabber. So if something comes up, we will phase that in during the discussion.
I think that's most of the logistics things. Is there anything you want to add to the proposed agenda or you want to have anything removed? You know there is always the chance to bring up last second things on the Any Other Business. No? Okay, then we'll move from the draft agenda to the you'll agenda to work from.
And the last thing here on the formalities is approval of the minutes from the previous meeting from RIPE 59. The draft minutes were circulated on the mailing list. I presume they are also available on the website, but I am not sure about it. Yeah, Nigel nods. So are there any comments regarding the draft minutes? No?
So, these are approved and are thus final.
Thank you very much.
Then, let us go to the next thing and ask Nigel to briefly walk us through the list of open actions.
NIGEL TITLEY: Right. This is going to be brief, I hope. Let's see if this works.
One second please...
We have a couple of rather ancient actions. One was removal of orphan objects, which dates back from RIPE 54 and one is the check that AS use that can support IPv6 objects. Paul is dealing with these later, so these will be discharged, which is good. The rest of the actions all date from last meeting. And pretty well all of these are going to be dealt with as well. This Working Group meeting. The first one is reverse delegation stave guards to put in to prevent sub delegations. This is being dealt with. 59.2 is to make sure that an announcement goes out forth removal of further unreferenced contact objects. That has definitely happened.
Database documentation in HTML form, that's been done, good.
Key search, this is going to be dealt with later on down in the agenda, because to some extent, it's been made redundant.
Action point 57 .5: I am not going to try to pronounce that surname, is he here? He was going to raise this at this proposal on the database Working Group mailing list. It doesn't appear to have been done but as I say it's largely obsolete now so I suggest we discharge this action point or mark is as superseded.
59.7, RIPE NCC: Again this is superseded because the whole thing is superseded.
And then finally, Wilifred, refer the question of optional MNT Revenue or object person or role objects. Was this done? Or again this is another one that's ??
WILFRIED WOEBER: It was not done. I have to think about it.
NIGEL TITLEY: Right. Okay. Ongoing. Okay. That's it. Thank you very much.
PAUL PALSE: Good morning, I am the manager of the database group and I'll be giving you the RIPE 60 data update.
In the updates I am going to quickly introduce you to the group for those of you who are new and a few slides about projects we run and commitments, one of which is also the action point list a little bit more information about that.
An operational update and I will try and give you a quick demo of the RIPE Labs prototypes that we have published on RIPE Labs. Then we'll have time for questions.
Who is the database group? That's us. And actually we are currently also looking for a new colleague, a database developer.
For some reason there is no animation, but these are the stakeholders. Obviously the RIPE community have the a various Working Group. There is still the data Protection Task Force there but that's been closed in the last meeting, but I haven't been able to update the slide yet. And then the various departments within the RIPE NCC that also ask us to do stuff for them.
So, I'll go to the Action Points. . 54.3. And this is in order of the oldest first. We were asked to make, maintainers mandatory on person /role objects, and we deployed the test environment for it right after the RIPE 59 meeting, and we haven't had any feedback on things breaking from your side until now, and we finished the documentation for it. So, we'll be looking to deploy the production version of that within probably the next month.
We are going to deploy that within a month or so, if we don't get any further negative feedback on the test environment.
Action point 5654.6 which is the clean up of the unreferenced person objects. We actually started running that script again and there is also an action point 59.2 where we were asked to do a little bit more of explaining of how that thing actually (54.6) works which we have done, and somewhere in February I think the cleanup was completely done. But we did increase the time before un?referenced objects gets deleteed to about 90 days and this was requested by registration services because sometimes they felt 30 days time slot was a little bit tight.
Then we have 58.1, the AS used support for IPv6. I have actually looked into this because last meeting this dropped off the action points list, but it will be dealt with in the new LIR portal and then they will ?? we will also add IPv6 support for that tool. Currently it's only available via web form.
59.1, which is adding some delegations safeguards to the database software. And currently the DNS Working Group is working on upgrading their provisioning software and as soon as they are done with that, we will pick up this project and will make the necessary changes to the RIPE software ?? RIPE database software.
WILFRIED WOEBER: Just as we read into this a couple of days ago, just to make you aware, all of us, that if these super flus and sort of irrelevant objects happen to be in the database already right now, they are, for the moment, going to remain in the database and sort of as soon as this new environment will be in place, we will, I guess we will, together, try to find out how to clean up the historical mess. But for the moment, if you end up with those objects, you have to try to clean that up on your own. And the interesting thing is that not as a criticism, but just as a fact, that if someone actually put in those silly objects which don't have any operational relevance under their own maintain err, then the holder of these, for example, /16 delegation at the moment doesn't have any means automatically to get rid of that craft, and the way to deal with it at the moment is to ask the friendly RIPE DB M human interface to help with the clean up. Okay. Thank you.
PAUL PALSE: Thank you. So, this was the cleanup of the unreferenced person objects that I talked about a little bit earlier and that's all all done.
Shane Kerr asked us last time to provide or document in HTML, which we have done for the update reference manual and as soon as we also updated our query reference manual, we will also provide is in the form of HTML.
This week Nigel already spoke about, and what we felt is maybe this, we could deal with this, with it possibly with this item as a use case search tool, which I will explain to you a little bit later on in this presentation.
Now we have some various updates. NIC H D Ls were a personal data which we were asked to move from split files and RT M and we have done all the code changes for it. We are currently finishing the documentation for it and the test environment has been up and running for quite a while now. And again, here, we will, if we don't get any negative feedback from now on, between now and approximately a month, we'll be deploying this into a live production environment as well.
The ongoing story about our mirrored data. Again, after RIPE 59, we reloaded all the mirrors that we were out of sync with and we recognised that slowly on during, from RIPE 59 until now, we have slowly got an gotten out of sync again, which now needs a little bit more than just a reloading and we need to actually spend sometime to see, relax maybe some of the impart rules that we have set for the data to make sure we actually do not got get out of sync with this mirrored data.
Now for some operational updates. This is where I normally, and I will this time. Introduce the customer service department. They are actually handling our first line support and whenever there is anything that they feel needs to be escalated to us, they will do so.
And they do an excellent job with that, and we also like to show you some stats on the amount of tickets that they handle per month in the different categories. If you are interested, you can have a look at the presentation up there to see some of the detailed figures.
And then we also have some statistics on the use of the RIPE database. Queries: We have ?? so, I normally ?? this is over a whole year we have an average of 8 and a half thousand, a little bit more, queries per minute on the RIPE database. And this time, over this period, about 1.5% was over IPv6.
And then some statistics on the division between which countries query our database most often, and this is always a little bit of ?? stays relatively the same.
And then the amount of queries each individual IP or client makes, and we find that it's relatively ad hoc queries for host of them, so between 1 and 10 queries for 80% of the queries are just 1 to 10 over the period between two RIPE meetings.
Updates:
Also, just, going on stable 36 per minute in average, and some peaks were, sometimes we run some scripts or maybe some of our LIRs run some scripts against database and do some cleanup or to do mass changes and that's where these peaks come from.
Where do the updates ?? how are the updates committed to the database? Well, most of them are using sync, which is a little tool ?? which is used internally by us as well, and which can be used by script etc.. it's a place where you can post your objects and commit them. Still 30% also uses e?mail, and only 4% comes from the web form that we host. And then something about the success rate of updates. We still get quite a bit of spam, and I just want to explain the high failure rate in this particular case, which is 41%.
Sometimes people commit several objects in an e?mail message and then if any of these objects fail to update, then that's counted as a failed update, even though it may be most of them succeed. And also we found that there is scripts out there that don't actually do any error checking, so in one particular case, we found that there was a script committing about 100,000 updates every five minutes which also accounts for the high figure, so maybe if there is ?? I mean any of you may be running scripts but doing a check on the RIPE database to see if a certain object exists and then if it doesn't exist, recommits it and if then there is no error checking, then obviously we get these kinds of ongoing failed messages.
Something we call Ego Query, this comes a little bit from the ARIN presentation also. When I heard that we also did some research and we also found that. The RIPE database has queried very often for the host, for the host's own IP address and we actually name those ego queries. It's about 13 million individual IP addresses doing a massive amount of queries, and I have also split them down a little bit in the top countries where these queries come from, and they are not, let's say, frequent, highly frequent queries but, you know, it's still 80% is does sporadic query and we have no clue what it is either. We looked at query flags or anything that could identify these, and nothing there. So, if anyone knows what it is, I think there is a few people that would really like to know this.
And then our up time, which we are very proud of. There was a huge dip we had to present during the last meeting, and this time we are nearly 100% up with all the services that we provide.
So, now we get to the prototypes that the database team has published on RIPE Labs. Just a very quick run through the choices we made for the technology. We also ?? we know about ARIN providing their services over restful interfaces, and we, too, made a choice to use rest for our web services, which has quite a few advantages. It's widely supported by the other big parties. It's relatively ?? the beauty of it ?? actually, it came from the idea of creating a kind of a scriptable API for the RIPE, for the query part of the RIPE database currently, so it's quite nice that this all runs over port 80, so you don't have to configure anything exotic to get access to it. And in this way, each object in the RIPE database now has a URL pointing to it and the service response in XML and J S O N, and we actually took RPSL as the basis and transformed ?? we actually didn't do an awful lot on trying to find a particular XML schema that would cover all our use cases, we just actually mapped RPSL one on one to XML and this way it's very easy using any templating language or script to transform the XML output back into RPSL if you wanted to.
So now, I am going to actually give you a quick demo of the search form. So, we currently have two methods of searching the database via the service, is a search and a book up. The lookup just points you to a single object and the search is just actually covers, let's say, 99% of all the use cases that are current port 43 search covers. And actually, a few additional features as well. So, with every service, we also released a search ?? a client that actually shows you how you could use the service.
So, this is the search form and currently we also proxy APNIC and AfriNIC, so what you see ?? when you use these ?? if you tick these boxes what happens is, in the same way, we use proxying ourselves to search the RIPE database, we do the same for APNIC and AfriNIC, because their output is very similar to the RIPE database output. And then obviously you have all the possibilities of setting query flags and inverse lookup attributes.
So, I am just going to go for 193 /8. Let's see what these three RIRs know about this. And here is the response. We see that we have a response from APNIC. Some data. AfriNIC. And RIPE. And these are all primary keys that point to the lookup service. So, this is actually what the client shows you. This is HTML. If you want to see what's the actual, the original query response was, you can click this XML button, or if you wanted to look at the J S O N version of it. And this is the XML that we output. And there is some additional information in the XML that you normally do not get when you use the regular WHOIS port 43 client is that every primary key has actually a link to the lookup service for that particular object, so it allows you to sort of jump around and get objects back from the lookup service.
So, let me just quickly show you, you know, if I wanted to know what this maintain err ?? I can just keep on clicking around, look at the XML for it. And that's basically what this service is about. Have a go at it if you like to, and we really like to get your feedback also, so if you have any feature request, find any bugs or anything, there is a forum on RIPE Labs that you can use to give us feedback as well.
Let's go back to the presentation.
I actually prepared a screen capture in case this all failed. So...
When we were building these, this API we actually also in the background did a little bit of filtering so you only get the unique results out, etc., etc.. so at some point we came up with the idea that if we are doing this kind of logic in the background, well before we actually pass out the output, we may as well add some additional business logic, if you would like to call that way, or do a little bit of data mining in the background before we actually output and the idea came about to publish something we call "Use case searches" and this basically is a service that answers a specific question with a detailed answer and the first service we published that uses this, where we use this "Use case" search phrase is the abuse finder, which I will give a demo about in the anti?abuse Working Group, later on today, so if you have interested, come by and have a look at that. Obviously it's also available on on RIPE Labs as we speak.
Last but not least, there is something that we have been thinking about in the database group quite a lot and within the RIPE NCC this is also an important drive that the quality of registration data, and of course also the RIPE database contains a lot of registry data. So we would like to pass by you a problem statement and some principles that we want to stick to thinking about possible solutions, and we would really like to get some of your feedback on that.
So, what is the Problem Statement? . As a registrar it's important that we keep accurate registration data, or registry data. And in that way we can make sure that the users of that data have trust in it. But, we really do not have a lot of control and we shouldn't probably over what users commit as data to the RIPE database, and if anyone queries the RIPE database and gets data back that looks inaccurate or there is differences between several ?? between data, it's perceived to be low quality and therefore, the whole data set has a kind of a bad, a kind of bad commendation. So what we are looking for is to actually try and look, if he could present a clear distinction between user data and registry data, the data that the RIPE NCC maintains, and do that to minimise inconsistencies and not breaking anything that we currently support. So it should still be possible to for users to store their data in the RIPE database in the same way as it's possible now, but it's just clear who maintains what set of data. And do that in a way that has a minimal impact on the current software as well. So it shouldn't be a huge new rebuild of a huge new flashy system, but rather be, yeah, maybe some small visual changes or anything that has a low impact on the way the current software works. And we'd love to hear from you and to give us maybe a little bit of direction or if this is a good way of thinking or, you know, anything.
And that actually concludes my presentation. And questions anyone?
I think it's time to say thank you.
(Applause)
WILFRIED WOEBER: First of all, thanks, Paul for the very concise and broad presentation, because we already covered the next agenda item by this restful services and a couple of things regarding the abuse management, abuse finder thingey. I'd like to reinforce what you have said regarding the start of this thinking process, like what's the real issues with credibility, data quality and presentation of data, which is in the RIPE database.
So first of all, anyone who is interested in this broader topic, just keep it under survey and we will probably see something coming up on the database Working Group mailing list. We may see something coming up on labs, and unless you correct me, I think this is the point in time, if you have accumulated some thoughts over the last couple of years, like this would really be nice to have something, or this would really be to have some information presented in a different makeup, in a different fashion, sort of this is the point in time to let the RIPE NCC know as input directly into the database group at the RIPE NCC or let us all know about your ideas on the database Working Group mailing list. There are probably going to be a couple of sort of hallway discussions, people throwing back and forth their ideas or their expectations, so please feel free, please feel invited to get in touch and to participate in that think. Okay.
Anyone having something sort of POP up in their heads right out of the blue? Out of the headache? No? Yes. Okay.
AUDIENCE SPEAKER: Good morning, Richard Cox, chair of Anti?Abuse. First of all we obviously warmly welcome the last part of your presentation. The recognition that we have got a problem is I think fundamental to fixing it. What I wanted to ask at this juncture, because I think we have got to start getting some of the definitions right is: What question are we answers when we answer a WHOIS query and what question is the query remember really wanting us to answer? Now, to my mind, what we are answering is: What have we been told to put here. What the requester quite frequently wants to know is to whom did RIPE allocate this IP range? The fact that these differ so significantly is, I think, part of the seat of the problem. How can we realistically solve that? I mean I have got several other key issues, but I don't think this is the place to raise them, unless others disagree. I think the discussion needs to go forward a little bit before we get to that. Could I ask for some thought on this question: What question are we answering and what question is being asked?
PAUL PALSE: In respect to the abuse finder service or in general? I am sorry...
AUDIENCE SPEAKER: In terms of the information we are providing about a resource. If we send a WHOIS query to the RIPE database, eye assuming port 43, that, what that data is telling the person asking the question.
PAUL PALSE: Well, let's say for ?? I mean, there is ?? there are objects where there is a joint responsibility between the RIPE NCC maintains part of the response and there is user data in the same response and I mean, one of the things that we have identified, it's to the user it's sometimes not clear where to extract the, who is authoritative for which part of the response and so if you are querying the RIPE database for who holds this resource, then you sometimes get responses back that could have conflicting information in there, so...
AUDIENCE SPEAKER: Yes, but I am differentiating here and it may sound a subtle point but if you analyse it, it isn't, it's a fundamental one. The difference between who holds this and tomorrow whom was it given.
WILFRIED WOEBER: Well, let me try to rephrase that just to check whether I understand your point. I think we are talking, we are talking different things here. Like, looking at the IP address space, we are having sort of different sub sets of that space for which the RIPE NCC has different levels of control and quality assurance machinery, let's put it that way. Like, if it was a PI address block that was given away within the last two or three years, then I presume the RIPE NCC has very good mechanisms and very good means and very good data available to sort of, to prove that the thing which is in an answer and the thing which is, which has been told to the RIPE NCC is matching, because there is this contractual relationship, there is mechanisms to actually double check that the organisation does exist. So, I think there should be a pretty good match and there is other areas where the RIPE NCC would only have either course grained, which can be sort of quality stamped, that probably applies to PA space because there is a contractual relationship, a service contract between the local registry and the RIPE NCC. So, the identity can be verified in both directionings, but then it becomes the responsibility of the local registry further distributing address space down to their clients, customers, users, whatever, sort of to make sure that this piece of information is properly maintained.
Again, I think this is part of the standard service contract which actually requires the local registry to sort of to work on this and to sort of to be aware of it and to be responsible for that. And then we have the third one, which is the legacy address space where we are probably going to see some policy proposals POP up within the next half a year or year maybe to get a hold of that. Is that the thing you are referring to?
AUDIENCE SPEAKER: Not quite. But, it's important. So, I am glad you mentioned it. What I am talking about is where an IP resource is applied for, usually by an LIR, and the data that goes in the database has got absolutely no relation to the actual user. And yes, there are contractual obligations on the LIRs, and yes, a very small number, a very small number of those LIRs are having scant regard for their contractual obligations to the community. Unfortunately, that very small number of LIRs can have a very big impact on the the credibility of data from the RIPE WHOIS and that bothers me. We need to fix that.
WILFRIED WOEBER: Okay. Point taken. Okay. Thank you. You want to add anything to that?
PAUL PALSE: No. Thank you.
WILFRIED WOEBER: So, again, Paul thanks for this presentation.
(Applause)
WILFRIED WOEBER: We are probably going to see some more discussion in the vicinity of this problem space in the Anti?Abuse Working Group later today. So we have covered the item C and D. I had this thing like abuse, abuse, identification, abuse finding, abuse contact thing as a separate agenda item. From my point of view we covered mostly all of that. The primary reason to have it on this Working Group's agenda is to make everyone of you aware that in anti?abuse, there is going to be further discussion regarding how to get a handle on finding out who is the point, who is the organisation, who is the individual to talk to if you think something is going wrong.
So, I presume we are more or less, today, done with the formal agenda items that were proposed. There is one thing which is still on the agenda, and that's input from other Working Groups, and there is one thing for which ** Iga Showouw is going to give a little bit of background and that's the ping contact.
AUDIENCE SPEAKER: There was discussion yesterday after a short presentation from the RIPE NCC on Internet draft that's circulating now suggesting the introduction of another element for some R B S objects, mainly the ping ?? C. So the objectives of this new item would be for any user with machines within a given address block or possibly even AS number or a route object to be able to put their register there either an v4 or v6 address that other people can use as a target for pings and therefore aid them in debugging any network issues that were. There were a pole in the room about how many people would use this feature if this was available and there was a large number of people, like half, which was an unusually strong response for a meeting like this, saying they would in fact use it.
Now, I'd like to propose this group that the upshot of this is considered. I don't have any particular indication of whether we need to actually wait for any extension to RPSL to be properly documented through ITF standards to go ahead and do it. I mean, in the past, the RIPE has taken its own modifications when it has been seen as useful from the response that we saw yesterday, this is considered to be useful, so we could just choose to do this thing on our own. The complexity doesn't seem to be a lot, because it's not ?? this field doesn't seem to have any internal structure like other RPSL help fields have, and it's just one item on our ?? there might be considerations that you want to think about like at the time of registration, would it be useful to add checks that would, for instance, make the database update server ping the address that been put this to check did that user make any ?? well, it's two attributes. We can read the details in the proposal.
So, there needs to be a little bit of thought about what other mechanisms you put in place to support this functionality, and that's it basically. You could consider that for the RIPE database.
WILFRIED WOEBER: Thanks for this input. Taking off the hat for the Working Group Chair here, just as one of the guys who are involved in debugging network problems in particular with IPv6, as you can imagine, I think it's basically a very good idea and would I rather see it yesterday than tomorrow. The thoughts behind it is there a strong feeling that this draft is very stable already and are the people more interested in getting this particular, as I would term it, subset of functionality implemented as soon as possible, or is there still room for sort of discussing the, discussing the mechanisms or discussing the idea, because ping is definitely one of the most popular debugging tools around, but in particular, with IPv6 there are a couple of other things in the vicinity of doing a simple ping which might be interesting, so I am thinking about facilities like doing P M duty and similar stuff. I had private chats, that's also just a heads up, I had private chats with some folks from the RIPE NCC during this week about ideas in general how to maybe support debugging of IPv6 related problems and how to potentially integrate those things into some sort of bigger scheme. So I would be very much interested in following up on that one. So is there still room to ??
AUDIENCE SPEAKER: There is plenty of room. I think as far as I understand it, it's an Internet draft, not an RFC, so that means anyone can discuss anything they feel like. The way this came up was at the, because some people recollect the author and the other people got together after one of these sessions of trying to track down something that didn't work and of course, it's like, wouldn't it be nice if we had this other feature. So I don't think it's yet ascribed to any Working Group, for instance, not that it needs to be, but maybe the author will join. So yes, it's totally open and I encourage both the Working Group participants and the RIPE NCC itself who eventually would be the people who implement it to think a little bit how you'd envision this and give the feedback back to the author. What considerations would you like, what things you might think that have not been said already and are not reflected in the draft that could add value to this, and just consider a little bit of the implications. It's definitely a good time to comment and add to it.
WILFRIED WOEBER: Because one of the things I would immediately start thinking about is to not only doing ping on the regular ping part, but for example giving more indication like what's the like low interaction honey pot technology or terminologies like sort of what port should actually answers on that address, because ping is one thing, but there are a couple of others things like if the ping is actually blocked or the firewall, or the other way around ??
AUDIENCE SPEAKER: There is plenty of other things that could be done. On the other hand, there is always a danger that whenever we engage in engineering mode, we might end up over engineering and it might be worth doing a simple thing first and then build upon it if it's felt necessary.
WILFRIED WOEBER: That was the reason why I was asking is there really sort of the interest in having something very down?to?earth but getting it tomorrow rather than doing something, but maybe we could sort of engage with the RIPE NCC and try to find out what we can do on short notice. Maybe even as a blueprinting and prototyping and then feed the experience back in the RFC process, maybe.
Could I have a brief show of hands, who is aware of this ping thingy or testing thingy? I am since yesterday, more or less. Okay. Interest in general? I mean it's not our job sort of to assess the validity of a proposal from a different Working Group, I'd like to make that upfront.
Okay. Thank. And with regard to the RPSL sort of to the more logistics things, like, extending RPSL by way of a side door, who is aware of the set of RFCs covering RPSL in general? Okay. Thank you. Because RPSL is pretty dated by now, sort of the set of RFCs describing the whole RPSL system and what I found out a while ago is that not only the RFCs might benefit from a brush up, but the whole environment around the RFCs, like help pages, use cases, descriptions of how to use it, that's more outdated and if anyone wants to get their fingers well with RPSL without knowing the history, they are probably more distracted by those pieces of information than getting help.
AUDIENCE SPEAKER (Joel): True. But just so that no one gets too scared about this stuff. This proposal has been labelled RPSL because outside the RIPE region, that's the framework people think about then things look like the output of the RIPE database, but this doesn't actually impact on the policy specification so you don't have to go and try to understand the complicated language that's available on the RPSL. It's more like a traditional RIPE database type of...
WILFRIED WOEBER: So what's sort of the proposal from your end? Should we just register an action item and if yes, with whom?
SPEAKER: Well I'd like to ask the RIPE NCC to think a little bit about how they would go about implementing this and what other easily ?? if things could be added easy that could provide free of value like checks at registration time without complicating things too much. And just issue a recommendation, how they see this stuff. And then we take it from there, we talk to the other people, the author of the draft and we see what the next step is after we all know a little bit better what with we are talking about.
WILFRIED WOEBER: Still the owner is routing Working Group and we are still trying to find out what we can do to IPv4 it.
SPEAKER: As you wish, we can spare it if you chose.
WILFRIED WOEBER: We'll sort that. Okay. Thank you Joel. Denis?
AUDIENCE SPEAKER: Denis Walker, RIPE NCC. Add in optional attributes to objects is a fairly simple exercise for us, so we could easily knock up a test server with these for you to have a play around with. My one question initially would be: I believe, although I wasn't in the meeting yesterday, there was some discussion about which object you would want it in, route or 6 INET NUM or AUT NUM ?? we could usely add it to all of those objects if that would suit you.
As for RPSL itself in, RIPE, APNIC, and AfriNIC all implement roughly an RPSL database but none of us stick stick strictly to the original definition of RPSL. There are many attributes and objects in the databases now which don't really exist in the original definition. So, I think as Joe he will said, it's kind of RPL?ish, so anything that looks like that is now considered to be RPSL. So if you wanted to do this, these new ping and pinc?C attributes on a test database, we can very easily knock that out for you very quickly.
WILFRIED WOEBER: Okay. So then, first of all, thanks for the offer to sort of to try to do something on short notice. And I guess we collaborate with routing and in between now and Rome, I hope we can get something either as a proposal or as a sort of test implementation or something to be test written on labs or whatever it is. Okay. Thank you Joel. Any other input from other Working Groups? Or any other business? Any comments? Sort of open microphone...
No? Then I presume we are ?? I'll double check with the agenda ?? I think we have covered all of the items.
So, we finish early. You get a longer break. Thanks for being here. And thanks for the inputs and participation. And see you next time in Rome and see you in between on the mailing lists and have a look at the stuff that's either already on RIPE Labs or might become available between now and autumn this year. Thanks very much. See you next time.
(Applause)
(Coffee break)
LIVE CAPTIONING BY MARY McKEON RPR
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE