These are unedited transcripts and may contain errors.
Database Working Group at 2 p.m. on 3th of November, 2011:
Database Working Group at 2 p.m. on 3rd of November, 2011:
WILIFRIED WOEBER: Ladies and gentlemen, RIPE colleagues, welcome to the meeting of the database Working Group right after lunch. I hope you enjoyed it. Let me get started with introducing myself, Wilifred Woeber, for those of you who haven't seen me up during the most recent days already, I'd also like to introduce to you Nigel Titley over there, who is regularly supporting the logistics of this Working Group in various ways, I think it's about time, again, to say aa loud and very heartful thanks to Nigel for supporting with us this infrastructure service.
We have got only one?and?a?half hours slot today. During this meeting, and we have to finish more or less exactly on time because this room is going to be used for another show during the thing that is listed as coffee break on your tiny thing. So the usual logistical opening words, if you want to make a contribution and you are really invited to do that, please walk up to one of the microphones, state your name and try to get a little bit of audio feedback yourself, whether you can be heard in the room and does, also, on the webcast, that is really the point of asking you to observe that.
The rest of the logistics, the draft agenda is put up behind myself. Is there anything you want to have changed or the draft agenda, anything you want deleted or added? This doesn't seem to be the case, so this is no longer the draft agenda, this is the agenda for this meeting. Then, the other points of logistics, Nigel is going to take notes and he will, as usual, circulate the draft minutes within a reasonable time after the end of this meeting. Then, we usually go to asking you whether you have any amendments to make to the draft minutes of the previous meeting. OK so rubber stamped, final minutes. And the next thing, usually is we try to take the group here through the list of open action items. This time, actually, we have the rather nice situation that all the action items, as I have learned, have been completed, and the RIPE NCC report will include the information about those open action items and how they were completed, done successfully, so we are going to skip the traditional part usually run by Nigel to walk us through the open action items because this is going to be covered by the next presentation. And going to the next presentation, I'd like to ask Kaveh to continue with the, as well, again, traditional database update thingy, which is going to include a couple of interesting things, I guess. Thank you. The stage is yours.
KAVEH RANJBAR: Thank you. So hello and good afternoon. I am manager of RIPE database department in the RIPE NCC. In this presentation I am going to provide a quick update on what we did between RIPE 62 and this meeting, in the database department, as well as an outlook on our major focus areas over the next couple of months. After the presentation, the mikes will be open for questions and comments.
First some stats: There is five of us in the RIPE database team, maintain the database core and all of the tools around it. We have an average of 14,000 queries per minute which is more than half a billion per month and IPv4 and IPv6 queries and updates and mail updates combined over the past six months had about 99.99 percent op time. For the queries it's very, very close to 100 percent. There are a lot of operational stats on?line in this URL and if there is something that is not covered here, please let us know and we can always provide that.
And now I will give you Mr. Denis Walker, our business analyst and product owner who will present you the action points.
DENIS WALKER: I am the business analyst for the database department, I will run through the action points from the last meeting and one that was outstanding from before that.
We had seven action points and we are happy to say we have completed them all this time and we will try and do that in future to get all the action points done before the next RIPE meeting.
First one is very old one from nearly five years ago, that is the clean?up of forward domain data. We started with 43 ccTLDs having their domain data for domain data in the RIPE database. We have gradually whittled it down and 41 have been removed, deleted all their data and we are down to the last two. We have been told that one of the last two removed their ?? or fixed their own database by the last week, and the next few weeks we will delete the date from our database. The last one have told us we can remove it in January of 2012, so by the first of February 2012, there will be no forward domain data left in the RIPE database. We will then adjust the syntax to make the domain objects only suitable for reverse delegations and ENUM objects.
We were asked at the last meeting to review the domain object attributes, we did this and we sent the report to the both the database and the DNS Working Group mailing lists. We had a proposal to drop attributes which were considered to be now redundant, in particular main pain law, refer sub come to and come to net. As far as we are aware, these are not used at all by reverse delegations or ENUMs, if they are, please let us know. L? we are pull in some business logic to make end server attributes, although optional, required for reverse delegations but not ENUM objects.
The next one, we were asked to do a TLS query service. We did a prototype and deployed it in June, working on a copy of the RIPE database. That is the command you can use to access it. Also we'd like to point out there is another possible option for you, now we have the RIPE database query API. This gives you http access, may want to consider that as an alternative to TLS. We were also asked to look at the very old ongoing issue of password versus PGP. The perception has always been that PGP is the main player and pass words is something that we can get rid of. In reality, 86 percent of all the maintainers in the database only have a password. We were then asked to look at, well, maybe the other small percentage of ones with PGP are the ones control most of the data. There were many ways to look at that. We chose to look at the maintained law on the allocation objects. This is the maintain of the controls that creation of all the assignments in the RIPE database. When we looked at these, we found 99.15 percent of all of those maintained laws contained a password. So, the reality is very different to the perception. In reality, passwords is the main player in terms of authentication. It's up to you to consider what you may want to do with that information. We simply presented the figures.
The other one was the dash notation reverse domain objects. This is a point that came from the DNS Working Group passed over the database Working Group for us to look at. We sent a proposal to the database Working Group mailing list in April, this has now been implemented. In brief, what we did was dropped the dash notation in the third objecting at the time and we have added the dash notation to the fourth, but also we made a subtle difference to the way it works. Previously, the dash notation was a simple shortcut to creating objects. If you did something nought to 100, we would actually unwrap that and create 100 objects in 100 ?? 101 objects in the RIPE database. What we do now is if you put the dash notation the fourth objecting at the time, we create the object with the dash so if you want to modify it or delete it again you work it on one single object. The expansion is now done by the DNS provisioning software, when they do all the zone work, so as far as the RIPE database is concerned we store the single object with a dash.
2007?01, I think gave you an update on the progress of that yesterday. We are required to monitor independent resources, so we were asked to put, do a mass update and put the specific maintainer on all of these objects so that can monitor it. We sent a proposal about this to the mailing list in June and this was all completed. We didn't send individual announcements because there is a lot of them. We would have been as a spammer if we sent out notifications like that so we announced what we were going to do and we did it.
Geolocation. We were asked to investigate geolocation. We do agile development and very quick thing around on things. With this kind of thing and TLS what we want to do in future is rather than come back with a report and say yes you could do this and it might look like that and you might consider it that way or that, we want to knock up a very quick basic prototype. It's into the production code or fully functional, it doesn't give you all the bells and whistles but it's something tangible you can look at, play with and think is that what we wanted or would it be better if we did this or that. It's a proofer concept. So we have done that in in case, we have done a very quick prototype with the optional attributes for location and language. We sent ?? we have done documentation on it which you will find on RIPE Labs. Go ahead and play with it and see what you think. I think that concludes the action points. Thank you.
WILIFRIED WOEBER: Just to follow up immediately on the action items, the 62 O2 regarding exactly this one, is this from your point of view, is this an auto pilot so is this going to happen anyway or do you require anything from our end?
DENIS WALKER: No, we did a review and we sent a report to the mailing list, basically now what do you want to us do. So we looked at it it, in our opinion this list of attributes we mentioned we don't think is of any value to reverse delegation on ENUM object. If you confirm that we can go ahead and regard those as redundant attributes and ??
WILIFRIED WOEBER: So this Working Group has to advise you on how to proceed or not to proceed?
DENIS WALKER: Yes.
WILIFRIED WOEBER: Thank you for that one.
DENIS WALKER: You or DNS or ENUM, between you.
WILIFRIED WOEBER: It's not going to happen automatically, we have to do something.
DENIS WALKER: Yes.
WILIFRIED WOEBER: Second one, 62.1, this is actually not a question; this is actually saying thank you for doing more and I think more useful stuff than we were actually maintaining you to do because we asked to you investigate and you put up sort of a proposal ??
DENIS WALKER: We think it's easier to do it that way.
WILIFRIED WOEBER: Partly functional. Thank you for that one.
KAVEH RANJBAR: Thank you. So, in this section we will quickly go through our projects. In past six months we restructured or improved efficiency and have updated our infrastructure and our test is test driven as ?? create Java development for all new services and we can respond to feature implementations with much higher efficiency and side effect we can switch tasks much faster and as a result, we have an argument with our customer service team that the ticket stays clear to us, database tickets, we will always reply to them in one working day, and in most of the cases, we reply formally in less than two hours.
We also have, we got rid of some of the very old servers that we had, one of the servers we decommissioned last month was eight years old. With these applications we are switching everything to the standard NCC set up of servers and they are highly reliable and obvious benefit is less downtime and also new infrastructure give us the possibility of deployment so we don't interrupt service, we can put new software live. As announced yesterday, all of the old CGIs are replaced with new web services. This means that we kept the core but everything on top of the core, all the front and stuff are replaced now with new software. And we also tried during this migration to improve UI and some functionality.
So, we also deployed lot of the services, most of them you have already seen in the, in previous updates, they were ?? in labs but now erring is deployed to production. I wanted to run a demo but I see we are running out of time so I will skip the demo but since all of them are in production, it's very easy to see them and some of them are ?? looks like very small improvements but when summed up it makes working with data much easier. As an example the first one that I have mentioned here is all of the database tools are accessible from right?hand ? if you are on any database tools page you have access to all other tools related to database. It doesn't matter which page you are. There is a simple integration between query and updates, we will work to improve that as well. If do you normal query on web query forms there is, if you hover over them, you will always see update and delete button which will directly send you to web updates for that object. There is a lot of other small improvements like that. There is a copy link which copies a permanent link for query to your clipboard. One example is maintainer recovery process, six?step process before. We had a lot of chats with customer services and we were able to actually use that to three step process and previously, members had to actually fax a copy of the printed document, now it's possible to also e?mail it, still they have to print it on their letterhead and sign it but now they can scan it and e?mail back to us and it's all automated at the back. GRS is another service which has been demoed and mentioned before. It's also now, it's deployed in production. There are ?? for people not familiar with that, we actually get the nightly dumps of other four LIRs plus some pager IRRs like JPIR, for example, and/or RADB and we import them to RIPE database as a source called, for example, LACNIC?GRS. There are two major benefits: One is you can go to only one location which is RIPE Whois server and get data for all LIRs plus major IRRs. Another benefit, which I think is a beauty of this service, is that you can, what you get back is always in ?? even if you are querying ARIN database, our copy of the ARIN database, you get the ?? your results in RIPE, so if you have developed something, a script for example, with processes you can run that over all ?? all IRRs and RIRs. And finally, the rest API, it's in production, the query and updates. All the developments inside NCC who interact with RIPE database they use rest API to work with RIPE database and we know that there are quite some different developing groups who are developing tools against this API. One of the things mentioned in the documentation I think is a great feature, you can use GRS to API, if your software knows how to talk with our API you have access again to all of the routing and registry Whois data that is out there, you have access to that and get it in one single format.
So, so this gets us to the work in progress. One of the major goals for us in coming months redevelopment of core database software. In the last RIPE meeting we mentioned that it's RIPE database is now ten years old. Now it's even more than ten years, and in the software industry it's quite some age, in Internet it's even more what we are trying to do is to redevelop and ?? this software. (More) but one thing we can't afford is to do a big bang deployment, like we spent some months developing the query part and we press this switch and now the newer software is active. Database software is critical and we can't risk that. In order to achieve smooth transition we implemented a proxy and we implemented a new server, a new query server. This at the moment knows only how to handle one or two of let's say 400 possible query types. So the proxy, when a query comes in, the proxy tries to detect so the new software knows how to handle this, for it doesn't it will route it to the old software. As you add new query types to the, more of the traffic will be routed to the new query server and we will get to a point that all the traffic is routed to the new query server and we can decommission and roll out the old.
We will use the same process for updates and then finally we will get data storage. This is modular and there are interfaces between these modules, so it will be easy to add and replace the old software brick by brick.
We don't expect any behaviour change so our goal is to keep the new software 100% compatable so at the end when we do this users should not notice any change actually. It should be very transparent for end users. And ?? result modern flexible and scaleable database software which we can happily and be proud of to maintain for the RIPE community for next couple of years.
Another focus point for us is streamlining database related processes, this will be done mostly through more intelligent database users. What we mean by this is right now, we have complete set of tools like web updates. It's very nice but a tool and I emphasise on word tool, which means you have to be familiar with the concept of the database to a good level to be able to operate this tool. It's good, we have training courses which we always tried to spread the knowledge and we have documents and videos, there will be an e?learning course but still, this steep learning curve for the database, the entry point, is ? we think is a major barrier for data quality because there are a lot of users which database is not day?to?day port of business so they set up their objects on to a point that it works and then, yes, it works. So they don't update it. What we are planning to is to provide some tools to capture most common business processes and these tools will somehow try to guide the user through a process, so before they start we will them them you want to update your objects, awful your objects that your maintainer has so you need a password for this or maintainer and then press next, they see their objects, they get the option to edit them. I am sure you have heard about strong registry in different occasions, it's a big projects but one of the pillars is actually to make it clear who is responsible for what part of the data. Right now, if you query RIPE database and get an object sometimes it's really hard and confusing to detect which part of the data is maintained by RIPE NCC and which part of the data is maintained by the user and we have to make it clear, and that is what we want to do, but and it sounds simple but because of all the policies and business processes it's a complex process so we will do it again incremental in small steps.
And this gets me to my final point on this presentation, gee location. Just some introduction, we have received a lot of requests through many different channels, members' area, registration services, RIPE meetings and training courses and meetings we attend. In the survey, which was presented I think in the first day of the RIPE meeting, out of 112 answers to the question: Are there additional fields or that would you like to see in the RIPE database? Eleven direct ?? there were some also implied something close to geolocation. It's the fourth action area for the whole RIPE NCC not only the database to improve and set up to promote. Obviously it was not rated as an important service because we don't provide it as service so that is not surprise. And after data quality improvements and clarification of sponsoring of LIR data it is most wanted service in RIPE database, as people who enter the survey. And it is also third one in database and DNS wanted features list. Also again, in general NCC services participants have pointed geolocation as important service for RIPE NCC.
So, based on the action point from RIPE 62 and mentioned requirements we developed a prototype. As Denis mentioned, the goal ?? what we did, we developed a wire model. That is the goal of the prototype. And the goal is to have this wire model, it's not ?? it's definitely not production ready software; it's just something out there. We want to play with community with this wire model, just try to shape it to something that all of us or most of the community agrees to as the user of service and when that is done we can work on it to make a production?ready software. So what we wanted is just a common ground to base all of this production development on that.
We have received some positive feedback for the prototype and some concerns, mostly raised on the Working Group mailing list about this prototype, but most of the concerns were based on the assumption that the prototype is a final product, so this is my ?? this is what I understood from reading most of the communications in the Working Group. Which is definitely not right. We are not going to just paint that and put it in production and this is geolocation. No, no. That is definitely not the case. We also spent very quite short A time actually to implement that, that wire model. We put it there as a common ground we can discuss and get to a point that we can get a product out of it or maybe not binge we have to play with it and see if we can get something out of it.
So finally to recap the whole story for geolocation. What we did in the prototype, we have added the content language and location optional fields and again, I emphasise optional, to a copy of the test database. We provided some higher level helper tools like on web updates if you want to update any of the objects, which we provided you with a map which you can select if you don't know the numbers, you have to enter for the object so you select it's on a map and fills in the numbers automatically or we provided some example for automated updates or queries, and also provided just again as an example, we changed the abuse find tore something called location finder. For example, if you want to find out the content language for an object but it doesn't have it because the field is optional, it can traverse the hierarchy and go up and find on the highest level it can and say this might be the answer to the question you are looking for.
So this concludes my presentation. And...
WILIFRIED WOEBER: First of all, thank you very much, and secondly, are there any immediate reactions to any details? If this is not the case I would prefer to invite Richard to just continue regarding this topic with the presentational ideas, some clarifications he offered just recently and I think it is more useful to take the question at the start of the discussion after we had both presentations.
RICHARD BARNES: First of all, I wanted to thank the database team for coming up with the prototype and putting some concrete code in place that we can have some really concrete discussion about what we are going to do with this geolocation idea. I wanted to present some comments about what we might do to present some privacy in this database. I noticed a lot of comments and concerns that people raised when the prototype came out were about how to maintain the privacy of this information and some questions about the semantics of the information so I wanted to present some suggestions for some possible approaches might be to improving those two questions.
So, I think for those of you who haven't seen the prototype, this is what it looks like. They have added in response to all the feedback they got, through the surveys and meetings and things like that, there were two additional fields that were added to the database, one for language and one for geolocation. The idea is although the language has a tag at that identifies a language that the users in this network would prefer to have their content presented in and the geolocation field expresses where the users of this network are located.
Now, this raises a couple of interesting questions: The language field, it's pretty OK. My only observation is there is an RFC that has standard tags and we should probably use those because things like language headers have those and there is common infrastructure for that. There are two main problems with the geolocation thing. The one concern is privacy protection, we will talk about that in some detail later but the other thing is that right now, there is not really a clear semantic to it. It's supposed to be the field is supposed to mean this is where my users are in general, but the current prototype only allows to you provision a point and clearly I probably can't fit on the single point on the earth if you want to be mathematical about it, it's indinly small and all of the subscribesers of an ISP aren't at a point either. Can we provide a structure that is more flexible for describing an area or something that actually expresses an ISP's coverage or network's coverage more accurately.
So I wanted to make a suggestion to generalise this field from being a pair of coordinates to being a URI.
I want to suggest two main types of URIs, one is geoURI that was definition from I think it's RFC, I am forgetting it now, but describes this geo URI. Basically what it provides is a moderate extension of what is in the current prototype. It provides a pair of coordinates but it can also provide an uncertainty radius. If you have a network that is physically consolidated, within roughly a circle or you're comfortable providing and drawing a circle around this and it's not something where you have privacy concerns then this more direct expression of location can be very easy, it can be roughly what is in the prototype right now in terms of how easy it is to provision you draw a map and it's pretty simple. And but you still get a little bit more faithful representation where the network is, the illustration I have given here is actually BBN's office in the Washington DC area. It's an enterprise network, we don't care about telling people where our office is so there is to privacy concerns and it's in that building so we can just say the network is here in this pretty small circle. So it's providing pretty accurate information and good information. It's more clear semantic than a single point. And so I think there is some helpful addition there.
The one I wanted to spend a little more time on is using http URI and directing this out of the database. People say any... interaction so maybe this one can too. But the idea is here, if we ?? the idea here is that the database by the nature of how it's structured imposes certain limitations, all of the go the same to everybody and they are more or less constant over time. You provision statically and it's a database, you provision a record and get served to everybody and that is not really the case if you want to provide privacy protections because different things to different people and you might want to provide some fuzzing or randomisation or different access controls that the database doesn't provide. There is also limitation just in terms of the sort of layout of the database in that it's very text?orientated thing, worry about things like international organisation which if you were to push this out into a separate service you have more flexible with and you have a little bit more openness in terms of what you can represent. So in the example here if I wanted to say my network is an Austrian nationwide network, I could draw joint circle around Austria but include parts of Germany and Czech Republic so that is not very faithful. I will show an example in a minute where we can say fairly accurately if we have this there is an XML scheme that has been developed in geoWorking Group to express things like national constructs, we can see this network is in Austria specifically, so you have that sort of flexibility. If you provide location through this external service. As opposed to in the database itself.
So, in terms of privacy, how does this story ?? how does this using improve privacy? And the name of the game here is that it takes the private stuff out of the RIPE database and the private stuff only gets handled by the people authorised to access it. On the back end in location determination provisioning, figuring out where a user is, that is a negotiation between subscribers and ISPs, the location server is being operated by ISPs and the location information itself gets provided to a third party only as point?to?point between the person using the data and the ISP, not between the database and the consumer. So the only thing the RIPE database will provide is this pointer to the location service so that the concept provider could go out and fetch the location information.
So, this much in the way that the geolocation field is supposed to give ISPs control over how content consent ?? in directing in this way gives ISPs over the privacy controls that are applied to their subscribers' location information. So right now, in the current prototype, they are subject to the NCC's database policies for how information gets passed around, who has access to information, and those are fairly open, and fairly universal policies without a lot of granularity. In this case the ISP if they chose to operate a location service in this way, could apply as granular policy as they want, and still have be able to advertise this service through the database.
Now in terms of flexibility, like I said the current format just by the nature of being in the database is pretty constrained in what you can put in there. You could put a will little bit more richness but can't put an XML document that actually has real space for richness and things that some applications find useful. So in the IETF there is a geoWorking Group that develops the protocol that handles geolocation information and a very rich XML scheme that has been developed so that scheme includes things like geodedic objects, polygons, circle actually came out of that, for the geoURI, ellipsis, arc bands if you are a GSM network and can do ranging from towers. There is lots of richness you can provide in terms of mathematical coordinate basis of description beyond just a point.
The other thing which is qualititively different from points and polygons and things like that is the idea of having civic addresses, the idea you can say instead of my users are in this polygon that describes Austria, you can say I am in the Hilton Vienna, I forgot to include Vienna here, and you can specify down to the river level if you want to be that precise. Part of the idea here on the last slide, if you as the ISP are operating this as your own service and your only talking to concept providers, you have an idea of who is asking for the information and you can provide different levels of granularity so you might only provide, you know, country level or post code level information to someone who just walks in off the street or you might have business partners for whom you will provide more accurate information. So the idea is that this, you have got this prototype right now that sort of is getting some good discussion going about what the value add of this geolocation information is, it demonstrates that it is feasible, it's not a complicated process to have an interface that ISPs can use to provision this geolocation information. But it does have these problems of semantics and what does this point even in terms of users and the network and privacy question of do we really want to expose this universally or do we want to have a system where we can have some additional controls. What I wanted to suggest in this presentation is if we have this, in allowing to allowing the direct presentation we might be able to ?? it might serve as a hook as a basis for providing privacy protections and a little bit richer express of geolocation. That is all I have.
WILIFRIED WOEBER: So thank you, Richard, for this sort of investigation and potential solution, and after this one I'd like to open the floor for comments or discussions. Go ahead
AUDIENCE SPEAKER: Shane Kerr from ISC. I think these are really excellent suggestions, I think this is cool technology. I was wondering if you had thoughts about RIPE's ?? RIPE NCC's role in terms of acting as a proxy so that I as a user don't have to run a separate tool to get the information and also the, if you had any thoughts about whether it would make sense for the RIPE NCC to also provide allocation server for people that again didn't want invest the resources as an ISP to set up the server?
RICHARD BARNES: Really from a technology perspective, you know it's very feasible, it doesn't matter who operates the location service at the other end of the pointer. If ISPs are willing ?? you can get those flexibility benefit, the richer description of location, if you are not concerned about privacy you just want the extra semantics then it's no problem at all for the NCC to operate it. If the membership agrees on the budget and all that. If you want to start using some of the privacy features, then there is the question of whether the ISPs doing provisioning is provisioning privacy policies one I have the RIPE NCC making sort of authorisation decisions on my behalf.
SHANE KERR: Right. I guess my feeling would be if there are any privacy concerns at all, that the RIPE NCC not be involved, that keep the RIPE database as fully open and public as possible.
WILIFRIED WOEBER: OK.
KAVEH RANJBAR: This indirect method, we discuss it had internally within our team, one of the things we see, is it three operational problems mostly, one of them is availability because if you want to provide a service it should be available and there is no guarantee that a client keeps it up, so this is ?? then you need a lot of operational or infrastructure or the customers need to keep it as a live service if we want to provide a reliable users of this service rely on. Another one is more general one: It's the geolocation data is not only user maintainable data on the RIPE database so then there will be a double standard. Why, if we are outsourcing the ?? why only the ?? why not the other parts that they can maintain? And there is already some ideas about that. I know worked on Whois for quite some time but didn't take off. There are also RFCs on that and things like that, but yes, it was never operational. And I think the basic question of that in ICANN they have the ?? registries and at the end I think again if you want to ask ISPs and providers, everybody to run a tool then I think it will help optic and, I like the idea of direction personally but I think operationally it will be close thing possible to make it ?? make the service run and have real users on it. That is my personal take on it.
SHANE KERR: Well, in the ARIN region they do use redirection and they do send queries to external servers so I think we have proof of it actually can work. It's not perfect I know there were problems in the past in the ARIN region because people would register an external Whois server but then not maintain it properly. I think that is not as big of an issue in the case of this data where we would presumably always be optional, so ?? I see there are some possible concerns.
WILIFRIED WOEBER: Well actually, to this sort of particular detail, discussion about availability, my personal take on that one would be that as long as we offer the very basic registration information about this resource on a very reliable basis, then we do not have to worry that much about the availability of these sort of icing on the cake services, which are not really the very fundamental and central responsibility of this registry but it's just my personal take on it, so first of all, thank you very much to keep us some sort of feeling about the potential to solve problems that were brought up on the mailing list. And I think this sort of prepares the ground for the more fundamental question that actually needs to be asked, whatever the detailed implementation might be, whether this might include indirection or not or whatever the real final blueprint for the service is, we have to poll the community actually whether the RIPE NCC is or this registry database is the right place to collect and to maintain that sort of data. I think it was very useful and very helpful that you did include sort of the backdrop like what the people in the street were already stating as their interest, but I am still not feeling convinced that we can just, as the database Working Group, simply go ahead and say oh, yes, we have got some sort of consensus, go ahead and build it. So I would like to poll the community on a very formal basis here whether you think we should continue this effort because this is going to take resources both on the RIPE NCC end as well as on the community end to develop these specifications, and living through yesterday and afternoon and evening, I think we have to face the fact that there are concerns in the community, that we are sort of doing a little bit of feature creep in the RIPE NCC might be task and mandated to spend less resources rather than more so I'd like to poll you, what is your feeling about it? Is this something you think it should be pursued in the framework of the RIPE NCC and the RIPE NCC services, or are we completely off track? Could I have any reaction to that, please? Or is the management summary: "We don't care"? Because what I really want to avoid is asking the RIPE NCC to continue to spend resources and to do that sort of thing, too far pilot implementation or even a pilot service and then the next ?? at the next GM say, oh, how did you go ahead and spend money on that? I think I have become a little bit more touchy than I was in the past after the events in ?? during this week.
SHANE KERR: Yes, Shane again. People really want this, like users are desperate to have geolocation information somewhere. It's not, in principle it's not necessary that the RIPE NCC be the place that this information is stored. On the other hand, there is a lot of things that the RIPE NCC does that could be done somewhere else, and I think because people want it so much it would provide some value to the Internet. I don't think the overall operational or administrative cost is that high. I could be wrong. I just ?? on a rough glance, it doesn't seem that way, so I would encourage us to go forward somehow with this idea. With the idea of putty geolocation.
WILIFRIED WOEBER: I am hearing you say we should at least continue within the framework of the database Working Group to work on the concept and to continue with the discussions, and to try to better understand what is reasonable and feasible and what should maybe not be done in this framework and then go back to the larger community and ask them the formal question. One of my ideas I had, was, for example, to ask Rob for five?minute slot on Friday during the plenary, and bring this question up. Of course, we could also sort of do it the fully formal way and submit a very simple policy proposal and work it through the formal machinery. I don't have any preference. I just would like to have some guidance from you folks.
SHANE KERR: The concern with bringing it up too early is that people get really scared when they hear about geolocation and stuff like that. I don't think it's too early, though, in the interest of open involvement and trying to be transparent in a more proactive way so I would think it's worthwhile bringing it up to the plenary.
WILIFRIED WOEBER: OK. Thank you for that suggestion. And building on that, and I think we should actually let you loose, forcing you to remain on stage. Of course, you are welcome to do that and to to contribute to this discussion but I don't want to put you on the spot.
I have got one maybe, again rather fundamental question to that whole thing and that is more like a question to the RIPE NCC folks here, whether they have thought about the question of who actually is allowed or who is responsible for maintaining that sort of data. Because like in my personal situation, I am having a small fixed address block, having that assigned by a service provider for my connection, and I guess I would like to have the opportunity to control this location information, but this might not necessarily be the way my upstream service provider looks at the situation and it might not be way the consumers of that data would want to have it maintained. Do we have any ideas?
KAVEH RANJBAR: Right now the way it's implemented because we have added two new fields to INET?NUM right now who is the maintainer for those objects is the control but it depends on the architecture, if you go in the direction Richard proposed ?? and I wanted to thank Richard because this is the kind of feedback I really like to see from the community ?? is so in that model, then provider even can decide sort of maybe they want to give, to give it very ?? to the end user and then give end user some authentication and you can always set it up or maybe as long as we are in this country you can change location. So it really depends also on the architecture. But current prototype is based on the maintainer.
WILIFRIED WOEBER: OK. I thought this would be the way. Thanks. Any other comments with regard to this aspect? Would any one of you want to have the control over this set of data? I would. Just a few. Minority. So the way forward, I think, I think I am going to have a chat with Rob. I think I am going to have a chat with the Chairs of the Services Working Group and then decide whether to sort of bring it up on the services mailing list or whether trying to put it forward on Friday during the plenary, and try to get some feedback, either positive or negative, and then let's take it from there. OK. Any other contribution to this geolocation thing? Personally, I think it's a fascinating thing but we have to ?? OK. Thanks to the RIPE NCC, thanks to Kaveh, to Denis, to Richard for giving us insight and this has taken us very naturally from agenda item B to agenda item D, because you had already included this thing in your presentation. I think we have covered more or less all the sub?items here, so I think we are doing fine timewise, as well. So let me go back to item C, internationalisation of the registry system. I think it is appropriate to give you a little bit of background where why it is started to become of interest about with me. As some of you probably know that I am involved in the Whois policy review team in the framework of ICANN which is mandated to have a look at certain assumptions, certain implementations and it's the framework that is sort of agreed between US government and ICANN. The very primary focal point of that exercise is limited to looking at the framework of the generic top level domain registrars and the interaction with the RIPE Whois ICANN, so this is not directly and at first glance applicable to the numbers registries. However, during the work of this review team it became more and more obvious to me that some of the fundamental problems we are uncovering in the names environment, more or less equally applied to our numbers registry system and that is the fact that we started out with these directory, what the resilient security and stability advisory committee in ICANN calls the directory services we started out to assume that the world is living in a seven bit as key environment. At that point in time when we started the whole thing, everyone agreed and all the tools actually implicitly or explicitly made sure that we are staying within that cage. The same, of course, holds true for the implementation of the RIPE database environment. So over time, both the environment has changed, over time the implementation of fundamental central parts of the database environment changed, were rewritten, updated, extended, so over time we lost these safeguards against using 8 bit stuff, which made us end up at the moment in the situation that there is lots and lots of 8 bit bytes in the registry data and looking back to Peter's presentation, I think two meetings ago, where he gave us a nice insight about the tiny little problems even within one country, one language and one script, we are actually having this problem in the RIPE service region because the participants in this community, I have identified at least five different script systems being used in that environment. That is the Latin one to start with, that is Arabic in the Middle East, that is the funny script system that is used in Israel and I was told recently by a linguist that even within these seemingly homogenous areas there is structure there is difference. It's not all the same. So, this was the backdrop.
And the question that I would ask you to actually think about and come back with a decision is, whether we want to ask the RIPE NCC formally to make sure that the whole system is actually consciously 8 bit?capable. I think we have to work a little bit on some details related to languages and to representation of things and stuff, but my feeling is that it is pretty essential in this new environment where we have, for example, check the correctness of a business address in some place, in the service region and then you try to do that and you get that stuff submitted in whatever funny version of whatever funny Latin variation of code page and at the consumer's end you are maybe interpreting the stuff based on different variant, so there is room for grief, there is room for problems, and I would like to ask the question here whether you agree with my personal point of view, that we should go ahead and ask the RIPE NCC to make sure that the whole system is doing the right thing and to track developments that are starting or going on already within the IETF environment and also within the ICANN environment. So backdrop, problem statement, my personal position of that, and any feedback from your end?
AUDIENCE SPEAKER: Yes, I strongly support that idea mostly because I was the presenter that was mentioned but I want to add to that: During the lunch yesterday, I was having a nice talk with the lady from JP NIC and she said that they have similar situation in Whois server is having data both in English and Japanese, so there are ?? some similar problems and they find a way to solve that, that is only one country and one transcription, but still, it's ?? there is problem, there is a solution to that.
WILIFRIED WOEBER: Yes. This is actually the valuable stuff I brought back from the interactions in this review team during the last week in Dakar where I had the chance to sit down with a gentleman from Pakistan who is really an expert in those things and he also said and confirmed that there are sort of ad hoc solutions which do work in a particular environment and they do work pretty well as long as you stay within the same cloud of assumptions. However, if you have ?? if you no longer have that common understanding, then you might end up up in interesting troubles. And maybe to spend a little bit, another couple of minutes with regard to this scripting thing, this is probably not that important for this service region because almost each and every one is living in an environment where there is character based scripting system, but there are other regions around the world where this basic assumption does not hold true, so you have got script systems which are syllable based which use different approaches to, for example, omit certain characters out of the alphabet, not even writing it, and using other mechanisms to find out what they have been or what they should be and then you think about things like Japanese approach or the Chinese approach. So there even isn't any longer a correspondence between a character and a sign. I mean, this is outside of our service region but just to give you a little bit of background what the problem space looks like and my feeling is that we should build something which can, in principle, support all the functions to serve more or less a global community. This is less, probably less essential at the moment for the numbers registry as it is for the names registry, but I think we could learn quite a bit from the names environment. Any comments?
AUDIENCE SPEAKER: Yes, just a short comment. I think that there are some ideas which could be implemented like four characters, common base and I think and there is interesting implementation in the ?? GD AP because LDAP could serve different data, according to different query, for the same person name or something like that. So there are some ideas which could be gathered together and maybe some other new ideas and that would drive the solution. And the second comment, also, you forgot about the Georgian alphabet because they have a completely different one.
WILIFRIED WOEBER: Thanks for that. And it's probably farfetched at the moment, but just think about the potential situations, someone wants to register reverse DNS name service for resources being maintained in a RIPE database and this thing happens to have internationalised domain name, so it's easy to do that in the labour field in the label field in the DNS environment because there is this XN?? notation but and I am pretty sure that you could actually ?? the RIPE database environment and probably the reverse delegation robot can work with such a label. But if you look at that, as a human being, you might want to see sort of the original name and not the XN?? thing. So there is lots of interesting stuff. OK. So any comment from you?
KAVEH RANJBAR: A bit of technical background on the current situation. So what is happening right now is the database core is encoding ?? it just stores bytes so the core really doesn't care about what kind of data is going in. Most of the data are already in actually, I can say for sure more than 95% of data we can actually do a research on that, is fits in the 7?bits area still. We have some characters which are presented in different encodings, most of them Latin one, so we have some data in Latin one. Right now, the Whois protocol, so the common line there is no encoding so it's based on your terminal if you are using Whois, but if you are using any web tools like syncupdates or web updates or web queries, our server prefers UTF8s, so it will offer UTF8 and prefers for answer, syncupdates accepts UTF8 and Latin 1. The rest only accept and provide UTF8. Since Latin and UTF8 have big overlap. We don't have major problem, there are some problems for data that are submitted with different encodings but we see users are also taking care that have so we see people are updating data to change it to UTF8 but if the storage we don't store it, so right now we actually, I also support this personally again, because I think it's ?? it's good to have at least some policy to say, OK, only Latin one or only seven bit or UTF8 but when we have clear mandate on that we can enforce it.
DENIS WALKER: RIPE NCC. I think maybe you need to ask yourself a different question here; technically, we can give you anything you want, so we can rate the entire RIPE NCC on all database and tools around it fully UTF8 compatible but maybe the question you need to ask: Who is the consumer of the information in the RIPE database, who do you want to be able to read that information? Is it acceptable to have information in there which only a small subsection of the RIPE community can actually read and understand? How would the RIPE NCC do a 2007?01 type project if half the addresses and e?mails and everything is in character sense we can't understand. So maybe before we look at the technical, which we can do, you need to think at it from a policy point of view and do you want to have bilingual information in there, the option where you can put it in any character set that is local but also requires certain fields to be done in English as well, so I think there is a lot of policy information or policy decisions need to be made before we really get too far down the road on a technical implementation.
WILIFRIED WOEBER: Yes. I think that is very correct, thank you.
AUDIENCE SPEAKER: As far as I remember from my original presentation that was the main goal, to have mandatory English fields and optional multi?lingual corresponding fields, because one of the users of our database is definitely the law enforcing agencies and that could help them, and this Japanese example is very crucial because as far as I remember from the talk, the Japanese use ?? use the Japanese version and the JP?NIC export data in English because it's very easy to the APNIC Whois, so they have both versions for international users and for local users so definitely, both versions, required English one or ?? and optional for those who can, so that is the one comment. And the other one is for those numbers which have been presented of 95% of data is currently in the Latin ?? sorry, in the ?? seven bit form because we are used to it. If people get the mechanism to put the international data, I think they will start using it.
WILIFRIED WOEBER: OK. Thank you.
AUDIENCE SPEAKER: I am the Japanese who has been referred to. I thought I would share our experience. I am from JP?NIC. And as the gentleman earlier mentioned, we do have database that is information both in English and also in Japanese and we mirror with APNIC database so the English part is sent to APNIC and people can also directly refer to our database and non?Japanese people can simply use /E after the Whois query, so they can only extract English information and for those Japanese users, they are able to search information in Japanese, and it seems to be working pretty well, but I also see the point that was mentioned earlier, that is since RIPE NCC is not only serving one country, you are serving the whole region so you really have to see the balance between like serving people of certain economies or you just like take for what is the best for everyone. It's easier for us because we are national based and we collaborate a lot with APNIC on information marrying.
WILIFRIED WOEBER: OK. May I ask a little question to that for a detail: Which party is providing the English language version of that information? That provided by the registrant, by the people who receive the resources, is this information provided by the national reg gee or APNIC or created automatically by way of some translation mechanism?
AUDIENCE SPEAKER: It's provided by the registrant. So it's a part of the template ?? it's a mandatory field both in English and Japanese, and that would avoid us misinterpreting information.
WILIFRIED WOEBER: Thank you. There is another gentleman coming up to the microphone.
AUDIENCE SPEAKER: Yes, from APNIC. Our experience handling multiple language culture and characters, as well, is we, APNIC, would stick to English, basically, and supplemental information can be added to it but basically because we are serving ?? I think referring to Denis' point there, that this is a global registry that we operate and we can't assume that people who read APNIC database actually comes from APNIC region, actually our help desk was handling complaints mostly from the United States, so APNIC at the moment sticks with the English version and our national Internet registries and we are ?? we are perfectly happy with working with other organisations that can supply local language that will help the local communities, so I think that is the strategy, but if APNIC is relying on RIPE Whois database code, if the RIPE Whois database code has the ability to handle UTF8, that would actually be helpful for our community who wants to create this alternative registries in their language and because it's also, say, written by RIPE, then the issue of mirroring, of replicating, is ?? would be solved. So I support this initiative, basically, of allowing RIPE code base to be multiple language, multiple character has this ability. But whether we are going to have, you know, everything in one database of or have multiple database that master different languages, it's just a deployment issue. Thanks.
WILIFRIED WOEBER: OK. So we seem to converge towards sort of a mandate for the RIPE NCC, sort of to investigate what would need to be done or whether there are any pockets of this whole system sort of which need a brushup to do the right thing, and as soon as possible but not with the top priority, as soon as possible sort of come back with some sort of statement about current situation or things to do. What I am certainly going to do is to track this information, or this development or this problem space, sort of with the hat of this review team. I am in for a little bit of more learning when it comes to character certificate, languages, scripts, pretty interesting stuff, and report back to the Database Working Group. Thank you again to everyone who has provided some input in this one. Thanks to the RIPE NCC, for example, for sort of listening to us and standing through this thing. And this gets ?? maybe a little bit I forgot to mention that gee low location again, in this agenda there is URL for RIPE Labs article on this thing so if you want to follow up on that, here is your link. And this gets me to the agenda item H, input from other Working Groups and task forces. I am not aware of anything at this time that is coming in from the outside. Is there any other chairperson in this room who has to advise us on anything database?related? Oh, yes, Brian. I am just a simple member of the task force. Simply in many different ways. Thank you.
BRIAN NISBET: I am just a simple chairman. Brian Nisbet speaking as chair of the Contact Management Task Force. As was raised in the anti?abuse ?? as reported in the Anti?Abuse Working Group yesterday, it's expected that the AC MT F will will be reporting ?? will be proposing something in the next couple of weeks which will be dropped into the PDP, which will be loosely a required abuse contact in the database. All of the details and all of the discussion will obviously take place on mailing lists and people can look at that and tell us what they think. That is actually a point for the multiple character sets in the database, as Rob just mentioned to me there. What happens in all of the abuse contact information is in sir I will I can. How do I contact people, but that is again something for that conversation. But yes, the proposal will be coming in next week, I would suspect, and we will make very, very sure that that announce is copied to the database Working Group mailing list as well.
WILIFRIED WOEBER: Yes. Thank you, Brian, and it's going to be pretty formal policy development process thing.
BRIAN NISBET: Full thing.
WILIFRIED WOEBER: OK. Last item on the agenda, any other business? Yes. Please go ahead.
AUDIENCE SPEAKER: David Freedman from Claranet. I have got three things that I want to cover. The first is a question, first two are questions and they are related to items from the last database Working Group meeting. The first of these is the issue of MD5 and SHO. I believe there was a action point to collect some statistics and I wonder where the results of those are and whether any conclusions drawn on that?
WILIFRIED WOEBER: I think we had the figures in the database presentation, if I remember them correctly it was some 89 or 98 percent ?? 86 percent, and the subcategory was even bigger than that, so this gives me the feeling that the big majority of the resource items are actually only protected, protected double quote, by MD5.
David Freedman: What are we going to do about that then?
WILIFRIED WOEBER: It's your turn to suggest a way forward. Do I have any personal preference and point of view and that is digital signature technology is around for about a decade by now, it's pretty ?? it's pretty deployed in different areas ??
DAVID FREEDMAN: The problem still stands there are all of these hashes that published and forcible and we haven't attempted to solve that problem yet and I think it's something we really should solve, if the next thing is putting forward to and proposal to do something about it, that is what I guess we do.
WILIFRIED WOEBER: I think there are two potential ways to attack the problem: One of the ways is actually to suggest to hide the hashes from any sort of output, which is ?? which would be a very similar approach to what we did a while ago with hiding contact information during a regular Whois query, which gave us quite a bit of grief operationally because people didn't sort of know that when they take the output of the registry database as the primary copy and make modifications and put it back they are losing information by not doing the right thing. So I am worried, but it's personal worry. I am not saying that as a chairperson here but personal point of view while technical it would be very simple and straightforward approach it would give us a lot of grief on the help desk side and the other approach I could see and envisage is to sort of discourage phase out, prevent the use of simple passwords, whether you ?? whether you solve that a bad idea of publishing the hash, I think is a secondary thing.
DAVID FREEDMAN: Sure.
PETER KOCH: I guess what Wilifred did was less offering a solution rather than making the problem statement and I was going to suggest that. So while some people agree there was some bad things happening we didn't really agree upon what the badness was and what the real problem was, so there are competing solutions or not yet proposals on the table but let's first agree on the problem statement, please.
DENIS WALKER: RIPE NCC. The statistics we gave clearly show that people use passwords more. I won't say prefer, because we don't know why they use passwords rather than anything else but the simple fact password is the majority. If the problem is not the password but the fact that the hash is public, then we need to look at addressing that problem, and internally we have talked a bit about this and we could come up with a proposal with some ideas on what we could do to solve that problem if this is what you consider to be the problem.
WILIFRIED WOEBER: Yes.
DAVID FREEDMAN: The problem space that we have been discussing a is that of the fact that there are hashes there that can be trivially brute forced and somebody can take malicious control of objects. I didn't imagine that there was another problem that we were trying to solve.
PETER KOCH: I think the other problem or the part of the problem is that we ought to look at the whole provisioning chain and the presence of the representation of the passwords in the database by way of hashes, is one thing; the other issue that remains, even though remember we have SSL, TTS protected mail on the last HOP at least, the other issue is that the passwords are there presently and clear text upon submission into the database and maybe we need to take step back and look at the whole provisioning system and maybe prioritise the different issues but maybe we want or the Working Group wants or whoever wants making a kind of a quote?unquote security acement there and be complete in the acement which doesn't suggest we do step three before we do step one, but get the global picture and then prioritise and work one at a time. But not just focus on this single thing.
RANDY BUSH: IIJ. I am just curious, does anybody in this room think clear text passwords are reasonable or safe?
WILIFRIED WOEBER: I don't.
SHANE KERR: I think most users are going to use web updates, which is a secure channel, so it's a plain text password but it's over an encrypted channel so I don't see a big problem with that.
AUDIENCE SPEAKER: There are a lot of users still sending mail with clear text passwords.
WILIFRIED WOEBER: Probably doing that from a Gmail account and the a copy of the password is sitting somewhere on the desk.
DENIS WALKER: With e?mail, yes, do you have to send your clear text password in the e?mail but there are alternatives now with syncupdates and with our restful APIs so there are alternatives coming on?line which can be used not just for the occasional user who has one object to update in one updates with the API bulk users and heavy users of the database do have options which are more secure. Bush do not leave the gun lying on the desk. This is an unsafe practice. We are putting users on the easy path to jeopardy. Don't do it, please fix it.
SHANE KERR: I think I proposed on the list one possible halfway point would be disabling passwords in e?mail and leaving them for web users.
DAVID FREEDMAN: I think the problem is, the passwords where they are still published and hashes are, once you have been able to brute force the content of the password out from that it doesn't matter which mechanism you use to update it.
SHANE KERR: Fair enough.
PETER KOCH: Now getting into trouble. So this sounds like we are again addressing these different pieces of the picture one at a time, so somebody should, now the part where I get in trouble, so some people should sit together and draw small picture maybe with the help of the NCC and I look at Denis over there, and then identify the crucial issues and how they interact, passwords may or may not be so crucial. Guns are mostly harmless unless you have bullets, you can still throw them and then identify and suggest a path forward. I am not going towards doing another task force somehow, but yeah. You are Working Group chair, go find volunteers.
WILIFRIED WOEBER: OK.
DAVID FREEDMAN: Again from the minutes of the last database Working Group meeting, I raised the issue of the publishing of the reg ID for all resources associated with the registry and this is separate from the organisation object. The organisation object is a separate solution to a separate problem, for PA, PI, end user resources. The last we had in the minutes was that this was going to the Anti?Abuse Working Group. I had a brief conversation with Brian earlier in this meeting and ?? Brian, do you want to ??
BRIAN NISBET: I had no knowledge of this. If I was in the room when this was decided, I clearly wasn't paying attention, but I don't think I was in the room. And I don't think anything was raised to AAWG. Now, if somebody has evidence that a mail was sent to me and I said yes we will look into that, I will apologies profusely and look at it again but I have no recollection of that and I am not sure entirely sure why this is being punted to AWG unless it's specifically an abuse thing, why is this not a database issue?
WILIFRIED WOEBER: I am not sure where it would actually belong because I think this is actually something aside from the technical implementation which I presume is just a couple of lines. That it's actually a thing that exposes business relationships.
DAVID FREEDMAN: I have spoken to a number of people in the NCC and, you know, just from the quick conversations we have had, doesn't seem to be anything ?? any real sort of OKs to this. I mean, there are some people that are unhappy at the concept but ultimately, there doesn't seem to be any real ?? obviously, counsel needs to go away and work this out properly but from what people have said there doesn't seem to be any objection. The second point, when you say it's just a few lines in the database, from speaking to people it probably isn't because your database is quite relational and just having a string with UK Claranet in it it's probably not great, is it?
KAVEH RANJBAR: Yes, there is wanting just to explain, the reg ID used to be internal representation, mostly used by NCC but each registry has an object which is retained by RIPE NCC and we have a one?to?one relation but the concept of reg ID is not used anywhere with the outside of the NCC except for the portal ??
DAVID FREEDMAN: When I take something that belongs to a direct end user assignment and I create an object organisation for them and publish it how does it tie back to my organisation?
KAVEH RANJBAR: We can put your organisation as well, I am not saying that, I am saying the wording of reg ID, there was one to one ??
DAVID FREEDMAN: If I look at my organisation object I don't see anything in that encodes my reg ID. If you are saying it isn't necessary it's only completely internal, I still look through the portlet and multiple registries I have, so for me it's still reg ID, not as internal as you think.
KAVEH RANJBAR: Exactly. From a portal user point of view that is how we authenticate portal users but other than that reg ID is ?? one to one mapping and data which we keep on keep file is synced automatically with that. If you send a ticket to ??
DAVID FREEDMAN: If I can quickly define the problem space there are resources and I want to know who the owning or the sponsoring LIR is for those sources regardless of how it's done, that is all.
KAVEH RANJBAR: Yes.
WILIFRIED WOEBER: Just processwise, I have to bow my head to you, I forgot to put it on this thingy, because it came up in a different context and I would like to see some sort of solution for that one as well. I forgot to put it up in the new version. So my proposal is to actually keep on that one and use the mailing list to do the kicking and the pushing.
DAVID FREEDMAN: The third one ??
WILIFRIED WOEBER: We have four minutes.
DAVID FREEDMAN: I was looking at tidying up some resources to return them to the NCC and when I was looking at autnums I found actually if I have got ?? I describe a relationship with another autonomous system and I want to return this autnum I have got the problem of the other organisation still referring to me so I can only find of find this out in a half?hearted way using free ??
WILIFRIED WOEBER: Referring to root object?
DAVID FREEDMAN: Routing policy.
WILIFRIED WOEBER:
AUDIENCE SPEAKER: He is trying to do a reverse query on the import/export attribute in the autnum object for AS number, and I would think this a bit further because there is no way to do inverse query on the invert for AS set object that I want to remove.
DAVID FREEDMAN: It would help us if we could tidy up these resources so we could return them, that would be great.
DENIS WALKER: There is no, at the moment there is no option to do an inverse beyond these and no ?? I think it was decided in the first place that these things can be referenced in so many places would you never be able to delete your autnum object if you had to delete all the references to it first, at the moment you can still delete it and still leave those references lying around in other autnum objects.
AUDIENCE SPEAKER: We are trying to be complete here and trying to go as far as we can. It's a best effort thing.
WILIFRIED WOEBER: I ask you to reraise the thing on the mailing list and we take it from there. Thank you. So, unfortunately, I have to close this session right now because there is some other stuff going on in a few minutes from now. Thank you very much for the contributions. Thank you very much for allowing all of us to remain within the allocated time frame. And I hope to see you either on the mailing list or next time in Slovenia next spring. Thank you. Session closed.
(Applause)