Database Working Group
Wednesday, 16 May 2018
At 2 p.m.:
CHAIR: Welcome everybody. Welcome everybody. This is the Database Working Group, we are going to kick it off today, I want to welcome everybody here. I want to thank Marco who is going to be our scribe today and Denis and I are here today, chairing your session. We've got a great session set up and with that, Ed will invite you up to do your operation update.
EDWARD SHRYANE: Good afternoon. You are all very welcome. So I have six slides doing through and 20 minutes so I will try and keep to the point and leave plenty of room for questions and comment at the end.
Three as usual the three focus points, these are the three main areas that we feel the RIPE NCC feels we are responsible for, and are important. And since the last RIPE meeting the focus has mostly opinion on operations, so we have made some really good infrastructure improvements but also we have improved current processes such as the transfer process, we have done some automation there.
We have also ‑‑ that is to say we also have done some work on usability and the Working Group and policies also.
Since the last meeting, there has been one major release and two minor releases. The major change has been to remove the abuse mailbox attribute from objects apart from the role object type. And this alliance the database with the abuse‑c policy so there is now only one way to record abuse contact information, that is in a roll object that then is referenced from an organisation or directly from a resource. And previously to this release we had already deprecated that attribute and done a clean‑up so now there is only abuse mailbox on roll objects in the database.
The second major thing we add was to add an end of stream comment, our near realtime mirror interface, you can sign up through the NCC, that gives you a stream of live updates from the database as they happen, rather than downloading the daily dump from our FTP site. The improvement here is to add a comment at the end of a batch of changes, there already is a comment at the beginning, so it allows a client to see when they have received all of the data from a server.
So release 1.91.and 1 and 2, there are more minor changes, we made some changes to the NRTM, we made a minor change to our single sign‑on application. There is some background work to improving the redundancy of that application and we made some changes on the Whois site to support that. And the final release we made some updates to our dependencies to fix some security issues.
And leading into the next point, we did a security scan of a Whois, who both the software and the service as a whole. An external company did an audit. No critical issues were found. And we largely implemented the changes that we had to make. The important thing is that as a team, we are now more aware of the security as a process, we have integrated into our build and into our release cycle. But one thing that was ‑‑ one functional issue that was found is the use of plain text passwords in plain text protocols is the biggest concern so in particular, sync updates and mail updates, you can use those over plain text and you can supply passwords.
So next is the, we improved the ‑‑ our database software, we use Maria DB to host the RIPE database. We upgraded through three major releases to the latest table version and in addition, we improved the support for failover, so we now can perform a manual failover in seconds rather than hours where it was before. So we were taking advantage of the more recent version of Maria DB to do that. And in ‑‑ not just for failure cases where we ‑‑ where the Whois update server can go down but also for operational support as well so we can patch the update server and allow for operational changes without affecting users.
So we already had support for redundancy for queries but now also for updates, it's more available and reliable.
So on to resource transfers. We see a lot of resource transfers. There were thousands of transfers last year so it was a record year for transfers in the region for transfers within the region. The process was hard for everybody, for organisations and also for end users. There was a lot of manual work needed, so users had to contact the RIPE NCC, there was a lot of round trips to get supporting documentation and the updates of the RIPE database were all manual so they are all manually done internally. So now we have improved that by automating what we can in the database, there is a wizard where users are asked for required information, supporting documentation for the transfer. And we have an API to verify that the requirements are met and it's possible to make a transfer. That is already in production. The next step is to automate updates. So we are going to make, at the end of the process, registration services will be able to press an approve button once all of the supporting documentation has been reviewed and to make the RIPE database changes all at once.
So in addition to the wizard, we will also email end users with a summary of the changes that are about to happen in the transfer so they will be well aware of what will happen.
Final thing for operations, this was discussed extensively last RIPE meeting but currently the changed attribute hasn't been completely deprecated. I looked at updates that were made during April. There was, out of a total of 650,000 updates, two‑thirds of them still contained the changed attribute, one‑third does not and from the two‑thirds that contains changed, that is A and B on the chart there is the majority of updates containing change came from those two sources. So there may be an opportunity to greatly reduce the amount of changed updates containing change if we can contact those sources and ask them to remove it.
Finally, slide on usability. So the IP analyser is an application, accessible from the LIR Portal, but it's been superseded by the my resources functionality, and we are planning to phase it out, we have been doing work in the background to do that. The IP analyser allows you to see which resources your organisation is allocated, IPv4, IPv6 and AS numbers. But it's mostly been superseded by my recourses so we are planning to phase it out so we will make an announcement with the plan to do that. We will remove the old IP analyser and ‑‑ from the left‑hand menu and redirect to the my resources. One other usage of the IP analyser is through the API keys functionality in the portal and we will be replacing that with also new implementation and users won't see any differences, they will be completely compatible.
That is it. They are the slides for me. Any questions or comments?
DENIS WALKER: One of the co‑chairs of the Working Group. Just one point about the change attribute. Historically, we haven't been very good at doing data clean‑ups very efficiently, so I would just like to ask, does anybody have any issues if the RIPE NCC proactively contacts the people who still submit updates with a change attribute especially those two very big organisations and actually encourages them to update their process?
PETER HESSLER: First comment, I still like the change attribute, I want to keep it. I don't want to delete it, I really, really like it. Second comment is that if we do insist on deleting it, that if we ‑‑ if the RIPE NCC would just start deleting it from our objects please notify us before it is deleted, I think that is my comment every single time this type of thing comes up.
EDWARD SHRYANE: The changed attribute has already been deprecated, already filtered out and been completely removed from the RIPE database. So this phase of the implementation is now, we have been returning a warning for the last two years, it may be just completely misleading to users that we are still semi‑supporting it.
PETER HESSLER: Then properly reject it.
RUEDIGER VOLK: No, no, no. There is no use in breaking processes that are operating. You could argue that, yes, before breaking and rejecting the stuff you should do a little bit more than just sending out the regular warnings, but kind of there is the question, what is the trade‑off, what do we gain from ignoring irrelevant additional submitted attributes that are at least sin that theically correct and kind of my understanding is, first of all, I also like the changed attribute because it very, very truly has been into a really good resource for people who could interpret the value of the thing, but well okay, it's gone, it's not in the database any more, it is stripped on input, and I could jump into slightly different topics just let me ask is there another question and answer spot for other operational stuff?
CHAIR: We have an open discussion at the end.
RUEDIGER VOLK: Okay.
DENIS WALKER: On this point, Rudiger, I mean, the functionality of the changed attribute has already been deprecated.
RUEDIGER VOLK: Yes, it is just irrelevant but sin tactically correct noise that is produced by existing processes and tools of the community.
DENIS WALKER: It is noise, let's have a clean database.
RUEDIGER VOLK: Then I have to jump to the other topics, we first have to make sure that the database actually, actually, actually rejects some ‑‑ rejects stuff that is syntactically incorrect.
DENIS WALKER: Is that a proposal?
RUEDIGER VOLK: Kind of that is something that has to be done and one of my topics would have been what are the tickets that we can see to follow up to report back to the database so that we can actually track what damage is there and what is being done about it? I very much ‑‑ I have attributes that I have reported back for early last year and I certainly demand that that is fixed before considering doing something about change.
DENIS WALKER: Which attributes?
RUEDIGER VOLK: I have to ‑‑ I have to look into ‑‑ I have to look into my databases for finding, it jumps up a couple of times when I do ‑‑ when I do stuff and, ah, in the end it doesn't do damage to me, but, well okay, there are things that are actually broken and that need to be fixed and where obviously the process for getting things fixed also is not completely clean.
SPEAKER: Tim, RIPE NCC. So I don't exactly remember off the top of my head which things were submitted but I do know that sometimes we get issues reported and in general if that is a real issue we do follow up. I am not sure if the communication went okay in this particular case but maybe we can follow up on this off‑line, I would suggest, because certainly if there are issues with syntax checks that is something we would take seriously and I know that we have done improvements there in the past.
With regards to the changed, I think, I just want to highlight that, yeah, there is a trade‑off here. On the one hand, reason for taking it out is because if you submit any other arbitrary attribute that doesn't exist on an object any more it would result in a rejection of that object. Currently, we don't do that because we didn't want to impact operations. On the other hand, that does not send us a clear signal to people who may still believe that by submitting the changed attribute they will have something that ends up in the database that will be useful. So one way to flag that to them is by rejecting. So there is that trade‑off. I am not saying that I have the answer but I think it's a question to ask.
RUEDIGER VOLK: Again, I was quite conscious in raising the thing that this is syntactically and scheme atically correct. This is consistent with a definition of RPSL. Walk would that be the official RPSL or RIPE's interpretation of RPSL? Would that be the official definition of RPSL or RIPE's interpretation of it which has changed many times over the years?
RUEDIGER VOLK: Kind of, kind of RPSL was defined in ways so that it is extensible. As far as we have done extensions, we actually, I think, took care that they were correct under the established standard. Removing, removing attributes that are in the base definition, I think would kind of start the process of asking whether we really declare we have our own standard and we will have to ‑‑ we will have to do a good job of defining that well and documenting it well.
DENIS WALKER: We have removed attributes in the past that were in the original definition.
RUEDIGER VOLK: Which?
DENIS WALKER: I will let you know afterwards, I can't remember the names of them now but we have deprecated attributes in the past.
PETER HESSLER: For the attributes that have been deprecated do you remember if the database will reject those or will it filter those out
DENIS WALKER: It will reject them as unrecognised attributes.
PETER HESSLER: Okay. There has been a warning for two years, reject it now, don't let it just be ignored forever.
RUEDIGER VOLK: Strictly, strictly object, the thing is, this may be burnt down in code of automatic management systems. That are still running and you ‑‑ and kind of at least, at least we would have to raise big flags that this is going to be changed, so that with sufficient advance notice and sufficient advance warnings specifically to the offenders, this can be moved out and I actually would say we have much better things to do than take care of that.
DENIS WALKER: ‑‑ is one of the ones we deprecated.
RUEDIGER VOLK: Okay, I am not going to argue why I wasn't that much interested in that. But kind of, kind of, kind of, I think there is a fair argument that we can expect that very little automatic management software actually did insert referral by into objects that were created and submitted while the changed thing is so old and so simple that kind of the observation that is still used a lot.
DENIS WALKER: It was as old as change and it was a mandatory attribute.
CHAIR: Why don't we take this off‑line, we are kind of out of time. Ed, thank you very much. Really appreciate your report.
(Applause)
Up next is current state of RDAP, Andy Newton from ARIN.
ANDREW NEWTON: Hello. Good afternoon. I am the chief engineer for ARIN, and I am here to talk about RDAP, I am not sure how many of you know what it is, can you raise your hand if you have heard about this before? That is a pretty good number.
So a, for those of who did not raise your hands, a primer on what RDAP is. What it means is registry data access protocol, it's an acronym that came out of an ICANN document and the history behind this is such, so I think around 2010 ARIN, we came up with our own restful web service for Whois and we are very proud of ourselves and telling the community about it and someone took us aside and said RIPE NCC did the same thing, but you two ‑‑ your two organisations did not make them compatible. So that was, you know, a kind of an oops situation there. But in the process of doing that, a lot of the people in the communities and the broader community, not just RIR community start talking about all the problems we have with Whois, and there are actually documents, there is an RFC on this in the IETF about some of the problems we have with Whois. There is no organisational support, not good international support anyway, there is no clear method of finding an authoritative server, there is no authentication and there is security and worst of all, nearly every Whois server has a different format so this makes parsing a lot of the results, especially for machines, verytive.
So anyway, what happened was, the IETF took notice of this, there were several BoFs and there was a Working Group in the IETF and they produced RFCs in 2015.
So, here is the basics of it. It's simply a restful service, it is JSON over https, where the https provides the security and the authentication layer and transport and JSON provides the structure and the international ‑‑ similar to other restless services that any modern day programmer is aware of. It supports domain name registries and Regional Internet Registries and basically the way the data model works is, the domain name, the problem space for the domain name registry is really a subset of what the IP address registries need, for the most part. Once you start talking about name servers things being a little different but for the most part the problem sets are completely intertwined.
The data model looks like this, it's essentially a layer data model where you have common data types which are wrapped by common structures and wrapped by the protocol called object classes, those are the things you look up like IP networks, domain names, autonomous system numbers and wrapped into search results if you are doing a search.
The other thing that the protocol gives you is boot strapping so that is a process of trying to find the authoritative server and in a way this works with RDAP the IANA accomplishes a set of files every day, every time something gets updated and these are the actual locations of these files, they are just JSON files, one for domain names, two for IP addresses and autonomous system numbers and a client go Will go fetch them periodically. In practice it kind of works like this, depending ow sophisticated a client is will go talk to a boot strap server, if it doesn't have it itself and in this case for this IP address you would ask the boot strap server and simply returns an http 301 redirect to the registry, the authoritative reg andistry in this case transferred from ARIN to APNIC, ARIN redirects to APNIC. So that is how it works.
So in 2015 is when the RFCs came out so it's been about three years. So as the title of the slide say, current state. What is the current state? At present, all five RIRs have deployed RDAP. Also, not in that list is the NIR for Brazil, they have also got an RDAP server. As far as boot strap servers go, ARIN developed an open sourced boot strap server and we have it deployed. Shortly after that LACNIC took the open source and added some features to it and they have deployed it as well. On top of that, in the Whois space we have been talking about two tiered authentication for probably 15 years now, well LACNIC went ahead and did it. It has two tiered authentication where if you don't authenticate to them you get a very low query rate that you are allowed to query that he is servers for, I think it's five per minute but if you apply for API key, your query limit goes up significantly.
As far as domain name registries that have been deployed this, Verisign has, they don't call it production but it's in the IANA files and last time I talked to them they were actually serving millions of queries over this, depending on the day. But they are doing a pretty bang up job, very active in this space. And ccTLDs who have deployed it. These are the ones listed in the IANA files, a couple of others who have it but they haven't actually formally informed IANA that their service is available.
As far as tooling goes, so ARIN LACNIC and APNIC we have all developed conformance tools and we did this to try to help come together on the standard because of the whole idea was that we wanted too far standard that was cohesive and all the RIRs could support and look ‑‑ anyone who was talking to us could get the same data out of there so we all have conformance test tools, they do various different things but we all have them. There is nick info. This is the command‑line client that Arin has developed. If you want to install it, if you have a system that supports ruby, you will get it. We continue to add features to that and working on a bulk IP address feature where you can give it a list of log files and so forth and it will go look them up and give you statistics on the IP networks that are in there. If you go look at GitHub there is over 30 projects in various states that are about RDAP, and some of the cooler stuff is being done by APNIC, has viz AS, uses R Tap on the back‑end to get all the end information and APNIC's social media people have done a great job, they have a lot of blog articles on RDAP and continuing to look for them.
The other thing here is, APNIC has this really, really cool tool called 'Who Was', RDAP 'Who Was'. This is, you ought doing try this, it's APNIC.net/whowas. Very interesting and I have to say I am quite envious of it. It's very slick. You put in an IP address and allows you to look at the point in time for how that address has been allocated throughout history. And then there is LACNIC, they have a new Whois client, this is a pure JavaScript RDAP client, they have and we have actually been in, trying to do some collaboration to them and talking about open sourcing the software so we need something like this as well and we may collaborate with them and add some features.
As far as the future, one of the things we are doing at ARIN is looking at adding R G NS information, looking at extension RDAP, we currently have origin AS in Whois, it's not reflected into, we are going to add that into RDAP along with a query specifically for getting that information. In the IETF, they are discussing support for RDAP so this is very interesting where you could have open ID or identity providers to access the tiered information in RDAP, if you wanted to, so imagine where you have an account with one RIR but you need information from another RIR you could just use your credentials for that one RIR to get to the other so if you wanted to get, if LACNIC and ARIN were participating in a federated space you could have an ARIN account to get your query limit up at LACNIC. So that is what that kind of feature would be used for. I don't have it on the slides but another thing they are working on in the IETF is object tagging and that is essentially being able to take ‑‑ tagging the name servers and the entities and so forth in RDAP so you can understand where they came from, because IP addresses and autonomous system numbers have a very natural way of finding out who the authoritative server is, at least according to hierarchies but those types of things do not, so that's an attempt is a help to build boot strapping service for those.
Recently, we have determined that there are couple of gaps in the RIRs, the way they have done this, so ‑‑ Matt did this presentation, it was a very good presentation but he pointed out some inconsistencies we have so we have been talking internally about how to solve those problems, the stat of the RIRs have been getting together and we are going to try and solve those and get those fixed. And finally, you talked about the who was tool that APNIC has. So an outgrowth of the who was tool is an idea about doing a history format for the different RIRs. So at present, several the RIRs have a bulk who is format. Unfortunately, it's different for every one. What we are talking about here is coming up with a standard format based on RDAP, for getting the bulk information and this will allow people to write one set of ‑‑ one client in order to do that. And that is it, any questions?
RUEDIGER VOLK: Deutsche Telekom. Kind of, I would raise the question did ‑‑ I think I didn't hear the word schema anywhere. I heard about structure when I think you were essentially saying syntax, actually meaning a very limited form of syntax. And you were talking about format. And you spared me the work for going through the RFCs, whether there is actually some schema definition from the very beginning from all stuff, I was talking to SR I nick at least in 90, probably in '89, the question of can we get and define a common schema for stuff, actually has been not good answered.
ANDREW NEWTON: That is a very good question. So this is JSON which there is no schema language for, correct, and so right now most JSON protocols either use something that is not a standard such as JSON schema, or they do it in pros and that is the way RDAP is actually specified, it's specified basically using send us this thing, by the way this member of this object has this ‑‑ these types of characters or whatever. We have been working on a schema for that, I forget Mario from dot IT has JSON schema version for RDAP. It is, for the most part, complete. The other thing is, we have been working on this thing called JSON content rules which is a separate schema language and we, the ARIN conformance tool uses that to verify whether the JSON is schema‑compliant or not.
RUEDIGER VOLK: Okay. So I hear there are various disprat activities about doing schema languages for JSON. And there is some pros definition of stuff, is there one schema document explaining one schema that is common or that is the common intersection of stuff?
ANDREW NEWTON: Yes, that would be RFC 7842 which is the pros version ‑‑ maybe it's 7483, I can't remember the number. And ‑‑
RUEDIGER VOLK: You will have to invent additional words so that if you are using and evolving the schema to talk about the particular schema instead of calling everything RDAP.
ANDREW NEWTON: Yes. So RDAP has an extension mechanism too, so if you want to add things to it there is a very clear extension mechanism for doing that and that is how we are going to be adding the origin AS information is do an RDAP extension. Any other questions? All right. Thank you.
(Applause)
CHAIR: Up next is Maria from RIPE NCC for general protection data regulations.
MARIA STAFYLER: I am one of the legal counsel of the RIPE NCC. I will give you an update on how we approach the GDPR on RIPE database, my presentation will be a little bit longer than the previous two. In any case, let me give you some background first with regards to personal data protection because this is not something new for Europe. The RIPE NCC is already covered by the EU data protection directive, and we have already done our homework. Back in 2006 the RIPE community identified the need to comply with the legislation, and the RIPE community identified the need to comply with the legislation and it formed the data Protection Task Force with a mandate to look into how the RIPE NCC is processing personal data, not only in the RIPE database but also with regards to the other services. In this presentation, I will focus only on the RIPE database.
If you want to ‑‑ so the outcome of the report of the data Protection Task Force is documented in the data protection report and you can find it online on our website. More specifically, what was done for the RIPE database and why is it important to keep it in mind? Because the data Protection Task Force took into consideration the limitations with regard to personal data processing and it already implemented certain mechanisms and procedures in order to limit the personal data exposure. More specifically, the task force implemented procedures in order to limit the personal data exposure by implementing maintained by attribute which clearly shows responsibilities and accountabilities with regards to who inserts the data in the database.
Next it defined the purpose for processing personal data, and it documented the purposes in the RIPE database terms and conditions. It also enforced the RIPE database terms and conditions as the applicable legal framework for the use of the RIPE database. With regards to personal data that are inserted in the RIPE database and the maintainer is unresponsive it introduced a procedure for removal of contact details from the RIPE database. And also, when personal data ‑‑ when person roll objects are unreferenced for a certain period of time, they are automatically removed. Last but not least it restricted the unlimited access to personal data by implementing the RIPE database acceptable use policy that limits the number of queries on personal data that are inserted in the RIPE database and it also limits the exposure for personal data when the RIPE database is returned in bulk.
So, how did we approach the GDPR. Of course, one of the biggest part of our approach of the work that was done was the legal review. I will give more information later on this these slides. We also engaged with external legal counsels and industry partners and we are following the relevant discussions that are happening between ICANN and the EU authorities about the status of the ‑‑ of the Whois direct Reese. And we believe that these discussions will not touch upon us because the purposes that are served by the RIRs are completely different than the Whois directors for the domain names.
We also raised awareness about the purposes of the RIPE database by published RIPE Labs articles and participating in various discussions and forums.
So going into the legal review, and what we have done. We approached the RIPE database and we analysed the current status, having in mind the work that was ton by the task force. Having that as a basis, we analysed the status in line with the basic principles of processing of personal data, and the requirements of the GDPR. While keeping in mind what is our role as a regional Internet registry and in maintaining the RIPE database. One of the basic principles when personal tat is processed is purpose limitation. Personal data can be processed only if there is a specific legitimate and specified purpose. The RIPE database, as I said at the beginning, has defined purposes for ‑‑ that allow the use and justify use of the database. We analyse all of the seven purposes, in order to understand which of the seven justify contact details to be made publically available. Out of the seven, the one that justifies contact details to be made publically available is facilitating ‑‑ facilitation of coordination between network operators. As you know better than me, for network operation purposes it is very crucial that the contact details of network operators are publically available in order to establish in a timely and efficient manner communication between operators even if they do not have a direct business relationship. After having thought about the purpose, the second principle that we evaluated is the legal grounds, what is the legal ground that justifies personal data to be inserted in the database? Depending on the role, the legal ground varies, and what does this mean? Personal data that is inserted in the RIPE database may either for resource holder or to their contact persons, when approximate comes to resource holder the legal ground justifies them being publically available is the legitimate interest of the RIPE community and the inter number registry system. Whereas when it comes to the contact persons the legal ground that justifies is the individual's consent.
We perform this exercise with every principle of personal data, I will not go into details but we just put it there so that you can have it and you can go and look at it. What was the outcome? The outcome is that there are shared responsibilities between the RIPE NCC and the resource holders when personal data is inserted in the RIPE database. And these responsibilities arise not only from the law but also from the RIPE policies and the database terms and conditions.
So, what issues we identified:
As, you know, the RIPE database does not return only the current version of objects but it also returns historical information. Although we historic queries ‑‑ on personal and roll objects are not allowed the NIC handles of historical person and roll objects are still returned in the results which means that if the person in roll object is still in the RIPE database still exists, a user will be able to make the link and identify who was ‑‑ who used to be the contact person of resource holder, which also is not always accurate; the result will not always be accurate because until 2009 it was allowed to reuse Nick handles.
The second issue we identified is with regard to historical contact details of resource holders and not previous resource holders. So currently, historical queries on objects are allowed and in some cases we provide the history of an object till the moment it was first created, and we provide also the contact details of the current resource holder but we also in some cases provide information about previous resource holders about organisations that used to have the resources. The issue is that when a resource holder, when historical holder was a natural person we are returning historical personal data which is not in line with the law and is not in line with the purpose of the RIPE database, the one that justifies contact details to be made publically available.
So, how to solve this? We discussed this internally and we believe that with regards to the NIC handles the solution that we suggest is to filter out the NIC handles from historical queries so that a user will not be able to make the link and with regards to historical contact details, the solution that we think as appropriate is to align the rules that apply to historical queries with the rules that apply when the RIPE database is provided in FTP files and also filter out the notify attribute because it also contains an email address.
Another issue that we are discussing and we brought ‑‑ we want to bring it to your attention and it's mentioned in the last labs articles that we published is the search of individuals. Currently search of individuals is allowed and every result to a search will return all objects that contain one of the search criteria. And also it will return the full object details of every related ‑‑ return result. What we are discussing is whether this is in line with the purpose of the RIPE database with making contact details publically available and whether this proportionate with regards to it when it comes to data protection. There are restrictions in place, queries on personal data in the RIPE database are limited. However, what we are discussing is whether these restrictions are enough in order to safeguard and to protect from unauthorised access to personal data.
So how to solve this? As I said, we are still discussing this and still trying to identify ways to restrict this exposure, and as a first step, we changed the default settings, search settings so that the results will not retrieve related objects and will not show the full object details. A different topic that we are currently discussing is how to get a contact person's consent before an object is created in the RIPE database. According to the RIPE database terms and conditions, contractually it is the responsibility of the user to, of the maintainer and of the resource holder to take the consent of the individual before they insert the contact details in the RIPE database. There are cases, though, where the RIPE NCC is creating a personal object in the database. For example, during the membership enrollment process. For these cases we are discussing internally how could we reach out to the individual and make them aware of this processing operation and get their consent, and the reason that this is required is in order for the RIPE NCC to be able to demonstrate the consent of the individual, without this taking the contractual responsibility of the resource holder.
So what is work in progress aside from the technical implementation? We are reviewing the documentation and the information that we provide. During the membership enrollment process when an object is created and we want to remind the resource holders of what are their rights, what are their responsibilities and before personal data are inserted in the RIPE database. And the goals of these documentation review is to provide clear and transparent information for the individuals and their rights and also about the responsibilities of the related parties, and the utmost goal is to be able to demonstrate accountability and due diligence.
So as you understand, this is an ongoing work. We will keep engaging with the RIPE community and we will keep informing you about the progress of our work via the RIPE Labs articles and it is a legal obligation to continue monitoring and ensuring compliance with the legal obligations. So for us compliance does not end on 25th May.
RUEDIGER VOLK: It starts.
MARIA STAFYLER: Thank you, it's already there and it's ongoing process and not a one‑off thing. Any questions?
SPEAKER: Ben Gordon, I would like to know about the article 17, I believe it's the right to be forgotten article. Is that sort of, I mean it's ‑‑ from a legal standpoint it's not probably not very difficult to take a stand on but from a database point of view, I mean, if I am John Smith and I say that I am John Smith can you erase me from that? How is that actually going to be handled?
MARIA STAFYLER: First of all you can go yourself in the RIPE database and delete your object and if you do not have your maintainer there you can always go to the maintainer and if your maintainer isn't responsive the RIPE NCC can take action and also there is a procedure in place, the removal of personal data from the RIPE database that as an individual you can exercise and you can already be deleted from the RIPE database.
SPEAKER: I am sort of thinking about about the persons who don't really know that they are there but they are still there and they say that they are sort of John Smith and they could be hundreds I don't know Smith there.
MARIA STAFYLER: As the RIPE NCC, we have mechanisms in place when individual comes to us and we have procedures in place, how to delete them from the RIPE database. Now, it is also the responsibility of the one who inserts the information in the RIPE database to inform the person and we have also procedures in place, for example, the ARC, and we have verification mechanisms in place that allow us to verify the accuracy and the validity of certain data.
SPEAKER: I think it's a work in progress, so I will leave it there. Thank you.
SPEAKER: Peter Hessler: For my day job, I have a number of things registered, with myself as the maintainer and in those objects I am the maintainer and in those objects, I have my company address and my company contact details. I also, as a natural person, have my own assets with a separate maintainer object because my contract with RIPE is with myself as a natural person. My personal data is then published into the database. I am completely happy with my data being on the contact and the contract and internal to RIPE but I am not really happy with my home address being available via Whois. I'm quite comfortable with an email address or a phone number because I can add new ones, not that easily but buying a second house is a little expensive. Is there a way that a natural person can restrict which of those even required attributes are displayed?
MARIA STAFYLER: So in each object has its own syntax and not every attribute is mandatory, some of them are optional. I to in the remember by heart which attributes are mandatory for the organisation object or the personal object but of course you can choose what information you want to insert there and if something is not mandatory, you can always choose to skip it.
SPEAKER: I believe the street address is mandatory and I have currently falsified it by using my work address but that is not really appropriate, and I'm not comfortable with this being published in the database so we can probably take it off‑line to work on but is there a simple answer.
MARIA STAFYLER: I do see your point and we can take it into consideration and we can evaluate it and we can come back to you with feedback later.
PETER KOCH: DENIC. So I have been through a bit of the names craziness on the Whois but I am not going to talk about that. I have also been a member of this data Protection Task Force that you mentioned and as such, I am a bit surprised that the results of the data Protection Task Force are mentioned as so much of a basis for this assessment because if I remember correctly, much of the result of what became came up with was informed by the then interpretation of the Dutch privacy law in accordance with the Dutch data protection authority. Now, the GDPR is not so much different but it has very subtle differences especially when it comes to consent. So anything we based on that back assessment that led to the data Protection Task Force result would no longer be sustainable and I think we might want to discuss that in a bit more detail and just wanted doing on record as a former member not to be involved in that. I have a couple of questions, I am not going to monopolise the mic and if people say that they actually do monopolise the mic, I won't. You mentioned that the RIPE database is fundamentally different from the DNS Whois and let's forget about ICANN for a second. Traditionally, many if not most of the European ccTLDs had their Whois data in the RIPE database and the primary reason for migrating out was not so much a fundamental difference but a matter of scale and organisational responsibility. So I would be glad to learn more about how the NCC came to this fundamentally difference because I think jointly we are in the interesting situation that we have a European based assessment on what can and cannot be published in one sphere and wave contradictory or assessment on what is going to be published here and some of us are in the delicate situation since we run an LIR still and are maintainers in both worlds, may need to explain to either the public or the D PA why green is yellow and yellow is blue and in some situations so that is something to get to.
On the purpose, I think there is still lots of address space in the database that is not routed, not used in the public Internet and for that the assessment of necessity for the cooperation and coordination and so on and so forth, the public Internet, might need to be re‑visited. It may not necessarily be true. Also historically there have been individuals being the holders of address space and that goes down that path.
The thing that totally surprised me, not now but when I read it first, you are suggesting to base the processing of personal data on consent and actually suggest that is my reading, that the LIR/maintainer go collect the consent from the data subjects. Now, in that other sphere, there have been very strong voices both from the article 29 group and if I recall correctly, especially from the Dutch data protection agency that this is no go and I would like to understand why the pay in the Netherlands dime a different conclusion in this case. And we don't have to have an hour of discussion here, but I would be glad to learn about that, thank you.
SPEAKER: Maria made a very nice high level presentation of all the work that we have done, when it comes to the ICANN who is and the difference between the ICANN Whois and our Whois, now the discussion is a little bit different. You said many things and I really like to thank you for that, because indeed these are issues that may be confusing to the public, and it's very important that we clarify them. The data Protection Task Force was established in 2006 and they is it a lot of work on things that were not there before. We had a RIPE database, we had no purpose. The purpose as a concept is fundamental in Data Protection legislation. Why? Why do you have this database where you publish all this personal details? What is the meaning of it? Now, the data protection authorities need the purpose to justify whether this process is lawful or not. This work by the data Protection Task Force was so valuable for our recent review of the GDPR because the community came up with a purpose and we base our assessment on this new legislation on the same purpose. This new legislation doesn't change much, it inserts new obligations, some of them, but the principles are the same. So back then, the community said, yes that one of the purposes is indeed the facilitating the coordination of network operators, and this is fundamental and this is a very good reason to publish personal data in the database, and I will go to the difference with ICANN. DNS ‑ you know this better than me, but I will give it through the glasses of a lawyer and how I understand it, and I believe this is, you will agree with me there, so the DNS is a very hierarchical system, any operational problems are solved along this hierarchical business relationships that are in place. Internet is a little bit different. When there are issues in one side of the Internet, in one network, others want to communicate with the person that is responsible for this part of the Internet, for this network. They don't have necessarily business relationship or any other kind of hierarchy there, it's more horizontal. The only way to communicate with this responsible person of this part of the Internet, of this network, is through the database, and this is very crucial when there is, there is a cyber attack. You need to establish as soon as possible, very fast, an effective communication channel with this person. You don't know who that is, so you go to the database and say, oh, that is the one, I want to talk John, whatever. This is something that makes our database different than domain name registries. That is with the ICANN. I think the third issue you touched upon was the consent.
PETER KOCH: The final one, yes.
ATHINA FRAGKOULI: Just for now. Right. When someone is assigned or allocated Internet number resources, there are not just register registry resources they are responsible for a network, for a part of the Internet. It is important that we know who that person is for transparency purposes and ‑‑ and it's very important that we have contacts with them. So this person has an obligation and a responsibility towards the Internet community and the public to give their contact details. Now, if this person doesn't want to give their contact details themselves they can ask a friend, their friend or an employee to do that instead. However, they should get the consent of this third person. If not, they cannot just put their contact details there. And the database is maintained both by the RIPE NCC and by the maintainers. We are not saying we are not responsible; we say we share this responsibility with those that actually insert this personal tat and with that I will leave you. Thank you.
CHAIR: Rudiger, make it very quick.
RUEDIGER VOLK: I am wondering whether it would be possible and appropriate that the RIPE NCC legal team actually writes an article that is targeted at other legal teams to explain to them what they expect and what the arguments about the sharing of responsibilities are. I think the communication that we have ‑‑ we have had here and so far was kind of knot the ideal stuff to be moved to my legal department in the compliance team and who is involved there but rather, tuned to addressing kind of general audience and I think this is stuff that can be extremely serious. I think there are intricacies that legal laymen really just don't see, and kind of enabling, enabling a direct legal profession exchange on this I have giver could be extremely helpful.
MARIA STAFYLER: Thank you. Of course we will take these into account and we can publish another labs article in the communication and explain more in details. Thank you.
CHAIR: Thank you, Maria.
(Applause)
Up next Laurenz Wagner, a modern chatbot approach for accessing RIPE database.
LAURENZ WAGNER: Today I would like to present new approach for using RIPE database. We thought about quite modern technology right now and we think very useful and we would like to show up a show case for using chat bots in conjunction with the RIPE database.
At the moment RIPE database is very powerful, there is a lot of database in that and a lot of people using it regularly. And there are a lot of ways how to you can query within the database, use the data there and a lot of them are based on automatic queries or manual queries, and in case of the manual queries, you need a few skills to get started, even if you are new RIPE member and you have never been working with the RIPE database, a lot of terms to learn to know what you ‑‑ how to query for the right things and we think that not necessary in any case, so what might be a solution for, a simple newcomers to easily get the information they want and that is the way we come up to the chat bots, because there you ask simple questions and you get the information presented and you don't mind about the things behind like database fields and their names. And so we thought about, ( ‑‑ we thought about how to use it in case of querying for RIPE database information and so I brought a few examples to show up how this could be work ‑‑ or could be done. For example, one simple question a lot of people are using is what is my IP, for example, and in that case you get the information, the IP of your gateway so it's quite often used query within the browser and this can be done very easily. If you are not ‑‑ so for example, another interesting thing is the abuse contact, for example, you want to know the abuse contact for a specific AS number, then you can ask what ‑‑ show me abuse contact for AS number, and then you go on the right‑hand side the right abuse contact from the RIPE database. For that query on the right‑hand side we use the RIPE Stat widgets because they are really great and we only used the natural speech processing in between and a few technology to get the right information. Another case for using it, for example you have one IP and you want to know information about that IP, without knowing what is behind and what is the database field name, and then you ask for your show me general information about that IP and then it's ease three select the appropriate widget to show up with the right information. And the last example especially for DNS queries I really like the DNS path visuallation and you ask simply for specific domain names, so we use in that case ripe.net and you get the right information about that. So, we think that people are not familiar with all the database objects can do these queries quite easily.
The short view on the technology behind, so it's quite simple: We have a few information like authentication service etc. Within our Cloud service and maybe if you like on customer side you can use this part of software or use the Cloud version. And behind we have a European hosted NL P service for doing natural speech processing. It's also located in France. And behind we added the RIPE Stat and RIPE database interfaces and a few Cloud services behind. So it's quite simple, all state of the art technology.
So, as this is a very new approach, it would be great if you try out our application. At the moment it's not that really public available, in that case, so you can go on our web page, fill in your first, last name and email address and we get in touch with you for the instruction but we will improve this within the next week so it's publically available on our website and of course any kind of feedback is welcome, any kind of ideas, in principle is this a good approach, is this useless, I don't know? Everything that comes up to your mind is necessary for us, so please feel free, contact us and we are here today in the afternoon outside so come up to us for questions. And now, questions? Thank you very much.
(Applause)
CHAIR: Thank you. Denis is going to talk about NWI 5.
DENIS WALKER: I am co‑chair of the Working Group. About four years since I last stupid here so I will have to get used to it again. I don't have any slides for this but just a quick recap. Basically NWI 5 is out of region route objects. This is one of those things that has been talked about and talked about and talked about for year after year after year after year. Usually just before and just after a RIPE meeting, no agreement was ever made and then it was for got enfor number six months until it came up again at the next RIPE meeting. So we set out last year to actually try and resolve this one way or another. The ups and downs of it there was long conversations over this last year on the mailing list. We issued a last call for comments in January. And basically, the interest in getting rid of this service from the RIPE database was growing. There was into the single comment made on the mailing list by anybody saying this service should be retained. So the consensus was, we drop the service. Now, there is two things we are doing there: One is, we are first dropping the authorisation requirement to create route objects from the AS number. So from now on the only requirement to authorise the creation of a route object will be from the address space holder. That means there is no longer any speed to create copies of AS objects in the RIPE database that are from other regions.
The next stage will be, will no longer allow creation of new route objects for address space that is not managed by the RIPE ‑‑ within the RIPE region. Those objects that currently exist in the database can still be maintained, you can still edit them and update them, you can still delete them when you no longer need them but you will not be able to create new route objects for any out of region address space. The RIPE NCC has been working on an implementation plan, they reckon maybe a couple of months to implement it and as a consensus has been drawn they will be getting on with this work shortly. So we have written labs articles on this, you can refer to that, it gives you the history and background and everything. Any questions?
SANDER STEFFANN: Funnily enough speaking on behalf of the AFRINIC community at the moment, I got some messages from some of my friends who basically said that large parts of the AFRINIC community weren't aware of this change and were very surprised by it, apparently there has been some break in communication there. I confirm that they now can create route objects for, in their regionist space, for out of region, ASN, so they can basically host everything now in their own database. But apparently this hasn't, a lot of them weren't aware of this and haven't ton this yet so they were a bit ‑‑ they were a bit afraid that operationally things were going to break there. We discussed the different source and again, they were like, well probably it's going to be all right but we are not sure. So and Andrew all son said I have a couple of objects in the RIPE NCC database is it possible we tag them with a different source first so we can see the operational impact on those prefixes so we know what the impact will be when we make the big change
DENIS WALKER: The source will be changed on all out of region.
SANDER STEFFANN: Exactly. He asked to do that, too far test phase where you can ‑‑ where people in AFRINIC can assess the impact before doing it on all objects and he offered some of his objects or route objects as test cases for this.
DENIS WALKER: Yes. Surprisingly, though, the comments we have been getting from AFRINIC and APNIC are that they were both keen to have this service dropped, so it does surprise me a little bit that communication hasn't been passed on.
SANDER STEFFANN: Apparently this has been ‑‑ I think the staff of AFRINIC was very happy with this, but it didn't... the message didn't reach large parts of the rest of the community so somewhere along the line there has been a communications hiccup which caused them doing what is happening and can you please slow down a little bit, so we can get our stuff together.
Peter Hessler: You mentioned that there is plans for tidying the sources and for not allowing new objects and but they can still modify them. Is there a plan for when those objects would be deleted?
DENIS WALKER: There is no plan as yet for formally deleting them. You can still maintain them when you decide you no longer need them you can delete them. Once this current phase is over, we will ask for feedback from the community as to how we should approach any remaining existing objects but the ‑‑ we are not going to say we are just going to delete all these objects, it's for you guys to decide how that happens.
RUEDIGER VOLK: Deutsche Telekom. I get confused about my topics. First of all, your statement first, what was it? First remove ‑‑ first remove the RPSS requirement that the AS co‑signs route objects and then removing the maintainer that has allowed traditionally to do out of region stuff. Walk the one with the public password.
RUEDIGER VOLK: Yes. Okay, kind of I am surprised about that sequence, because the sequence that I expected was and that could have happened some time ago, to remove that secret password and thus that loophole maintainer while keeping the RPSS without change and then perhaps work on changing that, is that sequence just an accident or is that the true plan in
DENIS WALKER: Does it really matter?
RUEDIGER VOLK: Oh, yes, it does
DENIS WALKER: Why?
RUEDIGER VOLK: When you ‑‑ well okay, kind of, kind of taking out of an existing standard RPSS authorisation framework, one loophole is a very simple semantically clean and well, okay, that is really unproblematic, it certainly disables some stuff that has been done in the past, changing the authorisation model is something much more complex which needs actually full documentation in advance so that one can check out what actually happens, the change of removing that AS authorisation requirement changes the ‑‑ changes essentially the approach of the RPSL database that started out as documenting routing policy which is the stuff that is done by the AS holders, and the authorisation was done by RPSS and well okay, I am unhappy, I am unhappy that we are moving out of that, but kind of that change of the authorisation model has a lot of implications and we need to understand the full details before we can actually move there so if you want to have quick progress, we moving that ‑‑ well, okay, that public loophole maintainer could have been done with my consent a long time ago, I wonder it hasn't been done but changing the database system and its authorisation model is something that is indeed more complex.
DENIS WALKER: Technically, it's actually quite simple.
RUEDIGER VOLK: Well okay. Then write a document that actually fully explains the new model so that I can check all the details that are relevant to my processes and my existing data and check out, check out what work is needed to adapt to the new model after I know it.
DENIS WALKER: I am sure the RIPE NCC can knock up some documentation.
RUEDIGER VOLK: As long as we don't have that documentation, obviously we cannot take the step.
DENIS WALKER: Normally, you document as you do it, but if you want it documented in advance, I'm sure that's possible.
CHAIR: Why don't we take this off‑line. We are out of time.
RUEDIGER VOLK: Well okay. I object to change of the authorisation model without full documentation in advance and sufficient lead team and we cannot even determine the lead team necessary if we don't understand where we are going.
SPEAKER: I might ask a simple question here but we do have a operation problems we have this password change. For the record, we are AFRINIC member and also RIPE member as well. Now let's say if wave scenario that we want to use AFRINIC space with let's say APNIC AS number, at our current ‑‑ we are adding an entry in RIPE database, routing entry in the RIPE database with AFRINIC address space and APNIC AS number, that works. We had problem that we want to use AFRINIC space with a RIPE‑issued AS number and then we tried to add it to the AFRINIC database, AFRINIC routing database which company like Level 3 and recognise AFRINIC routing registries at all, therefore the routing was let's say half so the announce was half announced, then the traffic goes to level three and just doesn't pass so it breaks down a lot of the things if we weren't able to do that in a proper routing registry to marry the, let's say one space for one registry to another AS number which is valued practice. So that is my question. That could possibly break it down a lot of networks. Because to our knowledge, quite a few transit provider don't recognise AFRINIC routing database at all. It's just not work for them. I don't know why.
JOB SNIJDERS: I do not believe the former statement.
SPEAKER: We have been told about that so I am not sure how we can share the email, but yeah.
JOB SNIJDERS: Not to be a Dick, if you really have an operational issue with any of the large networks feel free to email me, I will put you in touch with the right people and we can resolve this.
SPEAKER: We tried, we actually tried with a few transit providers and we have problems but we can't really provide details of each cases but yeah, I don't know how it goes because ‑‑ I am not telling ‑‑ that was the truth, we got that response we got.
DENIS WALKER: Perhaps you and Job have a talk and let the mailing list know the outcome. If you can resolve the matter.
SPEAKER: We can share that. Because we haven't find a way to marry APNIC AS number with AFRINIC space, for example, and make working properly with AFRINIC database or APNIC ‑‑ yeah.
SPEAKER: I have a comment from a remote participant in the chat, from liquid telecom. He says I am happy to supply a text prefix, AFRINIC space against our RIPE ASN, let's do a reachability test because some of us that are both RIPE and AFRINIC members are sitting on RIPE ASNs, we cannot properly reduce ‑‑ in the AFRINIC database. It won't let you because of the ASN not being in the region or in AFRINIC, and that leaves me with significant concerns as to potential impact.
SANDER STEFFANN: Denis, basically it's the same as said, I just verified with the people at AFRINIC, their current online tooling doesn't allow to create such objects but people who want them can request host masters and they will create them. It's not technically impossible, just very inconvenient.
JOB SNIJDERS: NTT. I for one am extremely happy that we are moving forward with this type of change, and it will prevent what is called IRR hijacking. If this proposal had not reached consensus and there was no commitment to do this, the alternative approach would be to simply register all remaining IP space in the RIPE database thereby precluding everybody else from making false registrations. So yes, this is work for the community. As is everything. This is part of our jobs. We need to improve Internet security. And this is one of the many approaches to do that. The RIPE database has been abused endlessly by spamers and other nefarious purposes and I am very happy that we are stopping this. And any of the operational issues that we may encounter will be worth it.
CHAIR: I am closing the mics now.
ANDREA CIMA: RIPE NCC registration services. I am not here to give my opinion about this topic but I just want to let you know a trend that I have seen over the last few months. We have received more complaints in the last few months than ever regarding the creation of route objects for out of region space. It almost feels like a number of people know this is coming and they are quickly trying to create as many route objects as possible. We have been contacted by our colleagues of other RIRs saying there are people creating route objects for address space that we yet have not allocated and actually announcing our space and we cannot get them to stop doing that, can you please help us and doing that, we do and sorry fat finger, it's the same people have fat fingers more than once. So do you know what I mean? So we see an increase in this. We see an increase in people coming to us and saying one is announcing my space, someone created route object in my space in your routing registry can you help us. It's just a trend that we see that it's increasing, the hijacking that Job Snijders just mentioned, in fact I can confirm that we on our side see an increase in that trend.
DENIS WALKER: We may need to move a bit more quickly into a clean‑up phase and discuss what to do with all these route objects sitting in the RIPE database.
SPEAKER: Hi. Sean Stewart, Verisign. As someone with addresses in autonomous system numbers, in three separate RIRs, I greatly approve of the goal of cleaning up the individual route registries, I do hope that at some point in the future once they are cleaned up, we can find a way for authorising routes in another registry that I own to be announced out of a different registry.
DENIS WALKER: Perhaps we need a global routing registry.
SPEAKER: I actually just, I think there is two problems here, the first is abuse which caused by the authentication problem which ‑‑ for object in RIPE database, we ‑‑ and so my question to the committee: Can we have by inquiring the foreign database for inquiring the registry, would that be possibility? And the second problem and I admitted that. The problem is not here with RIPE. RIPE is doing fine. It's some other registries have less functional routing database ‑‑ entries which causing the operational problems which we rely on RIPE database to fix that. It's not technically a responsibility of RIPE database, however it's a reality as operator we see. And if such functionality goes away, that will ‑‑ operating experiences.
DENIS WALKER: As far as cross registry authoritisation is concerned over the years many ideas have been put forward and discussed but nobody has ever managed to come up with an idea that was any way close to consensus.
CHAIR: We will take this to the list if you have a proposal, it will be helpful but we are out of time.
RUEDIGER VOLK: Let me repeat again: Removing that maintainer with a public password that essentially that ‑‑ that essentially gives the authorisation for all the space in the RIPE database that is outside of RIPE's original data could be removed quickly and that would quite immediately close the open door for attackers. Closing the door actually a few people with legit activities in the past will be blocked from continuing that but I think that is fine for people who are caught by that kind of problem and for addressing the question of how to do cross registries authorisation, well okay, all of the RIRs have working RPKI which are built for doing exactly the authorisation and kind of except for a few blank spaces like Brazil and Mexico, that is essentially an option and for Stuart ‑‑
DENIS WALKER: And RPKI doesn't do AS number authorisations.
RUEDIGER VOLK: What kind of AS number ‑‑ well, okay, the AS number, the AS number shortisation in the RPSS is to ensure the characteristic of allowing network owners to document their policy to be enforced. I own my original AS route object and I sync them with my configuration.
DENIS WALKER: But there is a flowed system because if the AS number and the address space holder authorise the creation of the route object and the address space holder maintains it and tomorrow the AS holder disagrees with it he can't delete it.
RUEDIGER VOLK: Denis, we are side stepping the essential immediate, the immediate ‑‑ the essential immediate action things. And the most effective immediate action is to remove that maintainer.
DENIS WALKER: I agree ‑‑
RUEDIGER VOLK: And it doesn't impact the overall structure of the rest, it closes the door for some processes and a few people who have been not figured out other ways, the other ‑‑ the way for some of those demands actually growing ROAs in the RPKI is an option
DENIS WALKER: We can ask the question on the mailing list right now, to we have consensus to change that public password tomorrow and if there is a consensus there it can be done like that. So, yes, if the community wants us to close that door immediately, we can do that.
CHAIR: Why don't we take this to the list, if you have a proposal we welcome it. Thank you.
SPEAKER: Another comment that he agrees with the Job and however while I am not opposing the change I'm asking that the RIPE community work with the global community to ensure that this is done in a way that is properly tested and without adverse impact where necessary. If we need to get the changes made to the database at the other RIRs to make sure that the objects can be properly released to there. Let us do that. But let us work together and not in isolation and avoid massive potential impact.
DENIS WALKER: Thank you.
(Applause)
CHAIR: With that we are over time by about ten minutes, we still had two agenda items, I will run through a couple of things really quickly. With our open proposals we have a bunch of proposals that haven't been talked about in over a year, we are going to raise them on the mailing list in coming weeks, and see if there is any interest and if not we will close them. Based on some of the feedback today if somebody has new proposal or request about anything that we have talked about, please bring it to the mailing list, it's where we conduct our business and that is how we get these policies addressed. The last item is we do have one Chair slot open, we revised our process for Chair selection from the last meeting, we were hoping to get it back out in the fall, unfortunately that didn't happen so we are going to open candid see for that, if you need more information otherwise we look forward folks putting their hands up to help out. Other than that, if there is any other open business that you think we need to do, being that we are cutting into the break, now or forever hold your peace. There is no peace.
RUEDIGER VOLK: I would throw out the question: What is actually the means of tracking back reports and the fixing for the database? If there is no clear answer quickly, well okay, I think this needs to be worked on.
Tim: So let's follow up, I did find some communication that I had with you the day before my second son was born so I was a bit distracted afterwards. We found an issue, you reported an issue with the syntax of emails and we found there is about 2000, roughly 2000 cases like that out of 4.5 million occurrences and we tried to find a quick fix for this but it proved to be a little bit more difficult so I think we need to just have this talk again and see what we can do with what priority.
RUEDIGER VOLK: Kind of my question is, well okay do we have a general way, I guess at some point in time I might hit another bug I guess more people will find actually more bugs and we would like to have a way to see which ones are open and how are they tracking.
Tim: Right, okay. I will take that back and we can say something to that. This particular issue is reported on ticket and that is how the communication went but it's not visible to everybody of course.
CHAIR: Well thank you everybody. Thank you to RIPE NCC for being our scribe, thank you to our stenographer for keeping us up on the screen, and we will see you next time.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES RPR WWW.DCR.IE
