These are unedited transcripts and may contain errors.
The Database Session commenced on the 8th of October, 2009, at 9 a.m. as follows:
WILFRIED WOEBER: So good morning, folks. Could you ?? I know, I know. Good morning everybody. Thanks to all of you who made it that early in the morning, not on Friday morning this time but on Thursday morning this time. Welcome to the database Working Group meeting. I am Wilfried Woeber, I am trying to keep us on track within the database Working Group. On the display here you can find the most recent version of the draft agenda for today. I just recently circulated and uploaded the version 4 of it. There is not too much change compared to the version 3 that was available for a few days already. We have another bullet?point by Peter on some suggestions, some ideas. The structure of the meeting is as usual. We start with administrative matters. I would like to extend my thanks again to Nigel Titley for offering to do the scribing. Then, we have got these microphones next to the rows of chairs so if you want to contribute, then please walk up to the microphones, state your name and whatever you want to contribute because we are webcast.
The next thing is and I think we also have someone from the RIPE NCC listening to Jabber and whatever. Okay, thank you.
So whenever there is anything then please signal me. Thank you.
Next thing to do is finalise the agenda. Is there anything you want us to add, to remove, to reshuffle? No, I don't see any indication. So then this is going to be the agenda for today.
And the next item on the agenda is approval of the minutes from the previous meeting, from the 58. Nigel had circulated them on the mailing list, I suppose they are already available from the Working Group's website for a while. Is there any comments to those minutes to, those draft minutes? No. Okay. Then they are the final minutes.
And we move on to review of the action list and I'd like to ask Nigel to take us through the list of open actions and I will take notes in the meantime if there is anything important here which is not covered otherwise.
NIGEL TITLEY: It's hardly worth it, as you will see in a minute. And I still seem to have the background from last RIPE meeting which says "birth" all over it. Never mind. Basically, we have just two open actions, which is quite amazing, and I suspect that the first one is going to be dealt with as part of the agenda, that is the cleanup of orphaned objects. RIPE NCC, is that complete now or is it still ongoing?
AUDIENCE SPEAKER: Still ongoing.
NIGEL TITLEY: Still ongoing, so we still have one open action. Okay.
And then 58 .1, RIPE NCC check that AS US E D can support IPv6. Can anybody from the RIPE NCC report on this? Anyone know? AS USED? No. Okay. So I think that one will have be ongoing, as well. And that is it. That is me, done.
(Applause)
WILFRIED WOEBER: Okay. Thank you, Nigel. And thanks to everybody involved to help us get this list down to just two entries, which is pretty nice. And I'd like next to ask Paul to give us the update on what is going on around the database from the point of view of the RIPE NCC.
PAUL PALSE: Good morning. I am Paul Palse, the manager of the database group and I am giving you the update today.
I will first start with introducing the database group to you, and then I will go into what we have been doing since the last RIPE meeting and I will give you some statistics on operational data and I will also take back the points that we have taken back from the data Protection Task Force meeting last Monday and then we have time for questions.
So the database team, this is us, we have a new colleague who started last Monday, Benedetto. Our stakeholders you, obviously you via the various Working Groups, and via customer services and registration services and internally we have the various departments within the RIPE NCC.
What have we been working on since RIPE 58? Action point 54.3 which was making maintainers mandatory on person and role objects. We have completed all the coding for it and the documentation is also ready. We still need to deploy a test environment, we first planned to deploy a test environment for it so that you could test any script in it you may have built around the RIPE database. This, we didn't finish that just yet and we will deploy that as soon as possible after the RIPE meeting. This is the page, the booth strapping script that allows you to maintain.
Action point 54.6 the clean?up of the unreferenced persons. We suggestion penneded that right after the RIPE 58 meeting. We presented it and started it and gave you some statistics on the increase of the daily batches that we would delete. Out of the previous meeting came the action point of making sure that NIC handles could not be reused and we felt it was wiser to stop cleaning up unreferenced person obs before we would actually implement this and then restart it afterwards (objects). One of the points of criticism that we could take?home is we may not have communicated everything well enough. So what we will do right after RIPE 59 meeting is send around a little bit more information on why we stopped the clean?up procedure and maybe a little bit more around the implications of it before we restart it again.
Action point 54.7: Deprecating web server attributes. In the last meeting we presented the fact that we had changed the business logic, no longer to allow you to enter graph server attributes in AS numbers, so that you could turn them into remark fields manually. We now have made a batch update of the remaining objects that had a web server attribute in there and turned them into remark lines and we found that approximately 105 objects were changed.
So there is some various updates. Also, in previous RIPE meetings we presented a new hardware platform. Last meeting we showed you that we were ready to deploy it. We have deployed almost everything. There are some minor or smaller services that we still need to migrate but that will happen without any operational interruption.
Making ?? removing personal data from split files in the NRTM stream. NIC handles are considered to be personal data so we had to remove those also from these externally facing services. The software for this is all ready again, documentation is ready and also for this particular change we would first like to give you access to test environment, so again, you could test your scripts against it and we will deploy that test environment also as soon as possible after this meeting.
And then we come back to not reusing NIC handles. This was ?? this came out of the data Protection Task Force meeting of the RIPE 58 meeting, and then we discussed it during the database Working Group session. We had the idea to allow you to choose the prefix and we would generate a number and attach that to it. However, we found a more elegant solution that would not change anything; you can still choose your own NIC handle; however if it exists before or exists, we will just return a message asking you to resubmit a new creation with a new unique NIC handle. This code for this change has been deployed on the 10th of September.
Mirrors: In the last RIPE 58 meeting, again, we acknowledged the fact that mirroring is important to you and we took home the task of improving the service. We have made a list of how much out of sync we were and found that APNIC was the most problematic one, addressed that. We got access to their split files again. We reloaded the mirror and we will do that for every other mirror that we hold and after that make sure we improve the service and keep the service appropriate. Currently, the APNIC mirror is not still out of sync, we still need to deploy the database so that is also something that is on the list to do for us.
So the operational update, some statistics: This is the customer service people that answer your queries. They are our first line of support and they escalate any questions to us. These are the average amount of tickets per month between the various RIPE meetings, so between RIPE 57 and 58 is blue lines and orange lines is between last meeting and this meeting, and rather stable with some decreases.
Statistics on the RIPE database: RIPE queries per minute, going strong at 6 and a half thousand a minute. We also like to show you the IPv6 service or service over IPv6, and in the last meeting it was less than 1 percent of the queries. And actually, this meeting it's over 6 percent of the queries we receive over IPv6. Then, how do we use our query methods, how do you access the queries? Primarily over Port 43 or Whois clients. There is a decrease in the proxy access and nothing spectacular there.
Then we did some mapping using GOIP, so where do people query from, from which country? And there is various changes in order.
How frequent do individuals query or database? Well, it's still primarily ad hoc queries and there is only a handful of IP addresses that query our database more than 1,000 or 10,000 queries a month.
Successful Whois updates. Let me say something about that gap. We deployed our new platform and we only re loaded the graphs from the beginning of the year onwards and obviously when time goes by, this gap will close. We have an average of updates messages of 8 per minute. We can easily handle that. And most of the up dates are still received via e?mail and sync is actually all the other methods of updating the database and we ourselves also use sync. And then most of the messages are successful. 30 percent of the update messages fail, maybe we could probably ?? it is a considerable amount, but we could probably also attribute it to the fact that deprecated ref server and made some changes and some people may have found they didn't know about it and some messages a little bit higher amount of messages filled. And then, obviously, we are also operational department so we like these figures. Last meeting there was a drop in the mail update service but that was due to the fact that monitoring service reported some false negatives but, this time, we have the glorious numbers of 100%.
So, the data Protection Task Force highlights, there is two outstanding ?? items we still need to review, review policy and proxy access service agreement and we also actually found our mission is completed, so the task force will be closed down.
There is two more items, things to clean up. We still have the tasks of addressing the forward domain objects. We have to work with the TLDs that still use our database for provisioning and that is something that we will be doing, we need to work and see how we can help restore it elsewhere and then clean up those objects. And maybe Wilfried wants to say a little bit about improving...
WILFRIED WOEBER: Yes, the background is that there is a small loophole in the structure which probably just very few of us will ever notice but, still, it's something which should be attracted. For those of you who do understand, the delegation tree in the reverse DNS structure, there is delegation points at the /8 level, at the /16 level and then at the /24 level and if you happen, and that is particularly true for legacy address space; if you happen to have a delegation point at the /16 level, then in some situations you can actually manage to register an additional reverse domain object in the database which is on the delegation level of /24. So that is syntactically correct and it's probably semantically correct what you put into the database but it will never have any effect, because if you do the tree walk from the root you hit the delegation point at /16 first and then you sort of move over to a different server, so the things that are below that level will never be queried or become effective. And if you have to do a little bit of debugging, if something goes slightly wrong, then you get completely derailed by seeing different things, different answers, depending on where you throw your query or your analysis at and this is actually something which we think that the database should actually prevent registering information which is ineffective, which is never looked at and which can actually sort of distract you from the right path. And that is the background. I don't know, Peter, if you want to add anything to do.
GEORGE MICHAELSON: George Michaelson from APNIC. Obviously because we have a large dependency on the RIPE Whois code for doing our reverse address delegation management we have also discovered this. Our zone creation processs are radically different to yours and because of that we had introduced pre and post processing phases that simply removed this but we had been exposed to this issue and I thank you for any structural improvements you can make which will make it impossible to precreate these objects. I think that is very, very good initiative to take. Thank you.
PETER KOCH: Peter Koch, co?chair of the DNS Working Group and this was brought up by an and in the DNS Working Group last time so it caused operational problems at the NCC and other parties to start with and resulted in tickets with the NCC. And we had a look at that and the point is the sole purpose of these domain objects present in the database is not documentation; the only purpose for them is to feed that zone provisioning process, so there is just no justification to keep this stuff and I just had a look and if I am not mistaken this is not only true for the v4 reverse space but there seemed to be rare cases, well they are only, reverse delegations for v6 anyway but let's not go there, but both should be dealt with at the same time, probably, and yes, thank you for taking this up and making this a bit less of a surprise to the operators. Thanks.
PAUL PALSE: Maybe we can move into question time.
WILFRIED WOEBER: Just as a formality to follow up, I think we should log a formal extra item on the RIPE NCC to have a look at that and either to clean it up or report back what the situation is or what we could do. Is that okay with you?
PAUL PALSE: That is perfect.
GEORGE MICHAELSON: I apologise if any aspect of our service delivery of Whois is impeding the mirroring. Please talk to a soft line, if there is anything we can do to help resolve the imbalance between our respective database states.
As a point of information, we are in very close to the end of a fairly major internal software exercise to make our modifications to your code base operate against the current head state as we last saw it, which will bring us much more tightly into line with your code base, we will gain the benefit of all your investment in developing native v6 query support. I was extremely excited to see as much as 6 percent load in v6. Based on all the discussions we have about usage of v6 at application level, that is possibly the highest single measure of active v6 service delivery I have ever seen. I think that is an amazing number. But hopefully, when we come close tore your current code state we will be in a much better state to maintain some consistency and we thank you for your continued support and development of this product. Thank you.
WILFRIED WOEBER: Okay. Any other questions to Paul regarding the presentation? If not, then I would like to come back briefly to the two bullet?points like the data Protection Task Force. The thing is winding down. We still have to review I think two documents and just to get back to the RIPE NCC with feedback, well that is actually what we wanted it to look like and then we will formally announce, probably by way of Rob, that this task force is actually closing down. Anyone wants to ?? anyone who has been in this task force who wants to add anything to that? No. Okay.
The other thing I'd like to come back briefly is the management of removal of unreferenced objects. The reasons why we brought it up again here is something to look at and formally put it into this presentation, is that we want to make you aware, everyone, you, me, us, that this removal of unreferenced objects is not limited to personal role object in itself but there is also the mechanism, it's an inherent mechanism, that, also, clusters of unreferenced objects will be removed and those clusters will include maintainer objects, and in the past we had sort of this vision that a maintainer is something which is stable, so this is probably something which we will try to make very, very obvious in whatever explanation and description of the process you are going to put forward.
PAUL PALSE: That is the idea, yes.
WILFRIED WOEBER: If any of you has any strong feelings or input to that one, now is the time to speak up, because the way to go forward is actually to do another round of information campaign and then to start this operation rolling and while some of us have asked and have suggested to RIPE NCC to suspend it again for a short while, this is definitely going to go forward.
PAUL PALSE: Absolutely.
WILFRIED WOEBER: So please be aware that things are going away, unless you do the right thing, and the right thing is either to reconnect your maintainer or roll or personal object to real registration pieces or to use the RIPE pages service for individual persons. It is there, and it was actually implemented to sort of provide you an alternative method to remain in the database. That was the task force thing, that was the unreferenced object thing and I think it was everything I had on my list to fill in and to add. So unless there are any other comments, thanks to Paul for the update.
(Applause)
And we are going to continue with maybe short discussion regarding Shane Kerr's proposal or request or suggestion to think about restructuring the on?line documentation which is related to the database operations. I don't know if anyone has followed this discussion. Shane is here so I'd ask him to actually give his point of view.
SHANE KERR: Hi, so I don't actually have a presentation about formats but if I can pull up a browser. The thing is, when I look at documentation on?line, when I use a web browser, I can do things like resize it and I can read it in a continual text like, I don't know, let's find documentation. So you see, you can kind of scroll down and see the entire table of contents and quite happily go to a section and read the whole thing, it's very straightforward.
When you go to some ?? and it's very natural when you are working actually with a reference to have it in a format like HTML, so this is how we use the web and spend most of our time. Now, if it's a ?? sorry, it's a Mac. If it's a PDF document, then it's actually a bit more cumbersome. It's really nice if you want to print it out and read it on the train or something like that, but we have one database document now and it actually has no content. It just tells you to go and look in the database document library which is all PDF, so now, I had this nice paginated version and I have to kind of click over here on the right and table of contents is broken up and it's not ?? it's not a major problem but it's just a lot less handy and I can't really resize it very nicely. I can maximise it but I can't make it small or I can actually work on the database, which is what I want to do. Anyway, that is long way of saying please put it in HTML. I think PDF is great and does exactly what it's meant to do. If he could go to Microsoft and click safe as HTML that would make me happy.
WILFRIED WOEBER: Okay. So probably a question to RIPE NCC people: Do you think that this is a major effort to try to do the thing or ??
SHANE KERR: I have that question, sorry, I am interrupting ?? but I don't remember, maybe I wasn't paying attention, I don't remember when it changed. I don't use the database documentation very often so last time I used it it was available in text format and now it's available in PDF.
Denis Walker: RIPE NCC. I think the reason it changed wasn't by design perhaps more by accident. I think we agreed to drop the RIPE documents status on the manuals, the idea was every time we do a software change we can very quickly roll out a new version of the document.
SHANE KERR: This sounds familiar.
DENIS WALKER: More by accident it happened we only produced a PDF and somehow dropped the conversion to HTML. I had a brief chat with our coms guys before the meeting, we don't see any problem in producing it in both, so, yes we will take this on board and go back and look at it again.
SHANE KERR: Cool. Thank you very much.
(Applause)
WILFRIED WOEBER: Then the next thing on the agenda is to formally come back to message on the mailing list regarding the sort of public disclosure of password for the routing registry maintainer. Personally, I don't have any strong feelings about this one because the purpose of this mechanism is well?documented, it is ?? it has been there since the introduction of the RPSL stuff and RPSS, but as this was a request on the mailing list, I felt it is appropriate to bring it up for this meeting. So, if anyone has strong feelings, please speak up. If this is not the case, I think we acknowledge the message on the mailing list but we don't see any need to follow up on that one or to expend any effort in changing stuff. Anyone have any input? No. Okay. Thanks.
Which takes us to the proposal or suggestion by Peter coming up with a few slides regarding ideas and proposals to make some mechanism in the database more useful and more straightforward and I think you have prepared a couple of slides. So the floor is yours.
PIOTR STRZYZEWSKI: Hello everybody. Together with my colleagues we would like to introduce a proposal for searching the key cert objects with the owner attribute. There is, right now, no possibility to search such objects with the owner attribute and owner attribute is quite important and human readable because it's generated directly from the certificate, we can't search it ?? we cannot use it to search the objects, as we can see. That is the excerpt from the query. So the proposal is to modify the DB software to enable such lookup and in our opinion, there should be possibly some kind of searchers. We should be able to search using e?mail address for both X509 and PGPKEY certs because there are two types right now with full name for PGP, with CN value for X509 and we are thinking that should be full and partial search, I will explain that later on the example and as an option because we are not dedicated to that piece of proposal and the full value of owner field should be also possible to use for the search.
So, example: I took up two extracts from the database dump. They were probably the first two in each category. And as you can see, the owner field is quite different in PGP and it's 509. In PGP it's quite simple, it's the owner and e?mail address, as far as I remember there could be common but I am not sure right now. In the owner, we have the attributes, country, organisation, organisation, common name and e?mail address. And for me, personally, common name and e?mail address is the most interesting part of this field.
So, the proposed search methods should be Whois and as you can see, the e?mail address, well, basically speaking e?mail address for both cases are exactly the same kind of query. The third thing is the full name, address for the BGP. The next two queries are the queries for these 509, for the common name part and the first is the full common name and the second one is the part of the common name and I think it's a nice way to search for the certificates issued for all members of the LIR because the structure here is the LIR do the user name and that is basically the idea behind these partial search and as an option, as I said before, the full value of the owner field could be used to search key cert object.
Pros and cons: For me the pros it will be easier to find certs. I was looking some weeks ago for my own cert because I forgot about it, and I was surprised that I am unable to do it in a very simple way and the solution was to download the database dump and just grab it and so that takes some time. There is as far as I remember with the with the search on the website, there is impossible to search key certs, so in my opinion, that should be also, somehow, improved. And there is, of course, some kind of concurrent search is full value. If I am, if I want to search for typical John [Doe] and put a Whois minus T person John D?O, not Doe, I will not find him. So it's full value. And my proposal is somehow partial, so it is either ?? it either needs to be changed to the software that allowed the partial searches but this could influence other searches, partial searches of persons and so on, or the new flag is necessary to support this proposal. I am not sure which of them will be better for me.
Any questions for that?
WILFRIED WOEBER: Peter?
PETER KOCH: Peter Koch, DE?NIC. Speaking in personal capacity of course. Could you go back to the slide with the headings "Examples 2."
I probably missed that. For the first big bullet item proposed search methods the difference between the last two examples, what is the intention there? So ISNick.4HS, that is the common name?
PIOTR STRZYZEWSKI: Yes
PETER KOCH: You want to be able to search by common name?
PIOTR STRZYZEWSKI: Yes.
PETER KOCH: The next one, what would that be?
PIOTR STRZYZEWSKI: I want to have the possibility to search for beginning of possible name. The LIR dot user name. My own is PL dot user name is here is IS from Iceland, yes, Nick and something like that. I would like to see all the key searches.
PETER KOCH: Understood. I think, generally, that might be a good idea; I mean, having these certs being searchable. I haven't thought about the down sides there. I am a bit concerned of any method in the database that could reveal personal databased on this wild card kind of queries, be that hierarchical or otherwise. I might be completely mistaken here but I think we should be very careful going down that road.
PIOTR STRZYZEWSKI: Yes but you are commenting the last example, yes?
PETER KOCH: Yes.
PIOTR STRZYZEWSKI: And I think all of them are partial, somehow, because as you can see, those are parts of the owner field, no matter of what. It's not full value of the owner field, and that will be the partial search. I am not searching for the full value. So making it more partial probably doesn't make any difference. Of course ??
PETER KOCH: Then we should stop there to start with, sorry for the pun.
WILFRIED WOEBER: Peter, just to make me understand your concerns, it's your line of thinking that the e?mail identity or the name in public key is private information or personal information that should be protected?
PETER KOCH: That can start a long religious debate, I guess, and I am not going there.
My concern is having ?? it's not the e?mail address per se, but the certificate is obviously bound to some person, the whole certificate, and even though I understand these are in the split copies of the database, so you can download them and, well, massage them at your will, this may or may not be a good idea and I am, as I said, I am concerned about having this wild card type of queries, and then of course there is the question whether the common name, whether that is a real ?? we have the name in the DNS world where people believe that hierarchy in the domain name space has anything to do with hierarchy in the real world, which is just not the case period, and from a technology point of view I am not sure that this is a good idea here, either.
WILFRIED WOEBER: Okay. Well, I have to admit that I am illiterate when it comes to X509 because I am old style PGP guy and first of all, let me state that I also had this problem of not finding a key, so we solved the problem or I solved the problem for myself by adding comments and attaching the key IDs to sort of other information to provide that linkage. So I really can see the need for such a thing. What I am sort of ?? whether we want to go into that religious or very fundamental discussion about sort of personal identity things, that is ?? I think that is one of the inherent problems in X509 and that is also one of the inherent reasons why I don't use that, that you just can into the create or you are not supposed to create roll based certificates and that is the reason why I use PGP myself and I don't use my personal key for authenticating transaction in the database, but that does not take away the problem of how do I find the key which is relevant in the database, so, yes, Peter, I do see the point but, on the other hand, this is ?? this information is already publically available in the database so just providing another way of finding it is maybe not that bad. There are other comments.
PIOTR STRZYZEWSKI: Can I respond?
AUDIENCE SPEAKER: I was going to respond as well. Your characterisation of X509 is wrong to use a technical term. Role?based certificates are perfectly fine.
PIOTR STRZYZEWSKI: You follow my response.
AUDIENCE SPEAKER: Organisation is is a well?defined attribute so it's anticipated. I think the fundamental issue here is that whether you are talking about a PGP environment where you can make up any name you want or the X509 environment, you can also make up any name you want. There is not one global directory information tree as X 500 had envisioned there would be. So common names, even qualified by other attributes, are not guaranteed to be global, there are lots of CAs out there. So the problems are really fundamentally the same in both of them. There's no difference in the level of personal information that you are disclosing in one versus the other.
PIOTR STRZYZEWSKI: That was basically the same thing what I was going to say. I have a few certificates for great environments, for certifying my students and so on, but a lot of them, we have role?based certificates. Basically, given by different organisations unions.
WILFRIED WOEBER: As I said X509, illiterate. Any other comments? Because we should go ahead and agree on what to do with that. My feeling is that we do see the merits of the proposal and we also do see the concerns, so my suggestion would be to start the real discussion on the mailing list with regard to those aspects, like privacy and data protection and that sort of thing, and at the same time, ask the RIPE NCC to just investigate what the amount of effort would be to implement parts of that or some aspects of that and then we continue that on the mailing list and we agree on how to proceed, and we might even want to have sort of that sort of technical discussion with comments in trying out the RIPE labs environment, that would actually be a very nice exercise to find out whether this is useful. You have got a second proposal to make?
PIOTR STRZYZEWSKI: Yes. That is another one. Introduction of optional NMT ref and attributes for person/role objects. That was on the list so basically speaking most of you probably know that. Right now, there is lack of authorisation during person/role reference process and that could lead to abuse of the objects and there could be a number of reasons for such behaviour: For example, lazy customer reference upstream contacts just to avoid taking care about the abuse; or nasty person reference some objects to mislead users who are looking for abuse contacts. We can do this very easily and have a nasty PA block which changes every single day the contact details. That is possible.
So the proposal is to add two option attribute and to ref which could be added to person role object toss prevent authorisation problems, just like in the organisation and ref notify attributes which could be added to enable notification mechanism, the same way.
Pros and cons: Reusing existing mechanism. Increased security. And of course CONS: Some work needs to be done. And I would like to thank Shane, which is somewhere here. Thank you. Because Shane pointing out to NMT?ref my original proposal was somehow different.
So questions?
Denis Walker: RIPE NCC. We are aware of this issue and we have seen examples of both accidental and malicious intent to reference the wrong person objects. This has been considered by the data Protection Task Force as well. There are a number of issues here: First of all, by implementing this type of arrangement, we are going to considerably change the operational work with the database, because anybody who then wants to reference a person object needs authorisation. If they don't have that authorisation but really need to make this change, there is a high likelihood they will just simply copy it and create a second personal object with the same data which they now maintain and they can now reference. So it could lead to quite a lot of duplication of personal data. As for the security aspect, yes, it would prevent the accidental reference to the wrong persons because you would suddenly realise oh, that is not my person because I don't have the authorisation for that one. For the deliberate malicious intent to reference a person object, they can simply copy all the personal data in the personal object that they want to make a reference to and reference the copy of it. Now, although we can follow the audit trail and we can see who did that, we can equally well see who made the reference to it in real existing personal object now.
As for, perhaps, the law enforcement agencies looking into the database, they won't recognise or realise the difference between a reference to a real person object or reference to a copy of somebody's person object so the usage of this isn't really going to help a lot in terms of security. So, yes, we could do it, but there is a lot of implications there to consider.
PIOTR STRZYZEWSKI: Okay. Thank you.
I have to comment on that. I am pretty much sure that from the legal point of view, the abuser can very easily excuse himself by saying oh, sorry, that was a mistake, if he points to the existing object but if he copies all the data from John [Doe] object and make another one, and then link it to his independent resource, that will not be for judge and kind of you know mistake. I think from the legal point of view, there is a difference, that that is the clearly intentional behaviour and something which could be excused as mistake, so from my point of view, there is a difference.
SHANE KERR: This is Shane Kerr from ISC. Regarding the first point that Denis brought up of people not being able to get a reference to the create a duplicate object with no malicious intent, I mean, that is kind of the design of adding this mechanism is to make sure that people get permission before they reference your object. There is a benefit to having such protection: Even if people copy the information, which is that I can delete my object, right, or I can ?? yes, basically, that is it. Right now you are in a situation where I have kind of got ?? I have got the RIPE DBM to help me and RIPE is like we don't know, so this is an attempt to, at least let me maintain my own data which, right now, I have no way to protect the objects that I am responsible for.
PIOTR STRZYZEWSKI: Yes. And moreover, there was, a few minutes ago, a statement about the mandatory MNT buy. So there will be probably some protection also to create personal role objects. So there will be somewhere the necessity to use maintainers. And I think that is not the case, I agree with Shane that the design is to, if someone see that there was an error because of lack of authorisation, and he is the person who is authorised to do such reference, probably add the password or sign a message with the certificate or whatever, just to do this again and if that is malicious person, yes, there are other ways to shoot him.
PETER KOCH: Peter Koch, DE?NIC. I think I understand your proposed solution. I am not so sure I understand the problem space that you are trying to address here, so I am partly with Denis but also partly with Shane. And I'd suggest that before going further on discussing details of the implementation, can we please explore the problem a bit more, so how much of this accidental/malicious stuff do we really see, what is really achieved by introducing this additional barrier and, well, as much as I hate to say it, but a judge possibly would, is usually not a good phrase to get there, because good practice has been that in such cases, in such cases, if need be, RIPE NCC gets legal advice on these issues, especially data protection stuff and even that legal advice won't guarantee what the judge would do but it is much more helpful than second?guessing there and not picking on you personally but that is just from experience. So let's please explore the problem space a bit more and get numbers if that is in any way possible, and work ahead from there.
PIOTR STRZYZEWSKI: Yes, okay, I have to admit that on the very first example, there is a customer we probably do not get the correct numbers but I think a lot of medium?sized ISPs doesn't care about and take care about the lazy customers' abuse and try to pass the e?mails and so on, not to lose these customers. I am not sure if we get the correct numbers.
Peter Koch: The correct numbers I am not after the fourth digit after the comma; it's just getting a sense of the volume and I know it's early morning but to be blunt, if nobody cares then how to prove that there is really a problem. So I guess at least you seem to care and I suppose that you have example/evidence of this stuff and that is contributing to the problem description and to the numbers, so to speak.
WILFRIED WOEBER: Peter, to come back to the numbers, I personally have experience with that case happening, not in the RIPE database but in domain name registry database. And sort of, the problem in principle is there. How prominent it is in the RIPE database is is a different thing, but, okay, you want to react to that directly.
DENIS WALKER: The problem with numbers, they could, at this very moment, be a few examples or possibly thousands or tens of thousands of examples in the RIPE database as we speak but unless somebody tells us, there is no way of us knowing that. We don't know if a reference to a person object was correct, was accidentally wrong or maliciously wrong. We only know when somebody actually mentions it to us and complains perhaps to RIPE DBM because there is a reference in a maintained object which they can't remove and they realise they shouldn't be referencesing there. We do get occasional complaints but that in no way reflects the possibility of how many could be wrong in the database today.
GEORGE MICHAELSON: George Michaelson, APNIC. Please do not interpret anything that I say as an implied criticism of your approach to the database design or its referencing integrity because I have spoken at your meetings many times over the years and I always worry that it feels like I am criticising. I don't mean that. But I do observe that we take a very different view, I think, in APNIC to the nature of data management in our Whois on your code base and we take a view that the primary interface for changes in our system is a portal, and when you make that decision, you have available to you a tool suite which has nothing to do with the database, about gaining acistive consent to have things done as a gaiting mechanism before it goes into your Whois. So if you are saying that you think it would be important for people to give active consent, that they be referenced as admin C zone text C notify, constructing an entirely referentially complete model inside Whois, from the history of speaking with you Wilfried it's very hard and has consequences for checking when references go away, you have to have backward links and forward and it complicates your schema. If you take a view that you gate processes into this system, implementing this in the gating system, the portal, is a different scoped problem. I would say there are aspects of this in the policy sense and design logic saying, no, you should have consent to reference other people's structures in Whois. Good. Should it be first class in Whois system? I feel less sure. I feel that it's a goal that should be established and you should pursue questions how many are there but not necessarily seek to only solve this in Whois. I think other mechanisms help to confront this problem. That was the sense of my comment.
DENIS WALKER: Yes, I totally agree. And one of the points we do actually want to make is that we have reached a point where we do want to take a step back and look at the bigger picture in terms of the RIPE database and things like portals and access and updating methods and we feel now is the point when we should take this step back and have the bigger view, and maybe through RIPE labs come up with some ideas and proposals on possible ways forward.
PETER KOCH: If we have another minute, I think I owe you an explanation or correction in what I asked for in terms of number otherwise it might look like a kill argument here. You can't see by looking at the database which is right and wrong, because consistency and clean?up would be easy but I guess a first ?? in a first attempt the cross maintainer references from object to persons might frame the size of the problem, to start with. Intra maintainer references, you are helpless anyway. And then the number of complaints/inqueries around this could give some indication. So just to give a sense of what is happening out there and otherwise, yes, what Wilfried said, there are other parts of the industry which have interesting experiences with this.
WILFRIED WOEBER: Let me, George, thank you very much for this input. It's definitely not going to be seen as criticism but as very helpful and useful contribution. What we also should, in that sort of framework of thinking, what we also should keep in mind is the statistics page about the up dates and I think it was about three quarters of the transactions are coming in in our region still through the regular e?mail thing, so this also should be part of the bigger picture and the planning that we have to actually get the user base to use different tools and again, out of curiosity, because I don't know what the e?mails are and what the interfaces are, e?mail can easily be scripted. A portal, web interface is more difficult to script unless you provide the hooks.
GEORGE MICHAELSON: I think the discussions in the ARIN San Antonio meeting went to this consideration, and I think the energy they have invested has been the consideration of portal interface which is functionally what I think IBM Tivoli would call middleware. The mechanism should be apparently scriptable behind the gloss of the web clicks and syncupdates were taking you there.
And I would also like to say I respect entirely the fact your members overwhelming wish to use mail and we must not go in advance of their behaviours, we cannot deprecate this in significant ways without consent. So this is a problem. It bears anything about. Thank you for an opportunity to talk to you.
WILFRIED WOEBER: So I think that is about time to ??
PIOTR STRZYZEWSKI: Just one more comment. Sorry, two comments.
First of all, the XML, there is mechanism to have a script to web interface. That is the solution. Probably all of us know about that and the other comment is to Peter and Shane because both of them arise, somehow arise, the legal argument. I think that ?? I agree with Shane; if it could be possible ?? it could be needed from a legal point of view that the person whose data are in the database should be able to protect them and that will probably be the key argument to implement that. I don't know if, from the Dutch law point of view, I am supposed to have the mechanism to protect my own data. If yes, that would be the argument to implement such thing.
WILFRIED WOEBER: Okay. So I think to wrap it up, first of all, thank you very much for these proposals and for bringing this up. As we have seen, this has already sparked quite a bit of interesting discussion, so thanks for that one.
Secondly, I guess the issue of protecting things and, in particular, following up on Denis, that any change into that direction would have quite a bit of impact on business processes and other things. My feeling is that this should actually be discussed in the framework of the Services Working Group, because we are supposed to provide the toolset but sort of the framework and the business processes and the application and policy things should be discussed in the Services Working Group.
And thirdly, I really think this is pretty fundamental discussions would be a very good idea to try to have these discussions and to collect these ideas within a reasonable framework and to try to do that on the labs environment. We had a couple of private talks in the hallways over the last two days and the idea was developing to have some special corner devoted to database and this might actually be one of the reasons to start that corner to become populated. So, thanks for bringing it up.
PIOTR STRZYZEWSKI: Thank you very much.
(Applause)
WILFRIED WOEBER: And the last item on our agenda is input from other Working Groups. Unfortunately, or fortunately for us, because we don't meet on Friday morning, we are meeting one day before, but unfortunately the anti?abuse Working Group is meeting after the database Working Group. So what I had expected to be able to touch on was the discussion sparked by Abusics, as this is going to happen after the end of this meeting we have to deal with it on the mailing list or bring it up during the next meeting.
And the other short item here was just to mention the proposal that was given by Peter ??
AUDIENCE SPEAKER: Can I make a comment. Brian speaking in my capacity as chair of the anti?abuse Working Group. I am not sure how much discussion we are going to have this afternoon. There is no one from Abusics at the meeting. While some points have been made, I feel very dubious about being any sort of proxy for a proposal which is very unclear and I also may or may not agree with it at any given point in time. So while it's going to be raised, I don't know if there is actually going to be anything in any way concrete to come out of that so I am kind of hoping if there is a proposal that somebody will raise it themselves on a mailing list and then we can look at it from that point of view.
WILFRIED WOEBER: Thank you for that input. I just didn't want to sort of put it under the carpet and ?? so it was put there more or less for formal reasons, to have a very clear understanding after the end of this meeting week, where we are standing with that, whether there is anything to follow up on or not.
The last thing to point out is that Peter has proposed, yesterday, during the Services Working Group, to implement some mechanism to link independent resources to the sponsoring LIR that has sparked quite an interesting discussion as well and this is going to be followed up in the Services Working Group environment. It was just sort of that this might have an impact on the database machinery. So I put it on to today's agenda as input from other Working Groups, just to make you aware this is being discussed.
That gets us to the end of the agenda, to any other business. Is there anything you want to bring up to start discussion on, to comment on? No. Everyone is silently reading e?mail or listening to my broken English.
So thanks for being here. I think we are going to close this meeting a little bit early this time but it's also I think a good sign that there is not too much contentious things, that there is not too much things left on the plate to do.
So thanks for being here and see you at next meeting and see you on the mailing list and maybe we meet, we will meet again on the RIPE labs environment to try that out and to find out whether it's useful to integrate that into the discussion environment. Thank you for being there. See you.
(Applause)
SHANE KERR: That was presentation at the beginning of the routing Working Group. I don't know if it was discussed. Nick Hilliard talked about the changes he has made to the IRR toolset which unfortunately there was a a cross from this meeting, it was recorded and the slides are available. The search summary are that he made a release yesterday so there is a new version. It's about 40 percent the size of the last version in lines of code. Check it out.
(Applause)