The NCC services working group commenced as follows:

Kurtis: All right. Time to find your seats. I know you have been waiting long for your favourite working group, it's always the same, you have to sit through all those others but that is life, finally it's us. Before we begin, again a reminder for those of you who have not picked up your registration packs for the RIPE AGM, please do so now. You can do it at registration desk out in the corridor and (you can do it) and the AGM will be held directly after the NCC services working group in St. John's room but ‑‑ exactly, to the right out here and, just follow Paul there.

So, welcome, everyone. The RIPE NCC has provided with us both a scribe and Jabber scribe, as usual, kindly, thank you very much for helping us. Also, when you go to the microphones please remember to state your name that, helps everyone. And also the stenographers. We have the last working group minutes were posted to the mailing list and to my recollection, there was no comments made on the working group minutes from RIPE 57, so I guess we approve the minutes.

It also acurse to me I didn't introduce myself, I am too used to people knowing me. I am Kurtis, the chair of the NCC Services Working Group. We had a following agenda for the day and it's quite packed so I suggest we get started right away. First up is Axel with the usual RIPE NCC updates, and then he is on to certification.

AXEL PAWLIK: Of course would he give you Jabber and all that stuff. This is NCC Services Working Group, right. OK, the up date from the RIPE NCC, as you know this is the beginning also of the RIPE NCC general meeting, and as part of this, this update.

Basically what we have done over the last few months and what we are planning to do over the rest of the year. One of the things that you might have gathered you are here quite some time already, probably since Monday, we have quite an increased interaction with law enforceers, basically the police, for a couple of months, maybe a year or so. Basically, we have ‑‑ we have been getting faxes and phone calls and stuff from those guys for a long time already, basically always the same; can you tell us who at this point in time used this Internet address?" And the usual point them to the database and that. We have had some more contact and it's very important, I think that, we understand what they want and also that they understand what we can do for them and what we can't do and in that, of course, we are keeping your needs close at heart and basically we tell them, we are members service organisation and doing what our members tell us and we have to adhere to policies and stuff like that.

So you know also that we do speak to governments regularly, we have extended the last roundtable meeting, two or three roundtables ago we had some interspersed activity and presentations by police. We now have had a regular round table governments and added another workshop next morning in our offices with the police force, or some police force members from various countries.

We have implemented the supporter agreement. You will remember over the last few general meetings, there was the request that we set up an agreement with people who would not be able to or not willing to become RIPE NCC member but would support us, give us some money. No we have that supporter agreement there. We haven't seen much support from that corner yet, but of course we hope to see that.

As I said, we have increased activity then in the legal area, arena, we have added finally some staff to support us in this area. There is a lot of work there and she has been running around here. Administrative and finance‑wise, as you will see later on in the member meeting properly, we do still see membership growth, there is a crisis or not, members are still coming in. What we do see, also, though, and that is for quite sometime, the conversion rate from applicants to paid‑up members is dropping. So the growth is still there, it's slowing down, we might or might not make our new member budget for the rest of the year but financially we are safe for now but of course we are tracking this very closely. RIPE NCC staffing is in budget for the first quarter. We have started some projects in‑house to make us work more efficiently, document management and fix asset management, and developing our reporting for ourselves, for the management, board and general meeting, more numbers, better numbers.

In customer services, in ‑‑ that is a group we set up some time ago. Basically to focus the customer interaction and to relieve some of the core groups of the fractured activities there. It works quite well in the member services area, the guys are taking over or have taken over, the set‑up of new members. Administrative set‑up there, the big administrative support to our members and user support for the LIR Portal. The other activities, as, you know, we have started 2007‑01 implementation that have and we will have a separate presentation. Lots of work there. DNS and user support, again abuse area and also the law enforcement interaction there.

Non‑members contact point, people who want to talk to us, they can go to customer services and do that.

And information services basic crack support for TTM and DNSMON.

If you look at the numbers, we are one‑third through the year ‑‑ you see that it's certainly in the same level as last year and probably a little bit more, also, in the various areas. Registration services.

Well the focus as we said many times, on the complete lifecycle of numbering resources, that includes auditing again and reclamation where that is possible and needed. It's again a high ticket load there but running stably. I have heard a few positive comments that, well, it's do I have deal with you, we don't get as many addresses as we really want but we get fast responses. That is good at least. Reclamation as you know we are testing the waters there and are making good progress (reclamation) we do continue audits and I think we will do some more, members' audits, as we go along the line with IPv4 depletion and we also again plan to be audited ourselves in terms of our implementation of it our processes and, yes, that will be by KPMG later this year.

Policy development. I used to say and I admit again it's 30 minute per week job, not quite; you see quite lot of work that Filiz has done there with support from other departments, of course. Not only do we deal with the policy development here; obviously and you have seen that in Filiz's presentation, we are tracking very closely with the other RIRs are doing and that involves a bit of travel and so, yes, we have added English to the PDP supporting ‑‑ just also to have the support team, to have some spread there.

Business applications. That is basically our software department. We have started a project to basically unify the various portal ideas that we have, as the LIR Portal and I will talk about some more later on. That is a major project, basically again making it easier for to you interact with us and, yes, some resources. We do run a lot of meetings, the RIPE meetings meetings, the regional, roundtables and all that stuff. Support for that in terms of software is needed and basically overdue but we hope to roll this out a little bit later this year. We have been very busy with certification and assume we will continue with that.

Registration services improvements, basically, again, looking at efficiency and making it easier for our people to do their work for you. And statistics again, we need to improve them, I said that.

Training services. Last time in Dubai I stood here and said should we do IPv6 training or are you doing this and we heard we should do something there. We have prepared of a a day training, basically, there. I will launch that in July. And basically, it's ‑‑ it's not ‑‑ these are IPv6 addresses and these are IPv4 addresses; it's basically about statistics and the urgency of IPv6 roll out, looking at ‑‑ debunking them, thousand request IPv6 resources, what is the specialities there, looking at scenarios for deployment and showing some testimonials, other people's experience on the IPv6 front. Also we are looking at e‑learning module there that will be hopefully out in the third quarter of this year. Testimonials, I mentioned them, we are also doing them here and have started earlier this week. The idea is to get as wide a spectrum as possible in our experiences with the roll out of IPv6 and, well, we are filming those and making them available, using them in training as well. That is all in the IPv6 there.

New e‑learning module is ready now and it will be released next week, the DNS basics, first of set of three, you have seen them during the break a nice view there, basically a ‑‑ showing the look and feel of those new modules. Very nice job. And basically, I must say that Alex and Al ma having wait too much fun take photographs, running around with cameras, they always smile very widely and I think I won't step as work any more. Too much fun there.

DNS activities. We are Anycasting route for a long time already so by now it's time to replace the hat of several sets of instances there. We have started to talk to of a after nick ‑‑ looking at special requirements there and working on designing a smaller package basically, smaller service that would still be able to do the work there.

Overall, we are look at DNS infrastructure in‑house as well.

Database ASDOT is dead by now. Data protection legislation, working closely with the database task force, basically it's about data protection legislation, basically we have ‑‑ we are taking out personal ‑‑ unreferenced personal data there from the database. Also improvements to the mirroring of our database, stripping out personal data we have determined that it's not appropriate to mirror and also, well, improving the filtering there, talking to people we are near realtime.

Information services, I mentioned that a bit earlier. Also here we are talking to the other RIRs who are interest in the area, and we have fairly large cooperation with APNIC extending our measurement network into the Asia Pacific area and talked to LACNIC and AfriNIC about nodes in their areas.

I talked about portals and the information services area is one where we would want to bundle the services that are available there into one portal, making it accessible in a more logical sense and easier to understand for different user groups. Technical people, governments and the like. In that sense we also have doing interviews with some of those user groups, representatives, we think, during this week.

Of course we are doing lots of things in the back office, as I said, to make us work more efficiently for you. Information security is ‑‑ we are dealing with a lot of I would say private business data that our members give us, that stuff must be properly protected so now structuring that activity there. And then we have, well, it looks a bit like excerpts from the sales brochures of the products, looking at increasing and improving our storage facilities and also at our server facilities basically ‑‑ setting up virtual servers there. Backup, tapes are dead by now as well so we are doing something better.

Meeting support. Lots of meetings, we are doing. We have been in Bahrain earlier this year. MENOG 5 meeting together with the RIPE NCC regional meeting. We will be going again back to Moscow in September and we are looking forward to go to the middle eastern area again in Beruit in October.

Future RIPE meetings, you are at one. This basically is about the preparation for that finding places, scouting cities and venues and negotiating, there is a lot of activity going on there before we agree to go to a place.

Outreach, I wanted to bring it up here, the annual report is ready and printed and published on the website of course as well. IPv6, now we talked about that earlier. That is basically the resource directory that is around the IPv6 training that we will (act) publish late they are month. It's in the final throes of being set up. NRO and ASO secretariat support. Those NRO activities, includes the secretary for is going around and this time it's ours and I think I did surprise Nick there with the requirements that I had in the beginning of the year, but it has been taken up very nicely, always at the beginning we have to do this as well. "Can you?" Of course you can do that. External relations communications, other groups, we have heard about that in the Cooperation Working Group. Lots of meetings to go to, lots of people to talk to. It is useful, it's very useful, I think. And oh, yes, I do talk on the telephone quite often with analysts and members of the press about oh what the RIPE NCC is and what RIPE is and v6 and v4 and why we have to move to v6 and ASNs and why the long ones are going to be a bit problematic. So that basically is update from the RIPE NCC so far. If you have any questions, I am happy to answer them. ?

CHAIR: Any questions for Axel on the NCC update? No. OK. Next on the agenda is the certification status.

AXEL PAWLIK: What do we do now? You know that we have embarked on the certification activity for Internet numbering resources. We were in here in this room, I remember, at RIPE 51 when APNIC, I think Paul Wilson it was at the time, stood up here and said "oh by the way we are certifying our IP addresses and ‑ preparation for I don't know, transfers and the like." We were then tasked by you in ‑‑ following on to develop a certification system ourselves, we started to do that, ARIN joined as well, then we at some some point in time said it's more important we talk to our members what that means for them. So we set up the Certification Task Force which we have been talking to quite often. We have put on some codes developed quite rapidly. We have had a meeting at the ITF among the RIRs to look at this and basically give us status on where we are with all this and maybe to ‑‑ I am happy to say quite a number of the other RIRs are happy to get their hands on our system. At Dubai we have offered a test bed for certification and we are still planning operational rollout later this year. And the question basically is, where are we with this and what is your feedback? A short recap: What is certificate? Basically it's an authoritative statement by an RIPE NCC of allocation's registration in our registry and it says that at some point this time that is when we certify this, information in here is correct. It contains digital ID of the issuing registry, the RIPE NCC in this case, the public key provided by the resource holder certified here and the resource covered by the certificate.

Then there is ‑‑ just for the people who haven't heard that. Route origin authorisation, which are signed by the address space holder. Basically they say that "I hereby authorise A given ‑autonomous system to route this address space." Basically yes you may announce my address space and that would be then also in the resource RPKI system, easily verifiable.

What are the goals, why do this? Basically, to enhance our registry, the certification here would be the derived from registration data and we would regularly verify the ‑‑ or reassure the certificates basically that would be a reason for the resource hold tore regularly contact us. That is basically in the way we were dealing with 2007‑01 the need for having a contract with somebody who has resources. This would be in a way, similar. Benefits for the resource holder would be that there is better proof, easier provable, the right of use of a resource, basically, in the RPKI system, easily verify that that person is the certified RIPE NCC certified user. For the operators upstream and transit providers it would be easier to verify the right of use for resource that they have been asked to originate routes for. They wouldn't have to look up various different databases all over the world, basically it's all in the certificate and they could buy the tools that are provided very easily, verify those requests.

Enabled applications. Again, what would happen if we rolled this out, resource transfers might be easier to do. There would be stronger trust if you have certificate from the RIPE NCC that shows that you are the owner or the rightful user of that ‑‑ sorry, always comes out like that ‑‑ of that resource, then it's easier to trust you than give me some address block and what is that, is it yours or not? Automated or just more efficient provision, basically what I said before, operators can nicely look this up in the RPKI system, don't have to go to various databases in strange countries all over the world. It's all very efficient to do. Then of course, there is secure routing that needs an RPKI system like this. This might be used for this or maybe not. We don't know. But it could be.

OK. This a change of tack. Obviously, I am standing here for a reason. I want to get some feedback from you, our members, and the operators, whether we really should do this. I think it's useful, it would be useful, but also we have to look a little bit beyond what is technically possible. This has, and I think we have heard that before we have understood that or some of us have, there is potential for fundamental change to the Internet is operating, which might be good, but some might think it's not so good. We have been in Heidelberg last year at the Internet governance forum. One presentation there had the funky title of the RIRs, the new epicentre of power in the Internet, which was roughly about this area. As I said, we have regular interaction with law enforcement, various police forces. It's great that we have that, they understand better by now, some of them, what we are able to do. We understand what their goals are and of course their goal is quite simple: Throw the bad guys off the Internet and they want us to do that and we say, well, maybe we would like to do that, I don't like child pornography either but we cannot really effectively do that because yes we could revoke address space but that doesn't mean anything, really, if we would do that so, in any case, no action here is possible without cooperation from the operators. If you don't look at the ‑‑ RIPE database currently and when you route stuff, then that doesn't happen, in any case. So if we would do this certification and if would you widely deploy this and if would you really use it for secure routing, then this might change, but, again, the situation doesn't fundamentally change, it's not RIPE NCC who is able to do anything; it's in the RIPE NCC, the registry and the operators all together. Of course if would he do this and you, then at some point in time then we are under Dutch law, Dutch police force might turn up at our door or the district attorney with a warrant for us to revoke a certificate. That might happen. We need to think about that.

So further considerations, yes we had some feedback from Dubai and already in Berlin, I remember. People saying if you do this certification thing, what happens if I don't find the right people in‑house to pay your bills, will you immediately revoke certificates and what will happen then. That was Berlin. Dubai had something similar. It is very, very clear that we need very clear procedures and policies on when would he revoke certificates or when we would let them expire or how not.

In general, I feel and that is basically shared by all of the RIPE NCC staff here involved in this, there was not really a whole lot of feedback or a lot of positive feedback. There was some rumbling and basically we said we have to expose this and put this on the table. Again, we think certification can be very, very useful to the operators. We have to think about what happens if we deploy this, we would like to hear some positive feedback, of course, from you, and that you will actually use this. On the other hand, if you don't want to us do this any more, then well, we would have to think about what happens then, of course we have RIRs are doing this, we don't know. Potential efficiency operators, I said that, for enforcement law, also depending on the configuration of the whole system and who place and who doesn't.

Assuming you want us to do this, which we are prepared to do, as I said we are preparing for our continuation of the project, how do we proceed here then? I get messages from my board members occasionally about the termination reasons for ‑‑ criteria for certain we are running. If we are roll this out great. What would we consider a successful deployment of certification. Certain within so many years or somebody is using it or majority of operators are using this or secure routing is deployed and used. We don't know. What do we do if we are not successful with this, will we just let it run or will we not do that any more? We will not certify any more, will we let any certificates expire? That is something that we also have to think about. Oh, legacy resources, yes. We wanted to talk about the policy for certification I think for PA. That is just a tiny bit of the resources so far. There are more out there. And sooner or later we probably would also have to look at legacy space and how to do this, we need policies for that as well of course if we want to do that. And that basically is my short presentation here. We are listening, we want to you tell us what to do, basically. You are our members, you have paid for this already. Will you use this? More feedback than that, please.

AUDIENCE SPEAKER: Russell Housley chair of the IETF. I am not a member so I am certainly not speaking from that perspective but it is important for the secure routing work that the authorisation database exist and so if we are going to have any success with the secure routing, I am quite concerned about your title slide for this presentation, which says "done."

AXEL PAWLIK: Yes

AUDIENCE SPEAKER: Because you are not.

SPEAKER: We are not quite done yet.

AUDIENCE SPEAKER: Vasily Dolmatov from Cryptocom. I have heard from Gert the day before, a nice phrase, that there could be unintended consequences where ‑ is unintended, someone want to do something good and there are consequences. Now, they have some technical work done, they have no procedures for its implementation and we are presented to deploy it. We cannot start deployment without having exact procedures with PKI is more than half our procedures, not technical. No clear understanding which should be these procedures in this deployment. It's for secure routing and so on there could be a lot more unintended consequences in this. So, I support, as a member of the Certification Task Force, these efforts and these work being well done and I think it should now be focused on the maintaining of RIPE database and its state there, correctness there, freshness of the data, eliminating of the stale records and so on, this scheme will do quite good. As for the secure routing, and other things, we should think before about unintended consequences and do think it out as intend enter or voluntary consequences. So that is one.

AXEL PAWLIK: I fully agree.

Wilfried: In general I think it's a very good thing to have that tool available, but coming to your question like how do we measure success? I think it's just like having an electrical screwdriver or some tool for the home worker; you can either ask the question how many of those have you sold and how much money did you earn by doing so? And that is easy. But that is sort of not the answer ‑‑ it's not the answer you want to get. On the other hand, if you ask sort of, how many buildings have been made possible or how many refurbishments or flats have been made possible by having those cheap electrical tools available, then becomes interesting and complicated and you can probably not answer that question when you put the product on to the market. Where I want to get at is that I perceive this certification thing at the moment as a toolset, and we have to make sure that the tool is safe, well understood, easy to use and cheap to buy, but what is going to be built on top of that structure, that is completely different thing and my vision here is or my expectation or my hope would be, that the availability of the tool gets the global Internet community to think about how to refurbish the management of the routing plain. We had a task force, the data Protection Task Force meeting and we were reviewing a couple of comments like we have to continue mirroring the routing registry and that sort of things. What we are having right now is ideas, at least according to my knowledge, about the state of affairs of secure routing, what we are having is nice ideas, no deployment, no products and no sort of coordinated global routing registry.

SPEAKER: Yes.

Wilfried Woeber: And even if we do the right thing in our region it's still going to be sort of a regional incomplete thing, it's not going to have a real global impact on the routing plain because there are so many other routing registries around which we might want to pull on to the same boat.

AXEL PAWLIK: It's not really done yet. But it's done to some degree or to a fairly large degree is our initial implementation of in‑house certification, giving you an initial interface, but that is really it. Yes.

AUDIENCE SPEAKER: Deutsche Telecom. Axel, I am glad you are say, well, OK, done is only a small part of it and, well, OK, actually we look to ‑‑ we have to look what we have to put on the road map, and the thing that has been done is indeed, well, objecting, centralised nice user interface with some underlying infrastructure (underlying), some other policy rules that was referred to are fairly open, and well, OK, you are, at the moment, saying, well, OK, only a small part of the resources that should be certified are under focus and the plan for actually getting the whole job done, needs to be lined out. And well OK, then also for the road map, well, OK, going from a centralised nice user interface to something where, actually, the standard assumption could be that the onus of resources actually keep their own private key instead of relying on a centralised service to keep their private keys, certainly is an important thing. Well OK. So there is a lot of work ahead and for Wilfried I would agree, well, adding stuff to ‑‑ adding stuff to the toolbox in the form of figuring out what are good practices, what are tool sets that can help network operators to actually implement stuff, also lot of work, but quite certainly, quite certainly not a reason to say well OK, we should stop this work; but rather, work out the road map to move forward. And well, OK to, your concern that this is isolated regional development, what I am seeing is not ‑‑ what I am seeing is not really matching that. This is, as far as I can tell, the first really globally aligned definition of infrastructure for the resources, and I do not have any hope that except for getting this done, we will get into a situation where we have a homogenous verifiable database system where we can check whether some party that steps into your office and says "well, this is the address that I own, please route it for me" you can check easily. If you restrict your customer base to the houses in the neighbourhood, well it might still work, but if you consider anybody who has a widespread customer base, well it just doesn't work without getting this done and this could do it. When discussing the threats from unintended down sides, yes, of course there are many things that people who are working on the mechanisms and maybe even on the policies do not see easily as they are working on the detailed problems. On the other hand, when the unexpected negative consequences are mentioned, I feel very ‑‑ I feel very uncomfortable because the fact that the routing system as it stands right now is completely unprotected and in the extreme, I could say, well, OK, guys, are you thinking that you should be more afraid from ‑‑ from the RIPE NCC withdrawing some certificate based on the legal processes in the Netherlands on the request of whatever law enforcement agency takes you down, should you be more afraid of this than with the current situation where someone at some far‑off land decides that some user on your website is offering some offensive picture and, well, OK, accidentally, they twist their routing and the global network takes off your website from the global network. And do we prefer the situation that, now, it seems to be a standard feature of each black hats conference that someone steps up and demonstrates how easy it is to hijack or black hole routes in the global routing system? I don't think so.

AXEL PAWLIK: Go ahead and plan the road map, draw out the road map but go on. Thank you. Our chair has ‑‑ go on.

CHAIR: I am going to close the microphones here but ‑‑

AUDIENCE SPEAKER: Thank you. Let me ‑‑ Remco. Let me start off by saying that I support the principle of a resource certificate, but the implementation of such a thing is different and difficult. What you have set up right now is is a nice little printing shop for certificates but what are we going to do with it is a very valid question. And I think that the devil here is in the details, in the implementation details. What you have set up has concerns in three, I would put it in three key words: One is central; one is validity; and one is revocation.

Let me start off with validity. Today when I get an allocation, it is valid until I give it back. In a new system it has validity date, at least the certificate has and how does that work? Revocation, all of a sudden we might have a central authority being able to switch something off or at least strictly advise people to switch something off. We can look at our colleagues in the domain name system world and ask ourselves whether that is a good question or not. And that comes to my last point, which is central, particularly if you are going to do secure routing or have the ambition to do a secure routing with this; we all need to realise that, for the moment, it is every network for itself who decides what to route and whatnot. And by setting up a chain of certificates and validity revocation and whatnot, that might hinder that independent network in their decisions or at least make it less transparent for them to what decisions they have come to. And that, combined with the central function for revocation, will make it very hard for, well potentially even up open networks for liability because they stopped routing based on some charge in the Netherlands, whereas whatever is going on was perfectly legal in the Ukraine, I don't know. And that is something that we should be very, very careful about and since Rudger has already spent 15 minutes behind the microphone I will leave it at this.

CHAIR: I close the microphone lines for the people who are standing here before.

AUDIENCE SPEAKER: Volodymyr Yakovenko from Google. I am curious, what is your plan to make it working across registry, if there is one?

AXEL PAWLIK: Yes. We have plans to have it work across registries, basically what we currently have implemented is a multiple Trust Anchor thing where we cross certify each other and that is how it currently is. We will and have started to talk about the ‑‑ this, to the IETF also because obviously this is not the most ideal, prettiest system but that is how what we currently feel is implementable

AUDIENCE SPEAKER: But do you have an acknowledgement from all of the registries that they are going to follow it.

AXEL PAWLIK: All of the regional registries, yes.

CHAIR: I have been told we can shorten the other presentations, if people have more things to say we can go on for a bit longer. Who was next?

AUDIENCE SPEAKER: First a disclaimer, I am not in a position to judge this idea, personally I support it but I mean the since it is mainly involved and impacting LIRs, yet I think there are over there organisations who are not LIR and holding PI space, legacy space so my question is double: Are those organisations taken into account in terms of certifications of their resource they held and whether they have to have a contract directly with the registry or via an LIR, yet another opportunity to get contracts signed. Second, when announcing their routes in the routing system, are they going to do it on their own or ask for some LIR or operator to do it on, let's say, their provider to do it and when they change provider, are there handovers or rollovers or whatever way we want to do it, to say ‑‑ are all those aspects being taken into account in this plan?

AXEL PAWLIK: They are taken into account. The plan is to roll out quite softly and carefully and do it for PA resources, first of all, and yes, legacy, like I said, probably will need to come into that as well in terms of yes, you will need to be registered properly somewhere, so sooner or later we have to do something like this anyway, yes.

AUDIENCE SPEAKER: Sam Weiler. Prior to seeing the lovely slide on the screen in front of us I had the impression that the RIPE test bed did not yet implement the up/down protocol for interactions between the RIPE database and the other resource holders. Could you reassure me that you have done that or are you not done.

AXEL PAWLIK: No we are not done. What we see currently we ourselves very centralistically can give out certificates for the resource that is know about. This is a bit of a pointed slide. I want to you think about the future implications; like here so far, if we should continue the effort, then of course we will continue with implementation the missing piece as well.

AUDIENCE SPEAKER: So perhaps it would have been more informative to give us the precise description of what you had finished.

AXEL PAWLIK: That was not the intention of my presentation, but of course we can do that as well. Basically, you understand what I want to do.

Kurtis: Not as chair. NetNod. I think there is a saying in English which is the road to much warmer place is lined with good intentions and I fully understand that having a secure routing system is both desirable and needed but the point that I think Rudger touched upon a bit and Remco is trying to make, there is a massive danger nothing to do with technology in here, you brought it up in your presentation as well, I think we have to acknowledge. There is real live example as you might have heard in my earlier session about trial against content site in Sweden, the rights organisations are ‑‑ I am not a lawyer, I can't judge the validity of this, are going after the Service Providers and claiming that because they are providing routability for these address blocks, they are in in a way part in a crime. And this is only one European interpretation of a European directive and we now have several more to take care of in a possible way that can affect RIPE and I think these issues are actually quite hard and dangerous and before they are clearly worked out and thought out, these can actually be a very, very good tool and easily misused tool.

AXEL PAWLIK: That is what I am talking about, yes. Who is next?

Rob: I think we all agree on one thing: If we are not careful, this is a very complicated issue, many facetted issue, (many) so I strongly encourage all of new this discussion to go back to the basics. It was on one of the first slides that Axel showed, which said what do we certify with this certificate. Well we certify the registration of a particular Internet resource. So it has all to do with registration and the quality of this whole certification process is built upon the quality of the registration data. I think before we go into the unknown territory of secure routing, we all know we can use it for that. I think before we start issuing certificates, we need a better understanding of the quality of our database, the quality of our certification ‑‑ our registration database and procedures for improving that and we need a registration policy, basically, and then the whole ‑‑ most of the issues surrounding certificates will back lot easier if it is based upon a well‑documented registration policy and procedures. Also, I would strongly encourage from day one, when we start doing this, to make no distinction between red IPv4 address blocks, yellow, blue or green. I think in a few years from now the distinction between various IPv4 resources, i.e. where did they come from in some further distant past, becomes rather irrelevant. We want to be sure that the complete address space is covered. I was very glad, this morning, with ARIN's report, that they are thinking on the same lines and are taking the first steps there. I think in parallel with developing the ideas about this whole certification system, we must put a lot of resources in hardening our registration data and that starts with thinking about registration policies and procedures.

(Applause)

AXEL PAWLIK: Thank you, Rob.

CHAIR: Steve and then Daniel.

Steve Kent BBN technologies. One or more speakers previously have expressed concerns about the implications on the use of the resource PKI with regard to routing but a couple of the statements that I think I heard don't seem to be quite right. Ultimately as I think you pointed out earlier, ISPs decide how routing is done, so this is providing information which can be used by ISPs. Now if we didn't think anybody was going to use it we probably wouldn't do this, the bottom line is ISPs do make that choice and if there was concern that a centralised database, one of several, with information of this sort is dangerous, then you should shut down the RIR database you operate today because it's the trying to do the same sort of thing, providing more information than what is coming out from the resource PKI, so the goal here, I believe, that all of the RIRs are buying into, is that as the previous speaker pointed out, with good attention to detail in terms of the accuracy of the registration information, you are providing a potentially more secure basis for people to make routing decisions, but they will always be the ones who make the routing decisions, they can choose to use this data or any other data, one cannot force them to make use of it, if the data is highly accurate, presumably they will find it useful to employ. If not. There are multiple RIR databases out there and some ISPs use them and some don't. Some use a subset because they believe the data is more accurate etc.. so this is analogous but just technically more secure in many regards and it was important I go first because Daniel doesn't believe this.

Daniel: That is what I was trying to say earlier on, fundamentally nothing is going to change because it's the ‑‑ the operators and the registry working together and it depends on how far for what purposes it is used. Yes.

Daniel Karrenberg, in this case Internet citizen. Of course, Dr. Kent is technically correct. The problem is of course, as always, a matter of degree. The IRRs are very ‑‑ how should I say? ‑‑ loosely coupled things. If we have an RPKI, actually those in charge of the public interest and Axel alluded to a couple of cases, will sort of understand this because they understand X509 and all that kind of stuff and it will have at least the perception of a much more direct, much more tightly coupled lever to them, and yes, Steve is technically correct that the ISPs make the decisions but if there is a perception among those after the public interest or maybe some cases their own interest, that such a lever exists, the desires will grow to actually legislate or otherwise make this lever be used. I ‑‑ for people in this country, will know that a number of people died actually in the Second World War and then those ‑‑ in those times, destroying some of these levers. So, I think it's a valid concern, and yes, technically, nothing changes. The other two little things I wanted to say is, I am fully with Rob, I think, and the applause that happened was very happening, we need to do something about registration data and I know that my colleague Robert is sitting sort of almost on the edge of the chair because he wants to tell you that we are moving in that direction so I think that needs ‑‑ that needs happening, but I also think, and that didn't quite come out as clearly, we need to do something on the, our Russian friend said, something on the procedures so we need to work on certification policy statements, certificates and all the stuff that goes with X509 that is certainly up in the air at the moment.

AXEL PAWLIK: Thanks.

AUDIENCE SPEAKER: I have two quick questions before Daniel leaves: Since you told me that you have political bureaucrats who understand X509, could you lone them to us, because I don't know of any in the United States.

And secondly, since you started off very nicely with the of course Dr. Kent is technically correct, can that as a blanket statement going forward?

AUDIENCE SPEAKER: The answer to both questions is no, I am sorry.

Kurtis: I actually don't think that Steve's analogy was completely correct to say that RIR today is exactly the same as a certificate would be. The I actually ‑‑ how to put this politely without disagreeing with Rob ‑‑ I think as a feature of the current RIR that is not that exact. It's a feature quite often used. It's quite often used. It's loosely correct but not quite correct and that is a feature.

AUDIENCE SPEAKER: So you are saying it's a feature that everybody believe the Pakistan Telekom YouTube black‑holing route?

AUDIENCE SPEAKER: Let me try to help out here. I think it's not necessarily the loosely correctness of the IRR data that is beneficial but the level of trust that people have in it as a result of that.

Kurtis: Correct.

Rudger: My suggestion for that problem is, well, OK, if you want to rely that, actually, the data out of the RPKI should be used with kind of a grain of salt, you are welcome to propose tools that actually allow this.

Kurtis: If that is the case, I agree with you but that was not part of the presentation but I agree with you.

Rudger: That is kind of a thing that makes Steve's comment kind of true, with no tools developed it's quite clear the certificate system gives us the feature that we really have a black and white picture and if there are things where we need a grey in between, again, that is additional work.

Kurtis: Correct. I agree so far.

Rudger: For Rob, I would say your suggestion to keep colouring out of a space, I would say, actually, we have to distinguish between the address space where we actually have figured out what the precise circumstances are and the parts that are grey because they still warrant investigation.

AUDIENCE SPEAKER: That is, I think you misunderstood me here. I think we should check the complete full IPv4 address space.

Rudger: To that I agree fully and I said to Axel that should be on the road map.

AXEL PAWLIK: It is.

AUDIENCE SPEAKER: Kurtis, I had not a point of order but something like a proposal of order. I think we have heard in the past, whatever 40 minutes or so, a lot of input from the audience to this nice presentation. I think we should now agree on the next steps. If ‑‑ my personal summary is that we need a set of documents, some policy documents, some are procedure documents, which cover all the aspects being presented and being brought up in the discussion and I think the RIPE NCC Services Working Group is as good as any ‑ no, it's the perfect environment to develop this and I think ‑‑ I hope that sometime in the very, very, very near future, some people at the RIPE NCC kick this off by, on the mailing list of course, at least give a summary of what we have been discussing today with a proposal of a set of documents where we then start working on.

CHAIR: I was going to pick up on it, Rob was the last one at the microphone, but looking at Axel, I think it's ‑‑ maybe it's fair, well, I am the chair, deciding it's fair to ask the NCC staff, who I guess has most insight in what documents might be address to address some of the legal aspects you concern, propose them on the mailing list and we can have a discussion of whether we let the NCC RIPE comment on them or ‑‑ but let's first agree on a set of documents and take it from there.

AXEL PAWLIK: Yes, I agree. Thank you all for your comments. I think I have enough material to work with for the next week until we are really done. Thank you.

(Applause)

CHAIR: Next up is Andrea.

ANDREA CIMA: Good afternoon everybody. My name is Andrea Cima from RIPE NCC and I will give you previous presentation of the implementation of 2007‑01. Contractual relationship requirements for end users I wanted to keep it brief as we are running out of time. I will start with the brief introduction about the policy itself. Then I will show you how we have broken down the implementation processes, and finally I hope to bit of time for questions.

What was the main goal of policy 2007‑01. Let's say until very recently end users are requesting independent resources through RIPE NCC member, we are not required to in any event a contractual relationship with the LIR itself meaning it was very difficult to actually keep track of those resources over time. Now with the implementation of this policy, and end users are requesting independent resources, either to a RIPE NCC member, an LAR or directly to the RIPE NCC or they are required to enter into a contractual relationship.

As I said before, we have broken down the implementation process into different steps. In Phase One, what have we done? We have been focussing on new assignments. What do I mean by this? I mean that since very recently, every end user who had a request independent resources has to get into a contractual relationship, either with the sponsoring LIR or directly with the RIPE NCC becoming what we call a direct assignment user.

Now, if we look what are the main differences between the end user of LIR and a direct assignment user. An end user of LIR signs a contract with the sponsoring LIR who is requesting the resources for them. The direct assignment user signs a contract directly with the RIPE NCC. End user of LIRs are not charged directly, the LIR will be charged for the resources and direct assignment users are actually charged directly by the RIPE NCC. None of them have a RIPE NCC membership and even though direct assignment users sign a contract with the RIPE NCC, they can only get independent numbering resources for their own infrastructure. For the rest, they will not be able to receive any other services. And finally, we have created a new work type in the RIPE database for direct assignment users in order to be able to differentiate them.

What has the impact been of Phase One? 14 new RIPE documents, it's quite a lot. Most of them are request forms and supporting notes, of course also new policy documents and procedural documents. The RIPE NCC has made 8 major updates to its internal softwares. 16 internal process have been updated. Mostly regarding to the way in which we evaluate the resource request and finally we have created a new section about independent resources.

If we look at some numbers, we can say that Phase One of this policy has been implemented on the 3rd of March 2009. In the first two weeks, we had to drop in independent resources assignments of about 65 percent this. Seems quite high but after three weeks things were back to normal.

98 percent of the requests for independent resources were received with contracts. This shows us that our members had no big issues with the implementation of this policy. And in just a few cases, the LIR was not aware of the new policy and we had to agree on a time frame in which they would send us the contracts and these contracts in the meantime have been received. With regards to direct assignment users, organisations who sign a contract directly with the RIPE NCC, we have two so far and there are six in the activation process.

Now, this was it about new requests. But what about independent resources which have been assigned in the past? This will be our main focus for Phase Two. In this phase, we will contact all end users who have received independent resources in the past through the LIR who requested the resources for them. Now if we look at some numbers, we can see about 1,200 LIRs have no independent resources, have never requested an independent resource to the RIPE NCC. About 3200 of them have one, have requested one independent resource. As you can probably see, almost all of them are AS numbers. So we can quite confidently say that these AS numbers are used by the LIRs themselves in order to announce their own allocation.

Then we have about 1,000 members who have requested an average of three independent resources, 260 members who have requested an average of 8 independent resources and then we come to 422 RIPE NCC members who have requested more than 10 Internet resources and if we look at the average, the average is of about 44 independent resources per member. However, if we look at the top five of LIRs in this group, we have five LIRs who have requested between the 500 and the 900 independent resource each, let's say this raises the average quite a little bit. And in this case, I have to sign these LIRs might need a little bit additional support from the RIPE NCC during this process.

As I have just said, we will contact end users through the LIRs who have requested the resources for them over time. Our business aapplications department is currently working on an interface which will be provided to our members through the LIR Portal and this interface they will be asked is the user of this resource still your customers? Do off contract with them? If yes, the resource will stay under the umbrella of the LIR; if no, the resource will be removed from the originally requesting LIR. The time frame we will use is between May and September, why September? Because in September, end of September, we calculate the billing score for next year for our members. And our aim is that LIRs will not be charged for Internet resources for end users who are not their customers any more. At the same time, we understand the there is quite a lot of administration involved in getting end users to sign contracts. For this reason, LIRs will have the possibility to upload contracts and registration papers until the end of 2009.

What will we do with all the orphaned end users and by that I mean all the end users who have been discarded by the LIRs? Organisations who in the past requested resources through LIRs who are not active any more. We will contact those directly. This will be at a later stage in Phase Three. At this point we have a few questions for ourselves: How many will they be, who will be, will they still be reachable after all this time. We don't have these figures yet. Of course, after September we will have those figures and we will be able to present them at our next RIPE meeting.

And finally, to conclude this, we know this will be a long, ongoing process, but we are sure that it will help to keep track of independent resources which are being assigned and it will help data quality, as well. So, yes.

Do you have any questions? No. Thank you very much.

(Applause)

CHAIR: Next up is Paul with the NCC survey.

PAUL RENDEK: OK. Good afternoon everyone. I will try keep this a bit brief. I am actually here to tell you a bit about the membership survey we conducted at the end of 2008. Many of you will have seen this or knew about this because you had participated in this. We did a survey towards the end of the year which ended around December in 2008. OK. Just an overview of what I will actually be presenting, I will give you the history of memberships surveys we have done thus far, I will give you some facts about what has come out of the recent 2008 membership survey, some of the results, some improvement areas and actions we plan on taking.

So some history:

In 2008, we had our fourth RIPE NCC member survey. There were three others, one in 1999, 2002, 2005. The first one was conducted by ourselves in‑house, it was kind of the first time we were getting our feet wet with actually surveying our membership. The other two were conducted by a third party, KPMG Australia and the fourth one TNS Nipo. The results can be found here on this URL.

The 2008 survey, we tried to keep the survey in line with what we had done in 2005 so we see the results and measure one survey to the next, so we did compare the results to 2005 where it was possible. The average overall satisfaction score for the RIPE NCC for the 2008 survey was 5.7. This was out of a total points 1 to 7, 1 being poor and 7 being rather excellent. And this compares to 5.6 in 2005, so as you can see, it's relatively stable and consistent. We have moved up just a notch there.

Participation in this survey, this was the largest turn out we have had, 771 members actually completed this survey, and at that time, which was pretty much the end of 2008, it represented 13 percent of our membership. And of this, the main Respondents which is probably no surprise to you, were network engineers, sys admin and some management and board members of LIRs, and this group, like the largest group you see, the top three area here is mainly comprised of ISPs and Telcos. Which is, again, also probably no surprise to anyone in the room.

Participation was ‑‑ well, the survey was filled out by members in 64 countries, out of the 75 is in our service region we are quite happy with that, we feel we have got a broad area of responses there. And the countries with the greatest number of responses were Germany with 16 percent, Italy with 10 percent, Netherlands with 10. And there is a list, if you go to the URL that I have provided, you can see some of the other rankings of where countries had scored.

Importance of services: The services most often used were the registration services 77 percent. The Respondents said they were using this service. The second was database, with 75 percent. But what is interesting the first time that we have actually been able to measure this anyway but for the first time we are seeing that the top ranked RIPE NCC service terms of its importance is the RIPE database and not registration services as it probably would have been seen earlier on. There is probably a number of reasons for this. One of the main ones is that a lot of people have received their addresses here, they haven't been coming back but they are coming back to use the RIPE database so that is one thing. The other ‑‑ some of the other areas of importance that you saw there were RIPE database, registration services, DNS services, then followed by information services, and it kind of goes do you know list there.

Now, some of the individual services that the RIPE NCC. The average scores in the database area range from 5.7 to 6.0. In the high ‑‑ on the highest area, we had that the RIPE NCC actually answers RIPE database questions to your satisfaction, so that is actually quite nice to hear. From the lower end. And of course I am giving you a high and low here to give you an idea of what is happened at each one, by no means does that mean this wasn't done well or that it's not being looked at. It's just the way the scoring goes, the averages. And low end was RIPE NCC provides me with the right tools to easily update the RIPE database and I guess the improvements that were listed there that we most often saw that was people wanted to see more user‑friendly interfaces andees to access tools for the RIPE database.

Registration services. Here we had scorings from 5.1 up to 5.7. The high being ‑‑ the RIPE NCC deals with our requests for resource quickly. We are quite happy to see this scored highly. The lowest there was the request forms easy to complete. This is something we have also been told in the past, I know that the registration people are ‑‑ registration services group are constantly working on this. Some of the suggested improvements here were clarity of instructions and providing some how to use guides and improving the interface, also, and making a few more wizards and I believe this is being added there.

DNS services, the average scores here range from 5.3 to 6.1, satisfaction there was on the quality of the reverse DNS service provided and lower end was request for more Anycast instances of K‑root servers. Again, it doesn't even in ‑‑ that the instances of K‑root is not important; it just was a little less important than what people thought of the quality of our reverse DNS services. And the main improvement was to have better documentation in DNS.

Moving on to training services. The training services actually showed one of the biggest jumps in approval rating from the membership, which is quite nice to see, from 5.4 to in 2005 up to 5.9 with the recent survey and I think what people wanted to see there was more technology‑specific training and more on‑line, step by step guides in e‑learning modules. So we actually had also asked people to rank or to tell us what specific courses they'd like to us offer, and, would you, boom, we have a whopping 85 percent going for IPv6, I am happy to say the training services are working on providing IPv6 training, which should be ready sometime before the summer, and we will also be taking a look at e‑learning module that will come out late sore we have listened to this.

The next was routing information services followed by DNS for LIRs. Surveys go, you do get some funny responses. We had 8 percent telling us they wanted us to training but had no idea on what. So that was a little funny there.

Billing and administration support. Overall, the levels here were also fairly high. Members are impressed with the speed of this service which was good, the lowest scoring there was that members showed they wanted service fees to reflect the services that they get. And I am going to attempt to explain maybe what is happening here. When we looked at the ‑‑ at the feedback that we got from people in this area, we could see that the folks in the extra small category are saying that they think the fees might ablittle bit high compared to maybe the other categories that you see happening there so this is where we could see this probably coming from. And the remain requests was they would like to us provide them with some historical billing information in the LIR Portal and an automatic payment confirmation to see they had paid their bills.

Communications and outreach, highest 5.9, keeping the membership informed about its events and activities. On the lower end, the members wanted to and this is also quite strange, wanted to read information in printed format and not only on‑line. , you know, I have overwhelming responses here telling us you should be providing all your things on‑line, no more paper and we provided a survey that turned around and said, no, we want you to provide with us more paper and not only on‑line. I think we have to strike the right balance there.

Meeting support.

The quality of support received at meetings? Actually, I am very happy to say this was the highest scoring question in the whole survey T ranked at 6.3. I wanted to you join me in a round of applause for the meeting team because they work very hard to give you this support.

(Applause).

Super‑duper. It's great team comprised of a lot of groups and we are happy to see that. On the lower end, non‑attendees want to be kept better informed and I am happy to receive any kind of input you can have on them getting better information here and we will try and get that up and moving.

Some conclusions: I think you can see we have got some satisfactory ratings from you, we think those are rated fairly high, we are on track, but of course there is always room for improvement. And I think after having run through this survey you can imagine that with the 771 responses, out of each question we left room for people to write a comment on what they wanted to change or anything else they wanted to mention about a particular service or activity area, and after having trudged through all of that, I have actually come up with some points here of areas of focus. There is no particular order or weight given to any of these, I have listed them down. One of them was easier ways to contact the RIPE NCC and this was things such as Skype or even just telephone or even different languages by telephone or with chat sessions. Better stats and more of them. This, actually, the statistics here out of all the feedback that was given that was written where people wanted to see more information, this was the single most replied to area, was they wanted to see more stats from us, it was basically statistics, statistics, statistics, and yes, we got it, that is from the services that we provide and we are taking that into account, as well.

Better interfaces to registration services in the RIPE database. Simplified procedures in registration services. And more e‑learning modules. All of these have been taken up by our managers, some of these things are actually currently taking place in or in plans already, and then of course some of these will be added into plans as we see, we can add with the resources that we have got. So we are very thankful that we get this feedback so it shows us we are on track and doing what you want to us do. So thank you very much for the great response we got on this. And I would like to thank one of my colleagues Fergal Cunningham who was a real trooper in trudging through all of this information and did he a lovely job in summing all this up so thanks, Fergal, and with that, I will take any questions.

CHAIR: OK.

(Applause)

Last we have Robert to talk about the validation of the resources.

ROBERT KISTELEKI: Thank you very much. My name is Robert I am working for the RIPE NCC science group, I am the manager there and today you can call me Speedy Gonzalez. I am going to show you some results that we did, we have about the resource registration data quality measurements, why we do it, what we do and what we have found out so far. First of all the need to measure data quality. Why are we doing this. We have several answers but most of all, we want to be aware of the data quality inside our own databases, of course that sounds like natural. We want to demonstrate that our data quality is good or if it's not, we want to know about it and we want to fix it. It's also true that our basic duty is to be Good Shepherds of data and our strategy focuses on that. So we need to know if our data is good.

The NCC registration data is not just the RIPE database, it's a whole lot of other things including the RIPE database. It contains legacy data, so data that actually was built before the RIPE NCC was born. There have been a couple of policy changes over time which means whatever we considered to be clean or dirty today, may have been dirty or the way, way around, clean back in the day. But we need to know it. Also, there have been a couple of events, for example some of you might know ERX, that were one time events and they affect the data quality that we have today. These events, most of them, were just a project that started and finished but there was no proceed tour maintain the quality of the data that was transferred during these projects and that is a problem. We also happen to manage a lot of user entered data which we are not responsible for but it's quite of mingled with the data we already have, so when someone tries to judge the data quality of the RIPE NCC some people say, well you should include the user entered data, some say you shouldn't, but in any case we need to know how good it is.

Also, some of you might remember this, I don't certainly because I was not been here, but some of you might remember it, the term registration of last resort. So basically that means whenever you had the resource in this region and wanted to put into some database because of some reason, most probably you wanted to show the world you have that, but you couldn't put it anywhere really, then the RIPE NCC was the place to be, we gave a platform to register those and those are still in our database. Most of the time you can't do anything with it, it's there. But it contributes to the quality of our data. Or the perceived data.

Now, I am sorry for ‑‑ Rob, but I am actually going to show there are green and blue and yellow data so. This is an image that we made for another project which I am not going to talk about in detail. But what you can see here is all of the /8s that are either administer by or allocated to any one of the RIRs. The colour code is at the bottom, the green one is RIPE NCC and blue is ARIN and pink is APNIC and LACNIC and red one is of a if I can. Each the horizontal bars represents one /8 and the prefixes that you can find in the so‑called stats files which I am going to talk about it a bit later, are actually mapped on to these bars. So, I just wanted to show you that it's really colourful, most of the time when it's allocated to the RIRs it's relatively clean except for a few transfers. But on upper right‑hand side you can actually see some really, really colourful things and that is where the issues are most of the time.

Other incentives: There were a couple of talks before me so I am into the going into the details, a couple of policies we need to support and need to know how good our data is to support them. We want to be ready for inter RIR maybe but certainly intra RIR. We don't want to certify data even we consider to be dirty.

So what is registration data quality is an internal effort to measure, monitor and enhance internal data quality. We want to measure so we want to know how clean or dirty it is. We want to monitor this. This is not a one time effort. We want to do it every day so we can tell if the data quality is going up or down. And hopefully it's going to go up. And also, enhance, so if we find something that is wrong, we want to fix it. So the two main goals based on this, are we want to be aware of what data we should be responsible for. Now this, sounds like an easy question but it's not as simple as you might think, and having an answer, yes, to this question, we want to know who has that data and are we sure or not.

At this stage of the project, we are focusing on v4 data but want to includes v6 and AS numbers at some point. The reason being IPv4 is considered to be dirty for some reason. IPv6 relatively new and should be a bit cleaner. If you look back at the goals, we actually want to achieve that so we define ourselves two questions and we call them two naive questions:

If I have a resource in my hand I want to know if RIPE NCC should be able to tell me if it's theirs or not. Yes, no.

Question number 2. F the answer is yes, then who is the holder and how sure we are about that.

Concentrating on question 1, we have built a framework that supports just this, it can evaluate all known and available databases, either internal or external, so it has to be known by us. And it also has to be available, so for example we know about ARIN's Whois database and we know about all the Whois databases but it's not available until we can mass civil query it so this is something that still needs to be done. What it does is actually can check whether the information that is contained in different databases is consistent. If one says yes the other should as well. This framework with do this on over time period so, like today I want to ask the question how good is it today and we also want to do this as time goes on and history goes looking back and see what we find.

We started actually measuring regularly and I am going to show some graphs over that and we started to fix the inconsistencies. We is the whole RIPE NCC so it's not the science group only, it's registration services, science group DNS and at some point involve database.

We are including internal registration databaseses, there is more than one. We have to maintain the consistency. Reverse the the NS services obviously this has the most operational perspective so we expect this to be the cleanest, if it's not people will speak up. But still we want to measure whether it is consistent with others or not. The stats files are the files that each the RIRs publish every day and it contains all the allocations and assignments that the RIRs did. So this is kind of the peak into other RIRs databaseses that we can use. We also include historical transfer information, as I mentioned ERX that was done from ARIN to the other RIRs back in 2003ish and the birth of AfriNIC, when it was created we handed a couple of prefixes and resources that were used in that region. It's transfer information, it's recorded we want to be sure it's included. IANA assignments and allocations pages. We want to make sure what they say we believe, or the other way around. Or any combination of those. This is one of the reasons why Daniel mentioned yesterday that we would like to have IANA information.

Explicitly excludeed from this stage is RIPE DB it, doesn't add too much information in terms of whether a prefix is RIPE NCC's or not. We also have covering objects over not yet allocated objects, so it doesn't really add enough. We are not including other RIRs Whois databases, we don't have good access to that, but we are working on it.

Right so. What do we do? Our approach is simple, we want to know if resource is RIPE NCC's or not and we simplify the question to be a specific IPv4 prefix, so when I say prefix it's IPv4 range but we are really looking at prefixes. We are asking all overt databases whether they think that this specific prefix is RIPE NCC's or not. This is really easy, sounds easy. The answer can be yes or no, I think it's not or I have no idea. For example, if we are looking at the APNIC stat files the answer could be no if they have it and it's included in their stat's files enit's obviously not RIPE NCC according to them. Or they can say well, I don't know. For any other prefix that they don't know about, it's not in their stat files. So we combine all of these responses into things that we call gene sequences. If couple of database say it is RIPE's and we don't know, it might be, then we consider it relatively OK so, most of the database agree this is RIPE NCC space. On the right‑hand side you see another example, when some databases think it's RIPE, some others think it's not we need to decide who is right, who is wrong. We need to look into this.

The beauty of this approach is is that we can categorise prefixes and we can look at which prefixes have the same gene sequence, so if for example this prefix represents a blue elephant, every blue elephant we can categorise by this kind of method, or the other someone like a black cat, let's call that the last one because that is more often in real life and the other someone like blue elephant so the thing is once we did this we have clusters of prefixes, of resources and if we find out to solve the issues with one cluster we can be sure we fixed all of the problems in the same cluster. Once we see a blue elephant, we paint it grey, that is fine, we solve one problem but in this case we can find all the blue elephants and we can paint them all grey, which is not good for biological diversity, but that is not the point.

Some numbers: As I said we are measuring prefixes, so all of the these things are IPv4 prefixes. And on the right‑hand column you can see the address space usage in terms of /8s. What we consider RIPE NCC is roughly 5,000. Out of that, native RIPE NCC space if I can call it that, 29 /8s and transferred from other RIRs is roughly 5 /8s. Claimed by other RIRs, this means these prefixes appear in some other RIRs stats file. It's a surprisingly high number and the reason for that is ARIN claims all the legacy /8s. Whether it's right or wrong it's out of scope. You are not judging that but they do claim T

Transferred to other RIRs from the RIPE NCC which is the opposite of transfer to the NCC is roughly one /8, unallocated by IANA and unclaimed RIRs is a total of 48 /8s. This is again, a surprisingly big number, includes the 32 /8s unallocated by IANA, as of last week is just 30, they allocated two to APNIC. Claims the unclaimed space so this also includes the ERX space which does not appear in anyone's stats files, the number is tiny bit higher. The red one are inconsist enters prefixes, the problem with those is that some database disagrees with some other. I didn't want to include in how many databases, you know two say this and three that or five against one or any of that, but this includes all. But I think that the interesting point here is the detail. It's roughly 800 prefixes and roughly 5 /8s. If you look at where are those you can find out of the 830 or so, 800 constituting all, almost all of the address space consumption is the legacy and ERX space. Is anyone surprised? I am not. Allocated to the RIPE NCC that is roughly 30 prefixes less than .1, actually it's less than .05 so that is where we have some typos and all that. And there are other prefixes like 10 /8, and there is a third one. And by the way, this is ‑‑ the total is 223, that means we are measuring from one ‑‑ the whole spectrum, we are excluding multicast because that doesn't matter from this point but everything else is included.

I am not sure if this is visible or not. This slide actually shows a graph with the number of prefixes that we can observe. The point here is the blue line slowly slowly growing up, which represents the number of prefixes claimed by some definition of ‑‑ by other RIRs. The ones on the bottom include everything else like inconsistent sees and RIPE prefixes and all that. This is the same slide but in terms of address space. I think that you will not see real surprises here, the really light blue one is going up, that is the consumption by other RIRs. This purple one is going down, the purple one is the free space. That is pretty consistent with what Geoff says. The red one is the RIPE NCC claimed, including free, so this is going up as soon as we receive a new allocation from the IANA, it jumps a bit. And the others are, again, well, not that much, total of like 10 or so /8s.

Size of allocated to NCC. Well that is detail on what we think, what we say the ‑‑ this is in terms of /8s and by the way, the X Axis runs from 2004 until like today so we close the ‑‑ closed two weeks ago or something. So the red line is the RIPE NCC claimed addresses, and the other interesting one is the green one, which is the free pool. Again, this is really consistent with what Geoff says but with a completely different methodology so I am liking this.

This might be interesting. This is the number of different gene sequences in any category. So in the problematic category or in the ERX category there could be different gene sequences, we just have to cluster them into the same category. And this graph shows how many different gene sequences fall into the different categories. The interesting thing here, actually there are two: One of them is on the lower left, you can see this interesting ups and downs for this ‑‑ it's supposed to be blue ‑‑ let's call it blue line. Roughly in 2005, January‑ish, that ‑‑ I think that is actually the birth of AfriNIC. So we have the real fluctuation and the number of categories in that one. The other interesting thing is that ‑‑ if you really think about it, it's going to be the obvious, the blue one is actually growing and growing and growing and you can't really see because the text hides it but it's started to go down. The story here is that actually represents the problem I can or inconsistent ‑‑ the number of inconsistent gene sequence that is we can observe. This tells us the story if you don't really do housekeeping, good enough, then the quality of your data will deteriorate over time. It's as simple as that. Now, it doesn't mean we did not do good housekeeping but those are the stepchildren of every RIR essentially, so those are practically the ERX prefixes, this project was done and everyone was happy, the quality that have it's slowly diverseed from reality. Zoom in on the last four months, since December until today, you can see the number of gene sequences in that bad category started to drop and that is the result of the measurements that we started to do. So that is improvement in terms of data quality. The other changes are measurements.

The matrix: This is not supposed to be readable, it's not your eyes. The message here on the left‑hand side, the green, the blue and the pinkish, those are RIPE NCC things. On the right‑hand side, the yellow and brown are free or other RIRs and the red ones are inconsistent. It might surprise that you there are so many columns, each row is one /8. You might be surprised by the number of red columns but I would like to point out most of the time there are only single cells which are filled in if you can see like here and here and here. Besides that, there are clusters of things like this one and this one, so since the columns are gene sequences, these prefixes falling into those cells have the same, exactly the same problem or the same structural problem. If we can attack one of them we know how to attack the others and that is the point. We are not going to fix one prefix one by one and you are trying to figure out what the hell is wrong with it, but instead we know these are the that was have that kind of problem so we are going to fix it.

OK. There is more to do, we are slowly moving on to question 2 which is who is the legitimate holder once we know the prefix is RIPE NCC. What is our confidence level in the answer. Building a framework for this so expect this to be in operation soon, hopefully. But what it will do is it will try to match actual data contained inside the databases where previously we only looked at existence. This will likely include RIPE DB because it has contact information so we can look at some interesting data. We want to supplement our findings with routing information, so if routing is consistent with what we think our confidence level, we go higher whereas if routing changed every week then we are not that sure about how and who has that prefix. This is a bit more difficult, I will not be able to show you such nice graphs because we have to compare textual data again and there is no real measurement. Yes they match like 80 percent. It's difficult to define. So the results are not quantifiable but they are working on this. Also, we have further inspiration from this, we want to measure inter RIR consistency, we would like it to be consistent with other RIRs but do that we need active participation, we hope we will get that and are approaching the others in this sense.

Quality of our registration data is important for us. That is why we are doing this. We need we have to be prepared for the things to come and for the things that are already here. This is why we are doing it. We are working and continually measuring, this is not a one time thing, we are doing it every day and we started to fix issue.

Conclusion: Most of the problems are in legacy space and ERX space and we need to focus on this one. The other activities from the RIPE NCC so the allocations of the normal /8s is pretty clean, we can actually prove that now. We want to be able to answer this tough questions which we can call them, the ERX related ones, the least well maintained, so therefore they are the most prone to misuse as clean IPv4 runs out. Runs that you can expect bad things happening from this right corner. OK. And I just wanted to leave this on for you to marvel at me. This is where your problems are going to come from. Thank you.

(Applause)

CHAIR: Thank you, Robert and thank you for bringing us a bit closer for being on time. I think Rob was first.

Rob: I don't have a question, I want to say I am extremely pleased to see that this work has start and I think I realised and most of you, this is not a six‑week project; this is a major undertaking of the RIPE NCC and I do complement you and all your colleagues on having a very nice start.

SPEAKER: Thank you.

AUDIENCE SPEAKER: Shane Kerr will from ISC. I would also like to echo Rob's comments, this is nice to see. I believe long overdue, actually. One thing you didn't discuss here which I think may be important, is that when the ERX space was imported it was decided to leave it in a vague policy space. The ERX blocks don't necessarily belong to any RIR; it's not clear what the legal ‑‑ what the policy requirements are for the holders of this space. There is no ‑‑ they didn't sign a contract with anyone saying they were going to keep this up‑to‑date and things like that. Maybe they did with Internic in 1988 but we don't have that information. So, do you have any ‑‑ well, I think there are going to have to be some policy changes and they are going to be pretty tough ones, so good luck.

SPEAKER: Thank you. I am not the policy guy. But the point is that, we instinctively know some things that need to be changed, we need to set some policies but more to the point, what we do in this measurements will actually guide us to focus on the problems, so we will know what the low hanging fruits are and what the real issues are so in terms of fixing the structural problem we need to develop some policies, what are we going to do with the prefix that was transferred to some RIR and no longer used. There needs to be a policy for that, that is obvious. But this framework will guide us in order to help deciding the ‑‑ defining the question, first of all, and then fixing it.

AUDIENCE SPEAKER: Absolutely. It's a necessary first step, absolutely.

SPEAKER: We would like, and I would say we would love to work together with other RIRs on this one.

CHAIR: All right. Thank you.

SPEAKER: Thank you.

(Applause)

CHAIR: Before we wrap up, we have one last agenda item and like to ask Nigel to come here.

Nigel Titley: I will be fairly quick. If you are RIPE NCC members, you will know that last year, roundabout this time, we lost two board members. Now to lose one board member is unfortunate; to lose two board members is careless. And we'd like to do something about it. Our case, and Jim in the audience, please. Could you come up here, please. Jim. Ah, no. I told him he was supposed to be here. We have just lost one board member in that case. In 1997, RIPE NCC was actually spun off [Terena], decide that had maybe this Internet thing was going to catch on and they might need somebody to hand out IP addresses. And but on the other hand they didn't really trust Daniel so they insisted that Terena should have a representative on the Board, and Kase was that representative and he stayed there ever since, we couldn't get him out. And over the years, I have really appreciated or come to appreciate his many qualities, his many Dutch qualities. First of all's very dry sense of humour, his attention to detail. He never let's go of something, once he has decided it needs to be done and he always focuses on the bottom line. Could I just thank you for all your efforts and that you have put into the development and growth of the RIPE NCC. And could I say that in a large extent if, it wasn't for Kase we probably wouldn't be here because the RIPE NCC might not be here. I think we have a small token of appreciation for him. Thank you very much, Kase.

(Applause)

Kase: Well thank you, Nigel. A lot of what you said applies to you equally well. I also appreciated working with you better and better the time we worked together. But I think also many others in this audience have been here from the beginning and that is amazing and the spirit which is still alive is still very, very worthwhile, I think, and this RIPE community, which is 25th anniversary, and a child that is nearly as old, the RIPE NCC, I think I would like to congratulate you all, you are the RIPE community and you made it happen and I am very privileged to be able to serve you over the many years and to see that this work has not just evaporated but has created a strong networking community in Europe that we will need definitely in the coming years, the challenges are not over and I know you are there, I will be there, and together, we will overcome all the new challenges as well, and thank you all for your trust in me, it was a pleasure to work with you all and I will still continue to do so.

(Applause)

Nigel Titley: Now it's Jim's turn. Jim wasn't on the board for quite so long. But Jim and I go back and I go an awful lot further. I think to around about the mid‑'80s, as far as I recall. Jim was involved with Janet, that is Janet the joint academic network and not just strange female. And Janet at the time was X25 only. However, Jim got around this by running IP over X25 which seems a little bit upside down but seemed to work. Yet it was actually illegal to run anything but X25 on Janet under the operating terms so Jim was breaking the law in those days. Since then, since then he has worked on ‑‑ his work on DNS has probably benefited us all and his work on ENUM may benefit us in the future. Jim came onto the board just four years ago and did he one term, but he did a tremendous amount of work in that time; mostly ensuring that Axel stuck to his budgets, which was Jim's particular forte. We will a little bit late but we have something for him, too. I hope you can find a use for it. Thanks very much, Jim. (Applause)

Jim: Thank you. This is a complete ‑‑ a complete surprise and totally unexpected. It was a pleasure to serve the board and work with the senior members of the NCC management and I think we all know a great ‑‑ owe a great deal of defendant gratitude, at that that we all maybe take for a granted. But there is a great deal of work and responsibility they exercise on our behalf and I learned a lot from my time on the board and it was a pleasure to do that and I think quite frankly, I am a bit embarrassed to be standing here right now, in all honesty I think my contribution on the board is nowhere near as great as the other members of the board and certainly nowhere near the contribution that Kase has done over the last 20 years and I would like to thank him for everything he has done both my myself and I my term on the term and the RIPE NCC and RIPE community in total.

(Applause)

CHAIR: All right. Thank you all. We have one last and that is open microphone. We have really, really late but I would still ‑‑ this is your opportunity to bring up any issues or comments or feedback to the RIPE NCC. And unless someone is running for the microphones now, I think we are done here and for those of you attending the RIPE General Meeting it's starting now in the St. John's room to the right when you come out and we will see you over there.