These are unedited transcripts and may contain errors.
Database session on Wednesday, 26th of September, 2012, at 9 a.m.:
WILFRIED WOEBER: Hello, folks. Good morning, welcome to the meeting of the for those newcomers amongst you my name is Wilfried Woeber, I am employed at /SREPB enin a ?? one of the co?chairs, Nigel Titley, is going afterwards to go through the action list. On the screen here, as well as on the website, you can see the draft agenda, the most recent version, version 3 I did yesterday, because we had one or two minor additions, so going through the admin ?? is there anything in the draft agenda that you want to see changed, any additions, anything to remove, no? OK, then sort of this is the agenda we are having to work from. Just be aware that the session is recorded and it is distributed on the web, so please feel free to ?? so please feel free that more or less any time during the presentations or between a move up to the microphones and please state your name and your affiliation. For those of you who are still able to read instead of watching YouTube, there are the instructions next to the microphones how to do that. And I would also express my gratitude to Nigel, who is, again, sort of as a customary service, by now even taking the notes, which gets me to the slightly embarrassing issue for this time to the minutes because they were ready right after the previous meeting but for one reason or another they didn't go out to the mailing list, so they were distributed one or two days ago, and due to that fact, I will not ask you whether there are any changes to the minutes but we will allow for another two weeks to collect comments on the mailing list and if we do not see any comments, any requests for amendments, we will declare the minutes as final from the previous meeting. Sorry for that. It was an oversight amongst the Chair collective here.
And this gets me to the action list, and I'd ask Nigel to briefly walk us through the action list and then we immediately after that one, we move on to the report, the database report by the RIPE NCC presented by Kaveh. So enjoy, this is a Working Group meeting so we expect to you participate and not just to listen, make round shoulders and wait till it's over, thank you.
NIGEL TITLEY: We have actually got a very few outstanding minutes, which is rather good. Here is the first one. This is on Wilfried and it's actually covered under section D of the agenda, so I won't propose to go through it now. And this is the other action point, which dates back to RIPE 63. This was raised by David Freedman. Is David actually here? No. OK. This relates to the fact that if you want to delete an autonomous ?? an ought num object, you are not allowed to do so if it's referred to by a root object or various other things as well, and Dave was asking whether or not it's possible to reverse lookup and find out what is ?? what objects are referring to an ought num object so that you can delete it because sometimes it can be difficult. Dave was going to send a note out to the mailing list to find out whether other folk thought this would be a useful facility, as far as we can tell he hasn't done so and he hasn't turned up at the Database Working Group meetings for a couple of meetings now. My proposal is that there is obviously not a great deal of demand for this and that we just expire this action, and is everybody in agreement with that? OK. Good. In which case, we will expire this action and I think that is it. That's all we had on actions. I will pass you back to Wilfried.
WILFRIED WOEBER: Thank you. Thank you very much. And Kaveh, may I ask you to get on the stage and give the database update presentation. Thank you.
KAVEH RANJBAR: So good morning. My name is Kaveh Ranjbar and I am manager of RIPE NCC database department. In this presentation, I will provide a quick update between what we did on RIPE 64 and this RIPE meeting as well as an outlook on your major focus areas in the coming months.
So, as usual, we have operational stats available on the mentioned URL. There was no major change in the trend of database usage. We still serve about half a billion queries per month and we are also, the average per minute is 14,000 queries and it peaks at 26,000. The opt time for the queries was as usual very close to 100 percent and we had no major incidents but for the updates, there was one incident about two months ago for four hours one of the update servers was down, which caused interruption; it was on a Saturday morning. Unfortunately, all software for the updates doesn't support redundancy or any kind of fail?over so we had to do manual fail?over but the good news is as I will mention later on, we are redoing the software and the new one will support redundancy.
So, on up times, on the last meeting Nick Hilliard brought up the correct point that the stats we provide are only local because we are monitoring our services within the same network that the services provided there is no reachability stats there. We promised to look into some possibilities to also include that and we did that. I won't go through the details but the main thing is we found Atlas to be actually really, really useful in that area. We new Atlas is a good service and I am not promoting but from an operational point of view we looked into monitoring or servicing with RIPE Atlas we found out there is actually no competition for Atlas in that area, it's a unique service. Not only because of the distribution and proper support for v6 monitoring but actually for the way they can ago grate the data and the results for us so in the next RIPE meeting I will provide the reachability stats through RIPE Atlas.
One other thing, but I think that will be discussed under item E; this is mainly ?? there were some changes and improvements to the way we communicate issues to the community. We always try to be transparent but there were some communications, so what ?? with committee, so what we did, we have changed our policy. Anything that happens at RIPE database as soon as the user reports a bug or we find something by our monitoring system, we put it on the service announcement, no matter how small the issue is, even if it only affects one user and everything is archived there so we always announce everything on the web page. Obviously, we don't want to spam the use, so only issues that we see have possible impact on the users, we will send them as usual to the Database Working Group and NCC announce.
Another thing, RIPE database documentation, it will be completely revised after the redevelopment project. I just wanted to reassure you, because at the moment, like for some new features or test features, for example, the geolocation the documentation is scattered in two or three places. We are aware of that, but consciously we decided not work on the it at the moment because it is evolving and change because it is one of our first priorities after redevelopment is finished, we will work on documentation. We had added version numbers to the query platform so whenever you query for an object, you see which version of the software as well as which host has it, so there is already in production. We are doing it up for ?? for the updates. We are working on the communication department has helped us with web platform is the public change log will be up very shortly, so any change to any version of the software, as soon as we deploy a new version we publish all the changes, even if it's the same behaviour, we say OK we are replicating the same behaviour but with new software in the change log. If they see any difference in the results they get they can see if it was related to a change we did for it's a bug.
Let let's move on to developments. Our main focus on developing new Whois back end software. All the queries to the RIPE database are handled by the new software and the old is completely decommissioned, so the ?? we don't have any trace of old software in the query any more. And it has helped us a lot to deploy fault and easy to maintain system.
There are a lot of benefits, I won't bore with and you you with all the small details, but one of the important ones is that it is a very fast and system so, for queries and things response times are improved. But it's also simpler, has a smaller footprint and has lot ?? is a lot more flexible. Just to give you an example, for some change we had to do, it took us about a week in the legacy software to implement a feature, the same feature it took us about three engineer hours on the new software and this is from design, implement, implementation testing and deployment. We are also planning to provide a code to other RIRs, what we have done is that for APNIC and AfriNIC it will be just a drop down ?? drop and change so they can just run the new one. We are planning to make it open source but when the coding is complete, which should happen in about six months, and we are also in talks with APNIC to possibly combine efforts to provide services so they write some of the features for us as well, so it's shared evidence effort.
Just to give you one example, in the old system, whenever we had ?? whenever we had an update and this is still the old update system so it's a manual fail?over, whenever we had an update, the software writes the object to the database and then the database, the NRTM software sees the change, sends it through our local version of NRTM to the internal software, the database and also sinks the query in memory trees and all of that. This has worked for ten years, if something goes wrong you need a lot of knowledge to replace or fix one of these nodes because there is a lot of software involved and it's also slower because there is a lot of processing involved.
In the new structure we used standard replication, the software is smart enough to update itself as soon as the database is updated, this gives us a lot of maintenance advantage because what we get here, any who knows how replication works can add a new node or fix a broken node so this gives us advantage in opex and things like that.
So, at the moment, we are working on the up dates, the I/O is already complete; by that I mean the inward and output methods for the update software and which is basically mail and syncupdates because all API goes through sync updates. What we have done, we have reimplemented mail update completely so it is actually now built on top of the sync updates and we also have reimplemented the sync updates, they are live on the test database. The sync update part will be live very shortly and at the moment we are tackling with objects one by one, object types, so the maintainer is done. When you send an update for a maintainer, no piece of the old software is involved in process and it's all done with the new software. And role and person are complete. We are testing ?? testing them, we are also at the moment working on organisation object. We are planning to implement all object types by the next RIPE meeting, so hopefully next RIPE meeting I can announce that we have finished implementing all object types in the updates.
So, again, wave lot of benefits as well as being redundant, the code is much cleaner code, it's easier to understand but the one I am really excited about is we have specific modules for specific work domains. Authentication, syntax checking and business rules etc., when committee comes up with a new feature or new policy, let's say the abuse policy, we know exactly where to go and fix, unlike the current software. For example, we go to the business rules, and implement all the rules proposed by the policy and then when we come pile, there are thousands of tests rub and we make sure nothing is broken, it doesn't affect other things and we can quickly also deploy that to production, so this will reduce our time to implement policies a lot.
At least from the technical point of view.
OK, so some of our longer term plans:
Let me present you with an idea to improve the organisation structure we have. In this three slides, I am using one specific implementation but the idea is not about implementation, I am already aware of three other possible implementations for this specific solution ?? this specific idea, but I am using one just to explain the idea. So think of a new object type, for example, let's call it resource org or any type, this type will be maintained by NCC and it will be by users partially, I will explain why later. What we will do, we will migrate all the existing objects, organisational objects with type LIR these are ones who have a contract with us to this new object type and all the organisations that have resources through one of our members we will migrate them to this type because we have a contract with a member and we have seen a contract because of 2007?01 with a member and their user. So this will be the first part.
The second part, we hope that there will be a policy that says any resource that is or will be given out by RIPE NCC should have a reference to one of these new organisation objects. So this is a visualisation. In the current structure, especially for assignments like AS numbers or PI, it's not mandatory, in this example there is no reference and this is autnum object. For user to find responsible organisation for this autnum there is no investigative or guesswork is involved because there is almost no direct link to this work and even if there is an org line it's not validated, so it might be pointing to incorrect organisation. With this idea or solution, it will ?? because autnum is always given by out RIPE NCC it will be mandatory to have this resource org, so it will be much easier to follow the chain. To give you another example: Think about PI, in PI we have the same situation. As a policy or a registration services department puts the legal name of the organisation in the description field, and then they monitor the changes because the object is owned by the user, it's their maintainer on the object, so if they change the description line, which is the legal organisation name, the registration services are notified, they come back to the user with an e?mail telling them you have changed this, please don't change it, we have reverted the change, which is obviously not a good solution.
If we go through with this idea, first of all obviously it will give proper reference to an organisation for all assignments. It will also add clarity on the users because RIPE database is very big data store but part of it, a subset it, is RIPE NCC's registration data and what we will get with this solution is that it will add a lot of clarity on the queries, because when a user queries for resource we will show them the usual data but we can tell them among this data this is the resource that's given out by RIPE NCC and this is the organisational object that RIPE NCC knows as responsible for this resource, so we can clearly show this to entities because at the registry level we only deal with resources, INET num, INET 6 num and the organisations, we don't deal with route objects at registry level.
It will also remove dependency on the description field. It will solve issues with a naming because as I said, our registration services puts the legal name on the description field, which for trademark holders sometimes is not the best idea because they have to put the full legal name, they cannot use a trademark for sole traders they have to put the person's name into the description field and sometimes there are multiple names so they have to list all of them in object. And it will obviously pave the way for peer resourcement management as well as NCC and user quality audits, I think today in the Services Working Group you will hear about proposal for audits, and this will also help to facilitate that a lot easier. I won't get into details but this is just an overview of the benefits.
Another thing we want to do is to initiate a data clean?up campaign. The main problem we spotted is that everybody knows there is a lot of stale data and there is a lot of broken syntax checks and business rules, what we want do to do, after we are finished with the updates, or implementing the updates, we will start picking object types, one by one, let's say for example maintainer, and then we want to come up with a process with the community so we will propose, for example, five changes to syntax to maintainer, ten changes to business rules and some proposal for cleaning stale data, and in this process with the community, say 15 comes up with yes or no for each item and after that we will also have 15 days to implement that and notify any maintainers if required.
So there will be a preset time frame and we want to go through all the object types to make sure we cover the whole database. There is a lot of examples to save time I won't get into details, just one of them, autnum in my personal opinion is the worst object we have because it has registry data combined with the routing, you might get two meg bites blob of text, if you are only interested in registry data you have to navigate through all of the routing data to find who is the admin contact for that autnum. We have solution in mind which will be backward compatable but we will separate that. This is one example we will propose to the community when we pick up the autnum. And when each ?? when we have gone through each object type we will initiate another effort to look into the overall relation between the objects because there is a lot of internal connections between the objects or global attributes like changed lines and things like that.
We also want to send a proposal to community about the aunt enterication and we will do that shortly. The main idea is we want to integrate the RIPE database with RIPE access. It will be definitely backward?compatible but the main thing here is it's a little bit weird, at the moment you have to go to portal to edit your allocations and go to the web updates to edit your assignments, for example. We want to integrate all of that. It will also add a lot of flexibility and accountability, which we don't have at the moment because the maintainers, they are kind of broken model, the maintainer don't model anything in reality, in real life, it's not a person or a department, it's not an organisation, neither a rule, so it's really hard to have a connectivity in action in logs and things like that. There is also problems with multi?layer authorisation. We have the hierarchical authorisation at the moment with maintainers but it's not possible to have role?based so it's not only about resources but also about responsibilities which we can introduce in this new scheme.
Another thing we would like to do is to develop some modern client tools and when I say "develop" I don't meaning writing the client tools specifically, we might have to do that as well but there are a lot of things we can help the community with; for example, the the IR toolset. Now, with the new software, we have gained the control back of the data so we have full control over the data. I was looking into the IR toolset for a simple thing it has to do three queries because just because the basic infrastructure is not in the existing query system. And a normal run will end, it depends but 3,000 to 100,000 queries to our servers. We can actually provide a single query or 10 years to give all the data that IR tool sets needs, is just communication with the developers and see what they want and provide them with options to give them exactly what they want in a single query.
With the help of Mr. Alex Band we have a developer area at the moment on the RIPE website. It's in the URL mentioned here. And it's very interesting because it has a list of all the APs provided by the RIPE NCC, including RIPE database, portal, RIPE stat, and IP analyser and there is a lot of possibilities to connect this data and get very interesting results.
And my last slide. For geolocation, I know there is an item and the Working Group Chairs told us to provide some stats on that. A quick background: As we discussed with the community, the decision was to implement the bear bone and core functionality to RIPE database, we never advertised it, that was the idea, let's implement it in a better and only the core functionality and that's done. There is a lot of possibilities to promote this and improve the coverage; for example, at the moment it's not in the request forms or LIR Portal, it's almost not visible anywhere except one e?mail that Alex sent to the mailing list about RIPE 64's time, that's all the promotion the service got. And with that, out of 3.6 million IPv4 objects we have 366 with geolocation attribute and 174 used the language field and out of 105,000 IPv6 objects 5 have geolocation and eleven have the language fields, just to give you, but this is only based on the one e?mail sent to the Database Working Group mailing list. So now I will give you Mr. Denis Walker who will walk you through GS slides we have for the action points.
DENIS WALKER: The bis analyst for the database group, I will go through the action point, there weren't many from the last RIPE meeting, and we have actually completed them all. We are getting a lot better now at getting the action points finished fairly soon after the RIPE meeting and there is more the code base improves in quality and flexibility we will be able to do it even faster.
Right. There was a follow?up from the long?standing project we did to remove forward domain objects from the RIPE database. After we had done that, we realised there were a number of attributes in the domain object which no longer had any function. That was particularly the sub?dom, dom?net and the refer, and also because we no longer have any hierarchies in the reverse domain objects because if one already exists you are not allowed to create one that's more or less specific than it so there is no need to have the maintain law either. So we have actually now removed these and they are no longer part of the syntax of the domain object; you can't submit any object to the database with these attributes in it, and we have also now cleaned up all the existing data to remove these objects, there was about 40?odd thousand objects that had reference to these attributes, that has all been cleaned up now.
There is also a proposal which was put to the DNS Working Group to make the end server a required attribute for reverse delegations, there are some of the databases that don't have them which makes the domain object pretty much useless.
Maintain hashes was the other action point from the last RIPE meeting. We implemented it one way, at the last RIPE meeting there was a little discussion and the ?? you didn't quite like the way we had implemented it, so we looked at that time again and we he implemented it and I think people are happier. We will be doing a review of the whole authentication model shortly or after we have done the rewrite of the update code and this is one of the aspects we want to cover because we know, even with the solution we have now, it's not ideal; there are corner cases, there are situations where you have combined PGP and pass words which is sometimes difficult to handle if it's a shared maintainer, so we do realise that there are issues and we will try and address all of these when we review the whole authentication model. I will give you back to Kaveh, who will take any questions.
WILFRIED WOEBER: Thank you Kaveh and Denis for bringing us up to speed what the current situation are. Next, Rob, please.
Rob Evans: You mentioned that you are going to try and do a clean up of things like the aut?num object. It strikes me that maybe this would be a good idea to look at what Dave Freedman suggested and was just cleared off the action list as a way of being able to reverse lookup the presence of aut?nums in a new restructured aut?num object so you can much easier clean up reference toss dead, removed objects.
KAVEH RANJBAR: Definitely. We keep a list of it. Cats from users either in this room or in the hallways, wave list, whenever we make a proposal we try to collect whatever we have on any object and we will definitely include that as well but it will be then up to the community as I mentioned because we will just make the proposal, if the community says we don't want it or do it this way, we will definitely do it and it's also opportunity for the community to acting so it's not just we say and we do; it's definitely what the community wants.
Rob Evans: Thanks.
Leo: From ICANN. I wanted to ask for clarification on the new organisation style object that you were talking about. Is that intended as a replacement for the current organisation object or in addition to?
KAVEH RANJBAR: Definitely not, it's just in addition to, mainly this is all the organisations that we have directly contract with them or they have a contract with our users and because of 2007?01 we have received a copy of that contract so we have documentation on those organisations, this will be the new type, the old org will always remain and people can freely create them and use them.
AUDIENCE SPEAKER: If I understand correctly, this is intended more like a verified organisation details object?
KAVEH RANJBAR: Yes.
AUDIENCE SPEAKER: So, for naive users of the database, is there any way that you can let people know that the difference between the original organisation object and this new object is that you have done a due diligence check to make sure that the details that are being published are accurate, because if I was a naive user of the database who didn't know what I was looking at and I saw an organisation object and I saw this object, I might not know what the difference is.
KAVEH RANJBAR: Definitely, you are right. And as I have mentioned, it will add clarity and we will make it very visible like on web server, on the web queries we can show them like in green, the two records that we have done due diligence for and the new proposal that I have mentioned for the quality audits, there will be also stamps, the proposal is to add something to the objects or something like that to mention when it was audited by NCC and by the users themselves.
AUDIENCE SPEAKER: That sounds really good.
WILFRIED WOEBER: Let me add to that, thanks Leo for bringing this up, this is the start of the discussion how to implement it, thousand structure it, how to role it with edges or without. So please start to think about that stuff and join in on the mailing list.
KAVEH RANJBAR: Exactly. This is just an idea. It's even not a proposal because we have ?? I have other implementation ideas as well for this, I just wanted to explain the idea, but please let us know what you think and if you want us we can also come up with a proposal after that
RUEDIGER VOLK: In your list of what needs to be looked at, actually documentation or formal definition was missing so kind of my question would be, well OK, where and when will we see the formal proposal of this is going to be the cement of this new object and where are we go to find the collection of all those definitions as we may actually start to do that kind of ?? of that description, hopefully for any new stuff.
KAVEH RANJBAR: Yes.
WILFRIED WOEBER: Yes.
RUEDIGER VOLK: The answer is not yes, the answer is where and how?
WILFRIED WOEBER: The answer is yes we are aware of the thing, and this is not the only one ?? this is not the only one where sort of we started to do better test implementation and not dealing with the documentation stuff, we are coming to that later so got it, and Nigel note it, so we should have it in the minutes and I will try to keep it in my brain as well.
KAVEH RANJBAR: From our side as we have mentioned, we are aware of that and we made this conscious decision, we have documentation but it's scattered for most of the things, so. Things we don't but we will definitely provide that we want to do it after the redevelopment is complete, just not waste resources because they change a lot.
WILFRIED WOEBER: Thank you. And just in the framework of sort of collecting comments regarding this new development, new implementation, minor changes I think it's a perfect point in time to ask Ruediger to just contribute his comments for his, whatever would you like to label it, regarding the stability of the output of the interface and that sort of thing.
RUEDIGER VOLK: Yes. Sorry, no slides but it could have been no more than two. We have had a couple of incidents where our heavy use production database access started to fail and it usually took something like a day or so to get up again and I think Kaveh already addressed some of the background and addressed some of the things that I think we saw need to be fixed, but let me talk about some small innocently looking things where ?? that probably should also get a little bit more attention, like, we have the IETF standard RPSL definition, which defines kind of the schema and the syntax of the database content, and it defines actually kind of the syntax of what is returned as objects from the RIPE database. The actual access protocol to the database engines is not an IETF standard, and actually, it isn't really that well?defined and well understood and small changes can happen there and of course, break the programmes that access the database. And we have seen that happen, and well, we don't usually talk about how to change this, and that obviously can cause production systems to fail because the assumption they operate under go away. So one very simple thing that recently is within the access protocol, there is actually a concept of messages that are essentially treated as comments, well objection sometimes the comments actually have semantics like carrying error codes and, OK, so what we have seen and what we are still seeing is, for example, there used to be a convention on RIPE database service that's still active, say on the AP?nix server, that in the comments that are returned when you open your session, you get an identification of the server and potentially the software that's being used, and some people may use it, actually our programmes don't do, at the moment, but they could and one of the recent changes was, we are not seeing that identification any more at the beginning of the answer; it might actually come at the very end of the ?? of the results that, well, OK, our programmes may already have lost track of parsing or receiving, but adding comments somewhere and moving comments around would look like innocent and not a protocol change, well looking at the specifics I would say, yes, this is a protocol change, and it broke things and actually, together with the changes of the software, it looks like the trailing comment at least broke our implementation. So, even that kind of stuff, I think actually should be openly discussed and documented if changed. So, that's this part. Let me add one more comment on the last things you were telling about development plans, actually we have been doing a few interesting extensions to our IR toolset recently and I am quite happy that we are very close to publish that out to the community again and for some of those extensions. Actually, it is extremely helpful that we do not have any complex server side processing, that we can do things in IRR tool sets for announcements with the RIPE database because we are actually doing all the processing client side and can tweak it there, and well, OK, having the server side processing like in RADB, well OK, prevents us from doing things that we consider helpful, so be careful about moving things over to server side.
WILFRIED WOEBER: OK. Thank you, Ruediger. And I think this is going to be part of the development lifecycle.
KAVEH RANJBAR: First about changes to IR toolset, I just brought that as an example. If you definitely communicated with the community and developers, it's not that we just add some features and say now you can use them, definitely not. We will get in touch as it was on my slide with the community and ask them if they want anything and if they want, what can help them. So that's the idea. And thanks Mr. Ruediger for his comments. He is right, for example, for the version number, we added it at the end, which we also know is like an odd choice because normally you expect to see the version number and at the beginning so you can do any kind of processing if you want to make decisions based on that. But we are in a kind of dilemma. We have reimplemented the software completely from scratch, even in a new language and we wanted to be 100 percent backward compatible, we didn't want to break any scripts, for the query software, I had three versions of AS use and two versions of IR toolset on my own machine and I was testing all of this because I wanted to make sure we are not breaking any of those. I also had two other routes generators and putting the comments on top breaks the AS use, but as Ruediger mentioned, this is ?? I mean, there is a choice; breaking the AS use or breaking the protocol, and the thing is a protocol is not that well?defined but what we decided because we know the AS use is being reimplemented and it's actually almost done, as Alex sent the announcement so after we officially say OK, this is a new way to get the AS use data, then we can actually ?? we are much more free because IR toolset and our route set generators they are implemented in a much more sane way than AS use but it is vitally used by a small and medium?sized members at least. And so, that is kind of our plan at the moment. So what we are trying to do is when the AS use is completely decommissioned we will be much more free to, again, back like the old times and adhere to actual standard. But at the moment, we made this decision; it doesn't break the standard IR toolset but Ruediger is right and I think there is a bigger picture here, so that the version number is really not an issue, we can remove it like in one hour or move it to anywhere. The actual thing is proper communication and transparency and as I have mentioned, we are definitely committed to that and we definitely took Deutsche Telecom and Ruediger's input in that process. We have already made changed, as I have mentioned we are going to make some others so thank you again for all your inputs.
WILFRIED WOEBER: Yes, just like a more general thought, it might not be the correct one, just for the discussion; if there is sort of a an atlernative to potentially breaking stuff which is at the users' side or breaking stuff that is sort of under your control with regard to software maintenance, I would suggest that you rather break your own tools because you know what is going wrong and you can fix that, but as a community, unfortunately we don't know what in the user community what type and sort of scripts or programmes are around so it's, I would guess it's much more difficult to find out what the impact of a change is.
KAVEH RANJBAR: Yes.
WILFRIED WOEBER: It's just a thought.
KAVEH RANJBAR: That would be our first choice, but the thing is AS use, it was ?? but the good thing is already reimplemented.
WILFRIED WOEBER: I think in that particular case it's just simply, it would simply be a matter of moving it in ?? to the positional place and changing the other ??
KAVEH RANJBAR: For past few years we didn't have it, but as I said, that specific version number is just one example. The bigger picture is the whole process of communicating these things and we did that but we found out a lot more and we learned a lot.
WILFRIED WOEBER: OK. Thanks again. And maybe you will stick around, not necessarily on the stage, because I would like to move on to the next item on the agenda and we had it on the agenda, and on the list review and we had it as part of your presentation, the geolocation thingy, and some of you may have seen that I tried to start the discussion about the merits, the uses, the shortcomings of the geolocation functionality in the database machinery as it is available right now, and unfortunately, the overwhelming number of replies being zero makes me a little bit cautious because if not ?? if and when not even those people who had argued in favour of the functionality would care to respond to a question like: Is it useful? How are you using it? How do you want to see it developed? I am getting the feeling that we actually wasting the resources in the RIPE NCC. And this is something I'd like to bring up for the community. And my current feeling here is that I would propose to abandon the whole thing, giving sort of a grace period of one or two weeks on the mailing list and if nobody speaks up, then I would rather propose to the RIPE NCC to rip it out and as a community, to take it as a nice idea and nice exercise but we had made mistakes in the past and we are going to make mistakes in the future and we might take this as one of these mistakes where we try to overload the database with stuff that's not directly related to the registry services and that sort of things. One of the background reasons why I have developed that position personally, not as a Working Group Chair but personally, is there are so many open issues with the maintenance of the geolocation stuff, with the usage, with the semantics of the stuff that you put into it, that I would would really like to see some active involvement in the community and proposals and discussions before we actually fund the RIPE NCC to do stuff. Any comments on that one?
RICHARD BARNES: Can you remind me how long this feature has been in the database?
KAVEH RANJBAR: Yes, they were introduced like one week before last RIPE meeting.
RICHARD BARNES: About six months?
KAVEH RANJBAR: Yes.
RICHARD BARNES: I just wanted to bring some data to the discussion, being when of the measurement Chairs. I prefer to use actually usage statistics as a baseline rather than just participation in Working Group discussions because lots of people don't talk on mailing lists, so looking at the database right now, I am seeing there is somewhere in the order of 380 to 400 INET num that have been populated with this field, so just to put that out there as a data point there is some usage of this at least in terms of people populateing that field in their objects.
WILFRIED WOEBER: Yes, definitely, there are some, and we have seen ?? we have seen the figures, but as a percentage, it's even less than the IRT object usage I guess. So ?? but anyway, as I was ?? as I was proposing, this is into the decision here; at that point in time on the spot. So there is still the opportunity for the community to join in on the Database Working Group. We might also after consultation with the NCC decide to put another message out on the ?? on to the Services Working Group and asking the Chairs of the NCC Services Working Group whether they want to have that, but I'm pretty disappointed, actually, as very personal comment, that we started this discussion, we spent the effort to implement it and obviously nobody cares about it, or almost nobody. But, as I said, sort of exaggerating a little bit to get someone active. Another comment?
RICHARD BARNES: I was going to express slightly less pessimism than you, Wilfried, I think we are fairly early on and this has not ban hugely widely publicised thing so at this stage we have got some initial data in place, some feedback from the intended consumers of this, namely the content providers, who I am not sure have been so engaged in this. I will try and, you know, ping some folks and get some feedback on that, which I think is ultimately the measure of whether this is valuable, whether anyone is reading it, not just whether anyone is writing it.
WILFRIED WOEBER: OK. But be aware that in case we keep it, it's going to add another layer of complexity with regard to maintenance of the thing because who is actually expected to maintain that subset of data in the object, is it just the management entity which is responsible for registering the IP addresses in the registry, is it customers who should actually have the privilege to configure that, and my feeling is we should really collect data about the usage of that stuff, because this might even play into intellectual property rights, things partitioning the availability of media streams and that sort of things because right now, geolocation services are used to control access to some sort of services, so if we try to import that into the RIPE database I think we should pretty clearly understand what we are doing.
KAVEH RANJBAR: I am not in a position to like vote for or not for the service but just to let the community know that because we are in RIPE NCC we are kind of receiving all kind of feedback, as I mentioned in the last RIPE meeting presentation there is a lot of interest, we hear a a lot of interest in training courses, in different venues, so there is ?? we always hear the interest but obviously they are not voiced in the list as you have mentioned, and the other thing is, we also hear not about the service but in general, people are unhappy with the current geolocation systems because there is no ?? with all the issues we have already discussed on the list, so without the community, this might be a good position to at least give the geolocation data providers another data point which is validated because most of the times there is a contractual relation between the user and the ISP which can maintain the data but as you said there they are not as vocal on the list. Also, the openness of the thing, so it's a little bit strange.
ALEX BAND: And I sort of ?? from RIPE NCC ?? I want to chime in with what you said: Traditionally, we haven't really done any kind of promotion around the fact that this exists as a service, and what we of course could do is raise awareness on it again on the Database Working Group mailing list or on the services mailing list. But there are other methods that we could explore to give this a little bit more promotion, and sort of, put it into perspective a little bit more what value this information adds and what kind of difference it can make by entering it because these kinds of things are not documented at all and not made clear at all, so if people come across the fact that geolocation is an option in an INET num they don't know why they are entering it; that kind of information isn't made clear, either. If the Chairs would be OK with it, we could explore making that a little bit more visible and having a look whether that attracts a little bit more attention to this feature, and whether adoption then all of a sudden maybe increases, is that OK?
WILFRIED WOEBER: Certainly. Because I tried to start a discussion so if we actually end up with a discussion, fine with me.
RUEDIGER VOLK: I am not happy with the priority of the RIPE NCC going out promoting a certain new attribute instead of making sure that all new attributes are well?defined and documented in the first place, and well, OK, the question: Which attributes warrant particular promotion, I think is a secondary thing and I am pretty sceptical about RIPE NCC promoting the use of geolocation; I know people that I respect very much who say, well, OK, geolocation is a bad idea and I tend actually to share that view.
AUDIENCE SPEAKER: Erik Klein. I think I agree with Richard that it may be a tad early on to stress its usefulness. I do admit that five out of a million INET 6 num having geolocations is a depressing number.
KAVEH RANJBAR: Five out of 100,000.
AUDIENCE SPEAKER: Out of 3.6 million. Even IPv6 deployment is better than that. Which is my standard minimum bar for how well something has to be doing. I think perhaps this feature is also complicated by the fact that we have ?? everyone who has to do geolocation has already solved this problem in other ways and work around it so it's going to take perhaps even a little longer for something like this to actually prove to be useful because it's already ?? it's already in people's minds that it's not there, it's not useful and we have to solve it in other ways. That being said, I don't think it's consigned to that, to uselessness, so perhaps a little more time, although I don't know what your resource limitations are and how ?? how much this consumes.
WILFRIED WOEBER: OK. Thanks for that comment and I think at that point, we should cut the discussion on the geolocation because we have or stuff on the agenda. I think we stirred up the dust a little bit and we will see what actually happens, and I'm certainly willing and happy if we can talk to Alex or to some other Working Group Chairs and try to find out whether it's useful, thousand do it, yes or no. So, again, thanks Kaveh.
KAVEH RANJBAR: Thank you.
WILFRIED WOEBER: Thanks, Denis, and I'd like to move on to Vesna or Daniel, I don't know who is going to give the presentation about the ideas of history or access to the history of registration data.
VESNA MANOJLOVIC: I can do it and I don't have slides, I will use the browser. So, the idea that we wanted to present today is showing the history of the registration in the RIPE database. There is labs RIPE ?? RIPE Labs article published about it, and here you can see how it would look like. So, the main goal is to satisfy a certain need there was a expressed in several mailing lists recently, about a month ago, when people said that it would be useful to see the history of certain objects, specifically due to the probable upcoming transfers between LIRs, transferring allocated resources. It is ?? it has been announced on the previous RIPE meeting that this is a possibility, a possible feature in RIPE stat, and at that time we limited it only to the RIPE NCC staff and so we decided to make a very temporary demonstration of how this feature would look like if presented to the RIPE NCC members. So if you are a member of the RIPE NCC, if you are an LIR you can log it in with your RIPE NCC access account to the RIPE stat and if you do, in the INET num object, for example, you will see this, so the drop?down menu which will let you, so to say, time travel to the past' see the past of database objects and this is all done in a object browser, so if you query for the address space or the AS number you will see the INET num or aut?num and the related objects for this resource, let's say, and all of them will come from the past, so when you choose the time moment, it will also show you all the objects that were referenced by that resource at that point in history. So this is the description of the feature. Our question to you is: Do you want this? Should this be visible to the RIPE NCC members? We received also some comments that actually should maybe be visible to everyone, so this is now discussion that I would like to have with you and we also are going to announce this in the NCC services group but there isn't much time there to talk about all the things that RIPE NCC wants to present, so this is why we brought it to this audience.
SHANE KERR: This is Shane Kerr from ISC. I am one of the people that mentioned that it might have been really nice to look at this feature but I am not a member, so I don't really know if it's useful or not; I have some theoretical ideas about it but I am actually a little disturbed that the RIPE NCC has recently started producing services and adding features to things like the database which has always been a community?owned database and is now being extended in ways that are for members only. Now, of course, the members are the ones that pay the salary, the members are the ones that are duly doing the work for the ?? supporting for the work for this activity, so it feels a bit weird to say I don't like it because I don't get a vote, but I do think it's a bit weird to ?? I don't think it's the right direction; I'd prefer the RIPE NCC to go the other way and make this service available more openly. Having said that, do I have a couple of questions beyond that. The first is: How do European data protection rules fit into this? We see an object here with some updates from 2003 or something like that and my understanding is basically if you don't need the information about people, organisations, basically any information that could be considered private you shouldn't be holding on to it. Now, I understand that maybe this information is just stored internally in some logs and it's never accessed, and I think that's probably OK, but all of a sudden, now, it's becoming available to people externally, people ?? and people then have the ability and once it's available people will probably start looking at that time which brings me to my last point, which is that it's kind of a change of the rules; it used to be that if I made a mistake in the database, it's not a big deal, I just fix it, I update the data and now my information is correct but now I have got to be a little more careful about the information I put in the database because if I miss type someone's name, it's going to be there forever and ever and anyone can go back see and I am a bad typist, and it could be more serious, if one of my engineers accidentally put in a customer information that's not appropriate, why delete it right away but now it's available forever, and it's not necessarily a problem that the database works in this way but if you change the rules now, then I think it might be a problem, so I guess my thinking is that I think it's probably a good thing to have historical information, but it should definitely be only after a certain date, and people should be aware that any information that they are putting in the database after that date will be available in perpetuity and they should at least have the option to opt out of that situation.
VESNA MANOJLOVIC: Thank you very much for bringing this up and those are certainly very interesting points and we will take them into consideration. And I don't have an answer on the legal aspects of this and the data protection aspect.
SHANE KERR: Are you going to address that, Wilfried?
WILFRIED WOEBER: I would just, as soon as they commence from your ?? comments from your end die down, I would like to add my own personal feelings, which actually gets me in a position that I don't know whether I should want it or I should argue against it, because from different points of view, I have more or less agree with Shane, it's in principle a good thing, and like if you listen to people from the security teams, they are very eager to have a means to role back in time and to trace (roll) trace the whereabouts of an address block or something like that, with that hat on I would like to see it yesterday. On the other hand, we know that in the Commission there are currently discussions going on about sort of introducing a functionality to the net to forget data, so the right of an individual to have his or her data forgotten in the Internet, this might definitely run against that discussion. Then, there seems to be common understanding that some parties are offering sort of similar services and there is also a feeling amongst many in that camp doing data protection and doing privacy, private data task force thingy that those parties offering those services actually collected the data by violating the A O P, so at the moment we seem to have some sort of similar services available based on issues of the database and provided by third parties and sort of we are not able to do that in a clean way at the source of the data. I don't know whether this should be a good or bad idea, it's just thoughts about the whole problem space. And
And the other thing I started to wonder about is, what is the sort of inter framework of this complete contractual relationship thing. As long as there is a contractual relationship between the RIPE NCC and the resource holder, either directly or by way of sponsoring LIR, there is a very sound legal basis to publish the data. If this sort of contractual relationship is no longer there, I am not convinced that the RIPE NCC is in a position to disclose historical data. Just wild ideas popping from left to right and up and down in my head. I hope it's going to be an interesting discussion that we are starting here. So anyone else?
VESNA MANOJLOVIC: Thank you for this until now.
AUDIENCE SPEAKER: Regarding the availability of the data to everybody, I think the privacy in this case should be more important ?? I would not ?? if this comes, I would not make it available for everybody on the net because coming from Germany, you know, we are very privacy?conscious and I have, I am sure I have a lot of customers who would have a lot of problems with this. I can only speak for the DE?NIC where if you need a history of a domain object, you can request it on a case?by?case basis, you say I need it because I need legal documentation or something else, and then you get this one object with this ?? with the history of it, you know, but not automatically, not available, yeah, to just click and see, you know, so perhaps that would be middle way, I don't know how the workload would increase by this approach, but you know...
VESNA MANOJLOVIC: When you say not make it available to everyone, right now it is available only to the RIPE NCC members.
AUDIENCE SPEAKER: Exactly.
VESNA MANOJLOVIC: Is that more acceptable?
AUDIENCE SPEAKER: For me personally I would say yes. That's more acceptable. And I hope that the members would be ?? would use it ?? thousand should be used, you ?? how it should be used, not put it in your database or spread it around, you know. I hope that the members would do that. I don't know how it pans out in the future, you know. Th Heather: Horizon, I am also ARIN Advisory Council member, I missed the beginning of the discussion so I am sorry if I say something that has already been discussed. Today, you have a bulk Whois arrangement, so you can sign the agreement and get a copy of the current database snapshots daily. I think having a whowas function and applying the same criteria to who has access to it that do you for bulk Whois, just is the sort of the same thing except that you can ?? you don't have to, as a recipient of the data you don't have to store the data yourself, having some mechanism to be able to go in and query the data directly from RIPE means I don't have to download however much data it is and keep it every day and having that replicated across whoever you are distributing bulk Whois to.
And the other part of it that I wanted to mention was that to kind of give another perspective, that we had this discussion in the ARIN region, I actually was the person who kind of poked at it; and it is ?? it is something that security folks wanted to have and be able to go back and correlate, you know, this address block was used for abuse and here is the contact information or here ?? who it was allocated to and be able to track how address blocks maybe change hands that are being used for abuse issues. And then they had a lot of the same concerns in the ARIN region about who would have access to the data, how would it be used, that kind of thing, and they kind of did what I was say, which was applied the same criteria of who has access to bulk Whois and you have to go through this extra step of being vetted and getting permission to have who was data. So it's not just open to the public, at least in the ARIN region.
VESNA MANOJLOVIC: Thank you, I do find it very interesting how you arrange the whowas, I would be interested to talk with you about it later.
KAVEH RANJBAR: To give some collar at thisication, we provide bulk access but there are two methods, both of those methods we come toify the data as we call it so there is no personal data in the bulk so there is no way to get bulk access with all the personal data, we remove them or replace them with other objects.
PETER KOCH: So as a disclaimer I am still an engineer not working for the legal department. Would I work for the legal department I would have much more fun because people are coming up asking for interesting information all day, and they don't get it, right? Well, not all of it. I think this is ?? first of all, I think these two applications are not necessarily completely comparable, because the data we provide in our Whois system is already a bit bit more restricted than what the RIPE NCC provides in the RIPE database. And second, yeah, I think it's definitely advised to do a data protection audit of this whole idea, because yeah, you are keeping records, not the least for reasons of compliance, as most of us have to do, but that doesn't mean that these records kept for compliance need to be made publically available and privacy legislation, not only in my country but in others as well, would actually advise against that. Again, I am still not working for the legal department but this is what I get out of the discussions there, so this is community requirements or demands, say, versus what the legal demands are, and they need to be weighed and you can't just copy from one example to the other. Thanks.
WILFRIED WOEBER: Thanks, Peter. And just maybe as one of the last observations, again as a private person on the network, I don't see a big difference making it available to members and making it available publically because we don't have any restrictions against becoming a member of the NCC. So, it more or less boils down that you just have to have, yeah, a pile of money, put it on the NCC's table and you get access to the data. So it might be a nice source of income for the NCC but it's not really a discriminatory thing like this is the gang which should have access and you are, sorry, not part of that gang, it's just a matter of money, I guess. Just as a private comment. But, many thanks for bringing it up.
VESNA MANOJLOVIC: Thank you for the feedback and we will take it into consideration, and decide the fate of this demo and the pilot soon after the RIPE meeting and we will inform you about it. Thank you.
WILFRIED WOEBER: Are there any immediate activities that you expect someone to start, like any action on someone in the framework of the Working Group or just private discussions or discussions on whichever mailing list?
VESNA MANOJLOVIC: We will look through all the descriptions and logs of this discussion and we were planning to close this as a pilot, as a test, within, I think, by the end of the RIPE meeting, so we might close it until we are clear what the decision is going to be on this project. Thank you.
WILFRIED WOEBER: Thank you, Vesna. Thank you, Daniel, because I think you were involved as well to some degree. And we have Peter from DE?NIC also talking about Whois stuff and this is more or less Whois stuff as well, and I think that's a very nice bridge to build and to ask Olaf to give us an update on where one of the IETF Working Groups appropriately called WEIRDS and dealing with Whois issues, sort of give us a brief summary of where this Working Group is and whether there are any open issues we should be thinking about.
OLAF KOLKMAN: We carefully don't use the words "Whois" in this context. Registration data access protocol I believe is the word de jour is. WEIRDS is an acronym that's extended to web extensible Internet registration data service, I am co?chair of this group together with Murray.
It's a small update because I sort of assumed that everybody sort of knows what this is. What this group is chartered for is, in fact, develop a registration data access protocol, standardise a single data framework to exchange messages, deliver those messages, encapsulate it in a so?called restful http service, follow general requirements that were laid down a while ago by the CRISP Working Group and most importantly, produce something that's simple to implement and can support internationalisation by which queering data from registration services is more easy.
The charter allows for the possibility of differential services based on client authentication but the whole authentication business is kept out of scope for the group, basically everything authentication models will be based on http.
We use the term "restful." For those who don't know, it's a programming model a mindset I would say used in web architectures, representational state transfer is the acronym, expansion, basically you use verbs and you get resources back, things are all represented by URIs, and it's all built on top of http so programmers have the basic libraries accessible.
There is running code for this. ARIN has a restful interface and you can see a restful query there, it's basically a URL, and you get an answer back. RIPE NCC has also implemented a restful implementation, which I think is on ripe.net/development. It's all there.
The Working Group doesn't deal with numbers only, so it's not a Working Group that deals with registration ?? number registration data, AS numbers and IP addresses but is also chartered to deal with domain names. This is interesting in the number space there are about five implementers, the five IRRs, in the domain name space there are now 2000 domain registries coming. But it is considered to have ?? that it's good if there is one protocol that serve them both and the Working Group has decided to move on together and produce one single protocol for both names and numbers and only split off if the work doesn't progress or things are really needed to split.
On the numbers side, basically things work. Prototypes have been developed and all that work is input into the Working Group, which means that the Working Group actually has a good flying start, I would say. But there is a lot of grade breathing matters somewhere in the room that's touched by many sides and that's the data model. What do you exchange, how do you exchange it, what do you need to standardise, what don't you standardise? And again, on a number space consensus is easily found, but on the name space, this is a somewhat harder problem.
Currently, there is people working in design teams to make inventories of data commonly used, specifically in the name space and that's all input to the Working Group.
As I said, the Working Group tries to work to a unified protocol. With the flying start, we have some documents. If you want to know more about the background, specifically this community, read up on how RIPE did this in their development pages, but also have a look at the charter.
Current status that we just adopted for documents to up on in Working Group context, a general document describing the protocol as a whole, query format, response format and JSON and security services and this is all the start of the work so this is a fairly good time to step in and contribute if you are interested in this stuff.
We have two Bofs, first face?to?face meeting and the next face?to?face will be in November, in about a month from now. And if you want to know more, these are the coordinates. And that's my update.
WILFRIED WOEBER: Thank you, Olaf, and comments?
SHANE KERR: So Olaf, as you are aware, this is not the first attempt to improve or replace Whois, it's not the second attempt, it's not the third attempt, I don't think it's the fourth eye tempt either, so I mean, my questions are about that; why ?? first, why is this going on now? And why is there any hope of thinking it's going to succeed this time when it didn't succeed with Whois plus plus or R Whois or IRS or any of the others?
OLAF KOLKMAN: I find it hard to answer. Why am I chairing the group? I can answer that. Because I do have hope that there is a bunch of folk currently meeting in one room that have, that seem to have common goals in and the will to work together, and there is implementation specifically in the RIR world where people have come together. If all fails, if all fails and failure will probably come from the name site, because there might not be consensus reached on the name site, then there is plenty of consensus around at the number sites to come up with something useful for standardisation on that site. So there will at least be partial success but I think and hope, you know, this is RIPE's, there is no guarantees. If you ask for guarantee, I don't have them.
WILFRIED WOEBER: May I ??
OLAF KOLKMAN: It's a community thing.
WILFRIED WOEBER: May I add a little bit to the question like why, part of the motivation to have this Working Group created has actually a background in the ICANN environment and in the Whois policy review team's report. I have been part of that and as some parts of those ?? of that report, pointed the fingers at the open issue of internationalisation of not letting character sets, of registries, registrars, Whois providers, doing things more or less on an ad hoc basis, and then some parties in ICANN started to, well, started to try to get a little bit of structure into that and they were hit over the head because ICANN is not supposed to define protocols and to do that thing, there was a strong feeling that this should actually go to the IETF, so that's where it's ended up in the end. Not to the ITU, not to cept ?? the good old IETF, that's probably not the whole story but it's part of the story, I guess.
OLAF KOLKMAN: It's multi?facetted and I think with a personal perspective, I think there is a little bit more of a push and drive to collaborate. Some external forces that come into play, yes.
SHANE KERR: Good luck.
RUEDIGER VOLK: It looks like I have to look into that IETF activity a little bit more than I used to. I think I got lost on that sometime in the past millennium. What I wonder is the actual scope of what information is under the umbrella. You were saying, well, OK, this is registration data, and there are Whois servers who are not only carrying number and name registration but also routing registry stuff.
OLAF KOLKMAN: Yes.
RUEDIGER VOLK: And well, OK, kind of reusing revamped access protocol for that stuff, looks like dealing with some of the problems I talked about earlier but is actually that kind of data really within scope or is it just the registration people dealing with the problems?
OLAF KOLKMAN: The ?? let's ?? the way that I interpret the charter and the way that I think of things are going on within the community is that the first step is going to be registration data. The protocol will probably be extendible. How the extensions will be, you know, done, that's part of the work that needs to be done, but certainly, if that step is done about registration data, you know, there is ?? if there is a sufficient body of work to incorporate other stuff and standardise other stuff, that might very well happen but it depends a little bit on the extensibility mechanisms and so on and so forth that will have to be defined.
WILFRIED WOEBER: Sounds a little bit like RPS LNG plus plus, and the cross with the access protocol.
OLAF KOLKMAN: Let's say it's not on the charter now. That's ?? that is, I think, the frankest and clearest answer I can give.
Andrew Sullivan: I just wanted to clarify one thing that happened in response to Shane's question. The impetus for this work at the IETF was did not come from ICANN; the impetus for this work actually came from the numbers registry side first and the names guys saw that the numbers registry guys were going to do something about this problem.
OLAF KOLKMAN: And they figured it was cool.
Mr. Sullivan: They figured they could hitch on, so one difference about the ?? one difference with previous efforts is that this Working Group is actually chartered in such a way that if the names guys can't get their act together then they get to be left behind, so what we could can end up with is a split protocol where only numbers are solved and the names community is out of luck because they can't come to some kind of agreement, so unlike previous efforts which sort of attempted to just kind of have one big happy protocol and if you couldn't all get along then nobody was going to implement it; what we have got instead is a path forward for numbers registries and if we can come to some agreement with other kinds of registries then that's good news but if we can't, then ICANN still has a big headache and too bad for them.
OLAF KOLKMAN: That's a much clearer answer than I just gave, thank you.
KAVEH RANJBAR: To also answer Shane and other discussions, at the moment in the number part, in ARIN 53 percent of the queries are going through the new restful method; in RIPE we have about 20% but if you exclude automated tools like IRR toolset higher than 50% so there is interest at least in the numbers part, to do that. And also to clarify what Ruediger said, we ?? yes, as you said, at the moment the charter is not focused on routing but RAPI which is already an extension to what has been discussed in the Working Group, we are the support providing routes and everything in a nicely formatted XMLRJ format.
OLAF KOLKMAN: I will be giving the same update in the DNS Working Group at which point I think the foe cuffs the discussion might be a bit different.
WILFRIED WOEBER: Thank you, Olaf, thank you very much. And as we are running out of time, I'd like to move on to the last, I hope last item on the agenda, and that's input from other Working Groups. I would like to make this Database Working Group aware of the fact that a policy proposal 2011?06 that was discussed in the framework of the Anti?Abuse Working Group is very closed to be wrapped up, to be declared to have consensus and to be implemented then by the RIPE NCC. And there are a couple of things which are outside the sort of clean policy mandate, what to implement and there might be slightly different ways of actually implementing it in the framework of the database machinery. So I'd like all of you who are involved with that and who think you might be affected by the upcoming changes, to actively review the 2011?06 to just learn what is being decided and what is being set in stone more or less on the policy plane and if you do see any issues that should be taken into account when we start implementing it, then please speak up on the Database Working Group mailing list.
RUEDIGER VOLK: Yes, well, my take at the policy proposal is a proposal that's technically just changing the database scheme. I am not quite sure ?? well, OK, I am sure the database group never was copied on the policy distribution there. Of course, the policy general announcement has been, but I somewhat suspect that database geeks may have actually missed that this is going on, and at least, at least for the question that I raised before about, well, OK, if we are changing and evolving the schema, we need to do proper documentation. I would say I don't see any there. And if I would be ?? if I would be a really nasty person, I would dig into some of the mailing ?? mail threats that had very much of a trolling touch, where one of the conclusions was we cannot define what abuse is, but we can ask everybody manditorily to maintain an abuse contact. That is something that will be hard to deal with at my operational colleagues.
WILFRIED WOEBER: OK. But thanks for the ?? thanks for the statement of your thinking. But, while I do share sort of some things with regard to implementation in the future, I think it was a conscious decision amongst the Working Groups and the Working Group Chairs to do the policy development in anti?abuse and to focus on the sort of on the policy component.
BRIAN NISBET: If I may with my Anti?Abuse Working Group Chair hat on, this is 2011?06, this has been a year?and?a?half, it has been talked about in this Database Working Group meetings, I think Kaveh possibly actually sent ?? Denis sent a mail, at least one mail to the Database Working Group in relation to this. It was done on policy announce and it's been bouncing back and forth for 18 months. Standing up now and going we didn't know about this, is ?? I don't know how you can have missed it, in short. It has been agenda itemed and talked about repeatedly. And we are ?? we finished last call, well, we finished last call on Monday, in fact, no, sorry, the week before that, currently it's just bouncing around the Working Group Chairs collective, so, yes, obviously work with ?? we are hoping that the database group and the NCC will implement it in the best possible way, but from the point of view of the policy, it's done at this point in time.
WILFRIED WOEBER: I agree, it's done policy?wise but I think we are handing over to the RIPE NCC within a few days, I guess, or a couple of weeks or one week, after we have formally declared consensus on the policy, and then we can actually sort of put a mandate on the RIPE NCC to come forward with a proposal of thousand implement it with the details sort of to satisfy, Ruediger to satisfy your requirements to have documentation first and think about the implementation later, sorry for being nasty and funny here. This is in no way meant to sort of unbundle the whole thing, it's just to make this community aware of the fact that the 11?06 policy is going to be declared consensus within a few days, and the implementation will start and if anyone in this community does have any input like how to best implement it, then I think this is the reason why we put it up on to this agenda.
BRIAN NISBET: Absolutely. Yes.
WILFRIED WOEBER: Thank you. Which gets me to the next one after the last item, that's any other business. Is there any other comments to be made? We are already taking the time of your coffee break, so unless something really urgent and important is coming up within the next ten seconds, I declare the meeting as closed. Thanks for being here, thank you for participating actively in the discussions, thanks to the RIPE NCC folks and thanks to the audio and the web infrastructure people here and, yes, see you during the rest of the week.
(Applause)
(Coffee break)
