These are unedited transcripts and may contain errors.
Notice: Use of undefined constant steno - assumed 'steno' in /var/www/html/ripe-60/steno-transcripts.php on line 24
NCC Services Working Group, 4 p.m., 5th May, 2010:
CHAIR: If you'd all please take your seats so we can start, because we are a bit short on time. You know you have all been waiting for this all week and finally the moment is here. It's your favourite Working Group, it's the NCC Services one. You have been going through the transport to get here. So, before we start, I have one or two small announcements. If you haven't registered for the annual meeting, the AGM, please go and do so now outside at the registration desk. Secondly, when we finish here, I am going to try and finish at 5:30 sharp ?? we are finishing at 5:30 sharp. We will ask you all to leave the room quickly, because we are going to have the AGM in here again and we are going to have to check the votes and the representation when you come back in because we are doing an electronic voting this time so we really have to ask you to leave the moment we finish in here so that we can get everybody back in here to start at 6' clock sharp for the AGM.
No problem. I'll be gone.
Kurtis Lindqvist, I am the chair. Welcome, we have a scribe provided by the NCC, which is Alex, thank you very much. And the participants list ?? where did I cut that from? Anyway.
So, I take it we can all ?? we have nothing added to the agenda. The minutes from the last meeting were posted sometime ago and I can't recall having seen any comments on them so I guess we can approve them, unless anyone objects. No objections.
So, with with that, then, we have Axel Pawlik doing the RIPE NCC report and this is for those of you who haven't been here before, also part of the AGM technically, I guess.
AXEL PAWLIK: Hello. Update from the RIPE NCC.
Yes, it is in some way part of the general meeting so I don't have to do the same thing two times. This is the update what we have done over the last half year or so.
And contrary to belief, we see the Czechs want to make us really, really at home weather?wise. We do have sunny weather occasionally at home. It's not so bad.
Customer services, those people that you probably face on the first time calling us and trying to interact with us, and this is some set of the group at some point in time. You see the important thing is they are all smiling. They all love you. If you have the impression, through mail exchange, that that is not always the case, no, that's just impression, it's not true. We all love you.
They are supporting the rest of the company in interactions with you. That's not because the rest of the company doesn't like you; no, we all smile all of us all the day when we think of you. You are paying our salaries, right. It's support for the other groups in the house. Basically, administrative stuff, contractual stuff, getting the bills out. You will have to pay them, I am sorry. Coordination activities in database and DNS user support, again administrative support, billing basically for test traffic and DNSMON. We are also trying to get into contact more ?? in more ways than e?mail. I have heard from Paul Rendek that e?mail is so yesterday; that we should all do, you know, social media and stuff, or chat, I don't know. We are working on that and we want to have as least as possible friction between us and yourselves.
Customer services statistics. We have quite a lot of members and other users. We have about 20,000 tickets handed in last year, more than that, and we did see, not really surprisingly, quite an uptake in tickets there due to the PI contractual things, but in a second quarter of this year we also see this is levelling out, it's becoming normal again. Overall response time in customer services is fairly stable one day.
Registration services, speaking of fairly stable one day, that's the same here. Also, here, there is a high ticket load, but the response time is stable and not too bad.
Reclamation project: That's something that we have started quite some time. I mentioned it before, and, surprisingly, it goes better than we thought. Basically, we are contacting people who are about to be closed because they don't react, they don't pay bills after a couple of reminders and basically have some view media results any more, some of them wake up and say, oh, God, yes, that bill, it was. And they pay, that's nice. And others say, oh, no, we really don't need to be a member and we are using some of the resources, others you can have back, that's also nice. Doesn't do anything about the delay of IPv4 but it's really proper housekeeping.
Also, you see that from '96 to 2008 we did a couple of audits. You see that, over the course of last year, we did as many. So, this is something that we think is important, again, scarce resource, running out, we need to make sure that all goes the right way and that's what we do. It's important that we do that, and yeah... it works quite well.
Again, 2007?01 implementation. Now we start entering the hot phase trying to find people who ?? we don't know where they are. Our members said we don't know these people any more, it's not our resource really. Yes, we handed out at one point in time but we don't have any contact. So, now, we are trying to get to those people.
All this, in some way, is part of the bigger effort of having a high?quality registry, again finding people who lost contact with us or we have lost contact with, and that's something that our registration services does together with the science group. It's a relatively long ongoing project and we will see a presentation about that a little bit later this afternoon.
Talking about audits. Now, we audit you and you might find that a little bit cheeky from us. On the other hand, we subject ourselves to audits as well. We have done ?? or we have had KPMG do an audit on us and processes in registration services, basically saying that, well, you have documented your procedures quite well and, actually, what you are doing, and those procedures are in line with the policies and what you are doing is also. So that's quite good.
That's how it should be, of course.
And, again, running out, before we do see occasionally a relatively large request and in?house we changed our procedures a little bit so that they are being scrutinised outside of registration services, so basically it goes into management and we look at that as well.
Registration services, then we do quite a lot of training. Strategy and goals: Of course, it's to give trainings to our members and some other people possibly as well. But more on a higher level, this, again, is another method of giving a face to the RIPE NCC, getting us in contact with you, getting you in contact with us, and to promote our messages and to hear your concerns and generally knowing what is happening.
The original idea was to reduce workload at your facilities by teaching you how to smoothly interact with us, and also, on the other hand, in?house with us. It's all running a bit smoother then when you know what you do.
Internally, again, valuable source of information of what's going out there, what is going through your heads and what you want from us, what are you missing, stuff like that. And that's basically what it says, and internally, the training on new stuff coming in and help them along.
So we have done quite an a lot of courses with with lots of people in many countries, and, also, we have broad spectrum of courses. For quite sometime, we do IPv6 courses now. We are very popular, which is nice to see. We do also offer presentations at other people's events. That sort of fits into the general area of what the RIRs do, what the RIPE NCC does. So we did several presentations at various conferences. They are basically trying to represent ourselves, representing you and talking about, in general, about self?regulation and how great this all works.
Then we have a couple of people in the training department that love to play with knobs and buttons and cameras and stuff like that. We found out that we can use that quite well for other bits in the company. You heard about IPv6 Act Now, the website, that little testimonials, little movies. We will, for the first time, do e?voting during the general meeting, and it appears occasionally to be a little bit complex so we made a video about that as well. Things like that.
That's not our course. We do lots of courses, as I said. The traditional LIR course, also IPv6 course I mentioned, routing registry courses and workshops on requests, depending on what it is, and basically, our attendees are all happy people and, you know, they smile a lot, as you see.
Legal update:
Well, basically, this goes about a number of things in the legal department, more or less. One is closure of members. For various reasons, they want to go away or they merge or they don't pay their bills any more, basically saying we need to be very, very clear, and I did hear you, Ruediger, wherever you are ?? so I hear you, we need to be very clear about our processes and our procedures and the reasons and it needs all to be very well documented, and we are working on that on the closure side. And we will, then, update the RIPE document. Currently, it's 301. We'll have a document on mergers as well, of course. This is our preparation, but we will hear your, or our community input, for that.
Also, we used to have a data Protection Task Force, but I think is now wrapped up. It was good work, it was around the RIPE database and eventually we also participated through the taskforce in new consultation on the data protection directive they have.
RPKI: Obviously there are lots of things there that sort of intersect with the other sections in, sort of, closure of members and what we do, and so that's, again, something that might be part of, I don't know, part of a registration policy, or the RIPE 301 document, or maybe it's all going to be the same or similar. But the point is, we need to document these things. We don't want you to be in any way not quite certain about about what might happen to you in what case. So all this needs to be clear.
Arbitration: You know that for cases where we end up in a tussle with members or in between members fighting for the same resources, we have an arbitration procedure for a long long time, and it sort of works; occasionally, it is called upon, not very frequently. But we find we can certainly improve the whole thing. So basically, the concept here is, that's basically the whole slide. The concept is to use the arbiters who made their time available in the most efficient way being able to serve as, let's say, expert witness, and to have the process of the whole ?? or the procedure of the whole arbitration thing run by somebody else, not the arbiters themselves, not the RIPE NCC, obviously, so this is basically working towards that.
In?house achievements in the IT department:
Of course, there are lots and lots of little things that you probably don't see apart ?? hopefully on the nice graph later on where it says we work much more efficiently than ten years. That's part of this, of course.
And the last one I have to mention, all external services, IPv6 enabled by now.
Software support: Again, lots of internal things that we fix, that we rewrite also, new meetings software and billing software and integration of those things. Certification, certainly, as well, the certification system. Something that we looking forward to, especially registration services looks forward to very, very much is new resource database. The old what you call "reg" is based on text files and a couple of them and in weird places. It works, but one nice integrated database will work much better, so we are looking forward to having that by the end of the year.
In general, software, we are looking at how we do software and they started to work and according to the [agile] methodology and that sped a little bit through the company into other departments. Basically, we see it does actually work. It speeds up the whole process, and users are, in general, happier.
Information services: NetSense, you have heard about that, is being developed. DNSMON gets a new interface. And we have plans to do something with the test traffic measurement network, that needs to be refreshed as well, that's getting quite old and we are looking forward to the rest of the year for doing that.
The science group: Basically, the main task is research and development there, to look at future services, to find out from you, also, what you would want. We are sitting on a pile of data, that's a shame if we only sit on it. We want to do something with it and present it and sometimes we come up with ideas for ?? or new sets of data that we might need, or we are open to hear from you about that.
And, of course, lots of writing in there as well, and lots of that in labs, but Miriam is going to talk about that, so I won't now.
[REXP], Resource Explainer Prototype, is available on that place on the net and we have heard it is useful. Have a look what it does for you. And in general, science group looking at data quality together with registration services, I said that earlier, and also, again, future needs of the RIPE community, of our members and of the RIPE NCC.
DNS department basically looking after our root server cluster. Now, with DNSSEC, it becomes a little bit more interesting. It's the 5th of May, is the Internet still there? That's nice. So lots of improvements there in that area as well. And then, of course, we go into the area of communications and external relations and representation of the ?? what was it? Internet self?regulation ??
The idea is to represent your interest to as many stakeholders and new stakeholders as is reasonably possible, without stretching ourselves too thin. No, we are not a lobbying organisation, but, on some little bits, we tend to try to speak for the bigger community, and actually, it works quite well, I think.
Many of these things we do together with the NRO, a whole row of abbreviations there. I did it and said, guys, you can have Paul Rendek for 50% of his time. He is doing more than 150% by now, but it still works, it's good. And he sort of laughs about it.
IPv6 awareness, obviously, is important. IPv6 ?? IPv6 Act Now, it should be. We do quite a number of press briefings throughout the company about all things, certainly IPv6 and some DNS here and there. Some general awareness of what do the RIRs do and how do they work together with with ICANN and things like that. So that's on the increase, as well. We joined the ITU as a sector member, not because we find the ITU such a great organisation that we need to be a member of those; it just hurts so much if you are not and you need access to the documents or you want to go to an ITU meeting and then you have a really hard time finding somebody to write you an invitation letter and you spend so much time on it. Becoming a sector member is simpler.
Other events: Our own events, RIPE area and RIPE NCC events. There is our own. There is, obviously, this, but there are also roundtables that we hold regularly two times a year for governments and regulators, again talking to new stakeholders. We do regional meetings trying to bring news from the bigger RIPE area into sections where ?? of the community where we don't see that much participation in the regular RIPE meetings; that, so far, was the Middle East and, well, we went to Moscow quite often as well. Those things generally very much appreciated and they tend to spawn off new groups, the operators group, MENOG for instance. MENOG, for instance, is a great success, and we hear rumblings from the Russian region that something is going to happen there in that sense, as well.
Then, of course, we go and go to other people's events. Other people's events. Speaking about the IGF and similar things, but also law enforcers, the police force, basically, internationally, they do hold big meetings and talk about cyber security and the Internet and they tended, originally, to have very strong ideas of what, for instance, the RIPE NCC could do for them, and then we say, look, guys, not quite as you think. And I have a slide on that.
Then, of course, because Paul has so much energy and enthusiasm, we think up new events for him to organise, like regional roundtables. We have roundtables, we have regional meetings; why don't we have regional roundtable meetings? That's something new and different. Basically, for the governments, again, in those regions where we don't have that much contact yet.
IPv6 roadshows, carrying IPv6 addresses around to show to people to see how nice and gleamy they are and they get workshops and trainings, and if they then think they need IPv6 addresses, they get them right there on the spot, and again, we want to tour around the Middle East with that one.
Law enforcement, I mentioned we have had contacts with law enforcement, basically, from the UK and from Holland for about, I think, three or four years, and, like I said, sometimes the ideas on both sides are a little bit off. So the reason we do this is, of course, well, first of all, we have to. If we don't, then that's not good. We increase understanding of the role of the RIPE NCC, of the role of RIPE, of the role of a new stakeholder group as in law enforcement. Some of them are here. That's great.
Basically, it's about managing expectations. We tend to understand better now how they think and what their issues are and they understand that we have to do what our members tell us, first of all. Then they understand better how the policy development process goes. Like I said, our first responsibility is to our members and to our community and to fulfil the tasks that you give us.
But then we go and participate in law enforcement meetings. There was a nice big international meeting in London with, I think, up to 80 fairly high?level officers from around the world, from every larger RIR region, basically, and they were very, very happy to see that all the RIRs had also some representation at that meeting, and it was a nice full room, it was lovely.
So, again, this is defending the industry self?regulation there.
All right. That's for you. We do talk to you frequently. We do talk to you quite a lot in the corridors and over food and over beer, which is great. We do publish documents like an activity plan regularly every year. We post it, we make it publicly available, together with the draft budget and a charging scheme, and we expect some sort of feedback from that and we rarely get it, apart from in the general meeting where people say, "oh, that's cool". So it would be nice to hear a little bit more about what we should be doing, what we shouldn't be doing, what is great that we are doing and what is not quite so great, and some of you, I know, are more out spoken than others. This is basically asking the others. It would be nice to hear from you.
And, I think, that is more or less on the dot. If there are any questions now or later during the AGM part, I am happy.
CHAIR: Any questions? Next up is Miriam, who is there somewhere.
MIRJAM KUHNE: My name is MIrjam Kuhne. I just realise that you get to listen to three German accents in a row now. I don't know how we managed to do that.
I am going to talk about the RIPE Labs and some highlights. Last time I presented that, I was brand new, last time, in September, so I presented it in the Plenary and now I thought there are many new ?? a lot of new content on RIPE Labs, but a lot of it is also, you know, relevant to NCC Services and to LIR, so I decided to present it here this time.
As a reminder, also, for those many newcomers who are here this time, what is RIPE Labs? Well it's a website in ripelabs.net. It's been mentioned a few times during this meeting already, and it's a platform for new ideas, new prototypes, new tools from within the RIPE NCC, but also from outside, so ?? but Axel just said also to provide feedback, that's another big aspect of RIPE Labs. You can use the forums there, comments, facilities on the site to let us know if, you know, if you find useful what's on there, if you like some of the tools and prototypes, and then, based on the feedbacks, we might decide to develop this into a proper service later.
Just want to give you some highlights that what that is been published in the meantime since the last meeting. That's really only a snapshot. There is much more on it. It's great, actually. There are so many new ideas and so many good innovations and ideas playing inside the RIPE NCC in various groups and that's the place for them to be published and to be shown to the community, and also, outside, there are so many, you know, tools that people are developing that might be useful for others in the community and it's a good place for those new ideas to be shown.
So, just some snapshots, some highlights that have been published in the last few months and weeks. We have done ?? and all these things there have been developed by various people in the RIPE NCC and our science group training, database people, RIS, IT, so it's really quite a ?? it's the whole RIPE NCC is involved in that, which is great.
We have done some statistics on LIR, numbers of LIRs over the time, where they came from, what countries and regions and, also, how the address space has been allocated to those LIRs over time. So you can find some pretty pictures there on RIPE Labs. I put the URLs on all the slides for the tools. Some of the stuff is not so easy to find any more because there is so much on it right now, but I'll get back to that at the end.
We also are working on an LIR locator tool that will be officially launched next time. I want to give you a little sneak preview here and some more description on RIPE Labs where you ?? provide a little map and some facilities for LIRs to log in and provide the exact location of the LIR, together with services that they provide and they would like to announce there or promote there on the side.
There is a lot of ?? there a lot of measurements and statistics and graphs that we have been doing, and, as Axel said, we also have a lot of data in the RIPE NCC and there is a lot of data also in other organisations and we have done a lot of measurements and statistics based on that.
I don't want to go into too much detail about all of this. A while ago, we published a compilation of measurements and statistics that others are doing, because it's not only the RIPE NCC, obviously, but also many other organisations who are looking into this. So we kind of published a list of the six measurements and it might be ?? it might be ?? publish a follow?up of that, but at least it's in one place now.
And Emile has presented that already earlier this week, some IPv6 measurements he has been doing and resolvers and clients connecting to labs and to www.ripe.net.
Another work that's been done by Information Services in the RIPE NCC is the measuring of number of tunnels and has it been decreasing over time, so you can find some information there.
And this has been mentioned before, I think, also if you just published it earlier this week, or last week I think ? kind of a rating system. There was some discussion on the IPv6 Working Group list about that. It's a bit of a ?? it's kind of a rating system for LIRs in our service region, based on four criterias that ?? criteria that we picked so far and we combined that in a map or in a graph here by countries. So if you are interested in that, you can look at the graph in some more descriptions on the website there. I think, as we mentioned before, Slovenia is doing well there.
There is also a DNS?related stuff on RIPE Labs, and the description or the announcement around DNSSEC and signing the root has been popular and mentioned various times in other media and especially the tool, the reply size tester tool that all DNS folks have developed as a little tool that you can use to test if your resolver still works, you know, if the DNSSEC is switched on. That's been done many, many, many times, so that seems to be a useful service for the community.
The database people have developed a lot. I think they are going to present more of that during the database Working Group. So I just want to give you a little snapshot here. It's a new interface, a new programming interface for the database, based on the restful services and there is a description of that and some documentation on RIPE Labs. And the last thing they published was also an abuse contact finder for a database, which is something that the community has been asking a few times and that's one way now to maybe get easier to that information.
In summary: Why did we start this? What's the benefit of RIPE Labs, also for you as a community? I mean, for the RIPE NCC, it's a place to put out ideas and tools and prototypes that we have been developing and a lot of this has actually been developed, anyway. It's not a lot of additional resources we have to put into it, and many of these things have been developed in order to facilitate other services that we are doing, and then, as a side effect, we figure, oh, this might be something interesting also for you, and so it allows you to see, you know, more what we are doing internally and also give us feedback and be part ?? and be closer to our developments and innovation, and so we hope that this will be useful for you.
What's next? As I said earlier, there is so much on RIPE Labs right now it's hard to find things. In the beginning, we didn't really know exactly how this was going to evolve and what topics would be on there and what the right structure would be, so, based on that, we have reviewed ?? based on feedback we got also, we have reviewed the structure and the concept of RIPE Labs and the layout, and we are working on a new website and on the new structure which will be much more based on dialogue and conversation. It will be easier to leave comments and to let us ?? give us feedback and maybe rate certain tools and articles and content. And it will have, like, tag clouds and topic clouds and a [] /SWEUT err feed and all the modern communication mechanisms on there. And it will be easier to find topics, also, and they will be structured around projects, like, for instance, database might have their own area, you know v6 discussions could have their own area and then everything related to that would be easier to find.
Just to give you a little sneak preview of how this might look like. It's not complete, but you will see a tech cloud in the middle, a Twitter feed on the right?hand side and a list of regular updates and articles. So stay tuned. That will probably be launched at the end of the month, end of May, early June. And I think that's all I have to present.
(Applause)
CHAIR: Questions? So, next up is Arne.
ARNE KIESSLING: Good afternoon. I am here to give you an update about the policy implementation 2007?01, or contractual requirements for independent resource holders in the RIPE NCC service region.
CHAIR: I'll just say the ?? to remind people, if you haven't registered for the AGM, please go and do so outside.
SPEAKER: So, policy implementation 2010?01. The background of the policy is, basically, that the RIPE NCC needs to be able to ensure that an end user holding independent resources exists, continues to exist, they continue to fulfil policy requirements, things like that. So this is all talking about IPv4, IPv6 PI address space, AS numbers, Anycasting assignments, etc.
The whole thing was started implemented in 2009, in March, and we decided to do this in several phases. Phase 1 started in March, as I said. Focusing on new assignments only, so, since March, everybody who came to us asking for independent resources had to have a contract in place with a sponsoring LIR or directly with the RIPE NCC becoming what is called a direct assignment user.
Since then, about 5,100 resources have been assigned under this new policy. And now this continues to grow.
It seems also that all the LIRs have adopted the policies, they are aware of the contractual requirements. They know they need to also prove that the end user exists by sending the company registration documents for the end user and for end users who really have no choice or chance to find a sponsoring LIR, they still have the option to sign the contract directly with the RIPE NCC.
If we look at the assignments that we have made under the new policy in total. There is about, there are 50/50 split between PI, IPv4 address space and AS numbers. And there are a couple of IPv6 PI assignments in there and some Anycasting assignments. So, not a surprise, actually.
Currently, we are in Phase Two and talking about existing assignments. This is because the policies as done there must also be a contractual relationship in place for resources that were previously assigned or before this policy was accepted and implemented. And we are looking at about 27,000 resources in total where LIRs had the option, in step 1 of this phase, to provide feedback via an interface that was established that you can access from the LIR portal to tell us the resources that are in your registry, the independent resources, are they used for your infrastructure? Are they used for one of your customers or are they assigned to one of your ex?customers that has now moved to another provider?
That stopped, or ended in September last year due to the billing, because, with the policy, there is also now a price tag or a fee included for independent resources, people need to pay, and there is the charging goes, because the charging goes through the LIRs, they had the option to exclude resources assigned to companies or to end users that are no longer their customers. And afterwards, the second step, of course, requires the LIRs to provide the documentation for these resources as well, signing a contract with the end users proving that they exist, signing the registration documents. Initially, that was planned to be finished by the end of 2009. It turns out that it took the majority a bit longer to sign the contracts, get the documents from the customers. So, basically, it was extended. It will ?? phase two will end in one?and?a?half weeks. So there is still some work to do.
First of all, the feedback that we received in the first step of name server 2. This is really, actually, a very, very good number. You see there is about 3,400 resources where we didn't receive any feedback. So the majority of resources, 23,500, informing us this is a resource for my end user, for our infrastructure or not for our infrastructure or end user at all.
And this is basically what it is looking as of last week, so the numbers here are based on numbers from last week. This is what we got so far. We have about 6,000 resources where LIRs said this is assigned to an end user that is no longer a customer of ours. This will go into the next phase, actually. Then we have about 5,600 resources marked as used for the LIRs infrastructure. For these resources, of course, there is no contract required because the LIRs already have a contract with the RIPE NCC. We know that you exist, so this is not an issue. And about half of the resources are basically used by end users, assigned to end users. Since mid last year, we have approved about 3,000 contracts so far for such resources and looking at a backlog of documentation that we have received of about 4,700 at the moment and about 4,200 resources have not submitted the documents yet, so we are still waiting to receive that kind of documentation. There are several reasons for this. It could be that it is actually, for example, the DIS number of an organisation that later became an LIR which is still listed with the previous LIR's registry. Things like that. We also, on a daily basis, moved resources from one LIR to another, upon request, upon receiving the documentation for this. So this is something we are busy with as well.
And looking at what we will have to do in the next phase, the results taken from phase two. So this is what we will have, we'll be looking at. We will need to contact all the resource holders where we didn't get any feedback, where the resources have been marked as this is not my end user any more and also where the LIRs have not been able to provide the required documentation by the end of phase two.
So, all these end users, we will have to contact directly. That's about 13,000 at the moment. The planned start of phase three is September 2010. We are working together with database and business applications department to assess which is the best way forward. We are basically planning the process, how to contact the resource holders directly, what kind of ?? or what contact information to use, which level of contact to use, and so on. So we are really trying to ?? or having to get in touch with the end users with the resource holders directly. There will also be a procedural document published before phase three will kick in, so this is something we are working on as well. This will be made publically available, of course.
But in order to plan this in a sufficient way that works for both, so for the LIRs as well for the RIPE NCC, we would also need some input feedback, ideas, suggestions from the community. For example, if you look at resources where it is not possible to contact the end user over a longer period of time, contact details in the RIPE database are not up to date. There is no way to get in touch with these end users. If you look at the reclamation time lines, would half a year of time for the end user to sign a contract be enough, or would they need more time or would this be too long? Things like this. Also, in which order to contact these end users? If you look at these, should we, first of all, try to contact the end users that have not been able to sign a contract yet but who confirmed they will sign a contract, or should we look at the ones where the LIR was not able to contact the end users themselves? So there are several ways to get in touch with the end user and we are assessing the best way forward, but, of course we would really appreciate if you could also give us your input ideas. You can always contact us, we have an extra mailbox for all these end?user?related issues, enduser?contract@ripe.net. So feel free to send us your ideas. We will evaluate them and then see how to best move on.
Any questions?
AUDIENCE SPEAKER: I have a question about this phase three. There are some customers and some resources which you are currently unable to contact with the user, yes, as I correctly understand? My question is, have you made any research looking in the BGP table or whatever and try to find out how many of those resources will be probably reclaimed? Because if they are not in BGP or ?? they are probably so?called dead. Do you know the numbers?
SPEAKER: Not really yet. We know that there are resources out there that are not actually in use any more, that could be reclaimed. We also actively do this right now already. We also look at when we have problems, finding the end user, contacting the upstreams, but there might be reasons why an end user is not announcing their PI prefix on the Internet over BGP. Why it's not visible, for example.
AUDIENCE SPEAKER: I had understand that. Still, there could be a number of resources to ?? that we can reclaim and the number could be interesting.
SPEAKER: Yeah, good point. This is part of the procedure now already when we get documentation for resources, we do checks; if the prefix is announced, for example, if the AS number is in use in line with the policies, if it's multihomed, for example. And if not, we try to find out the reason. We ask the LIR, and then, in the end, in phase three, we'll have to ask the end user what's the reason for this, so we definitely are taking this into account.
AUDIENCE SPEAKER: Okay. Thank you.
CHAIR: I have two questions, by the way. One was: You didn't say this explicitly, but I assume that if LIRs happen to know that we have users, customers, whatever you want to have PI space, you want them to just send this in?
SPEAKER: Of course, if there is an end user, the LIRs know they are now with another LIR who will sign a contract with the end user. You can always send us an e?mail, inform us about this and we'll follow it up.
CHAIR: That's sent to the hostmaster, as usual.
SPEAKER: Hostmaster or preferably to end user contract ?? we have a mailbox for this, because the workload for the documentation is so high it would have an influence on the service level and we try and keep that, of course, stable and have an extra mail position with ?? where we process end user requests, moving resources, providing documentation, an even after phase two is over, so if you haven't been able to provide the documentation in time, you can always send an e?mail there with the documentation, if you have it, when phase two is finished. Of course, it's to us and to the community, more important, to get the end users to sign a contract with the sponsoring LIR, instead of excluding them from signing a contract after mid?May.
CHAIR: My second question was ? maybe I missed it in the slide ? did you say that you had decided on a time when you stop trying to find someone and declare this resource is not in use?
SPEAKER: This is, basically, when we really have no way to get in touch with the end user, where we tried several levels of contact details, admin C, taxi, maintainers, maybe the upstreams, and so on, and if there is still no result from the end user or somebody might not be willing to enter a contract with a sponsoring LIR or with the RIPE NCC, then what to do with with those resource holders and with the resources. And they are ?? for this, we would basically appreciate your feedback and your input how to tackle this.
CHAIR: I'll give you my personal feedback. I think there is only that reasonable level. I mean, what you said here seems to be thorough attempts to go and find these resource holders. It might be that, let's say, some time X, maybe we should put it in a proposal after a year, two years, we seem to publish all the prefixes or the resources and then say that a month from now they are recoverable to RIPE NCC. Publish it widely ? all the mailing lists, forums, etc.
SPEAKER: That might be one option, for example, so your feedback, input, definitely for this phase and for the future steps, how to follow this up, is definitely appreciate and needed.
CHAIR: So a third question, we actually have some time, so you said you were going to write up the proposal, but you will be starting in September. I note that that means we have to do this discussion on the mailing list before the next RIPE meeting because you'll be starting this before you get the chance to meet next time. I guess you are proposing that the NCC Services mailing list for ?? that would be some sort of written proposal, but not a formal policy proposal but a written plan, if you want.
SPEAKER: Well, that would be part of the procedural document, so the time lines, all these things, how we will go ahead, but there will probably be a communication on the mailing list before to get feedback if, yeah, everybody considers this a feasible approach or if there are any issues, if there are problems out there known only to the LIRs that we might not be aware of.
CHAIR: Any other comments on this? I see Ruediger going to the microphone.
RUEDIGER VOLK: Even if the timing of the meeting is not nicely aligned, please make sure that actual proposals for the final decision are there for the procedures in the policies at the next meeting. I assume there will be others things that actually need to build on it.
SPEAKER: Yeah, will do.
CHAIR: That's a good ?? they might actually do some sort of, well, if I say last call, people think I talk about a policy, but at least say this document sometime in August is what you'll be executing and then ??
SPEAKER: For this is only a planned start date so it's not set that we will definitely be able to start in September, and we will try to do a test?run in summer to see out of a certain amount of resources, trying to contact end users directly, how much feedback do we get, and then, based on the result, we can also estimate the way forward and figure out how to do things.
WILFRED: I am just wondering regarding the orphaned resources, it will be interesting for me, and maybe probably also for your end, to find out whether our situation is typical or just completely off the average. I had to work through a reasonably short list of resources, and I know the correct situation and the correct context for all of them, with one expectation, but about one third of those I sort of clicked them away as not my customer, not belonging to me, not my infrastructure, because the receiving organisations have, in the meantime, already become a local LIR in their own standing and the question actually is, sort of, what I am wondering is, is this a completely atypical case that I know that stuff or whether this would be something to consider like in a certain way re?opening that LIR portal space, and, at the orphaned component, just offering an input field and if I happen to know what the proper local registry is to contact, I usually know even the sort of the A T dot X Y Z 999, if I could put that in that could may be a useful information for you sort of where to start with contacting. But it may be a completely atypical case.
SPEAKER: No, this is actually happening quite often or from time to time, that end users contact us directly. We have this AS number but we can't see it in our registry file, or, basically, LIRs tell us this, they got it when they were not an LIR, it's with another LIR. This can be transferred, so that's a good point that we will definitely also take into account and maybe look into re?opening this interface that LIRs who marked resources as not my end user because they are not used by an organisation that became an LIR can give this feedback and kind of reduce the amount of resource holders that we will have to contact in phase three.
CHAIR: I actually think this was proposed in one of the mailing lists when we started this and I can't remember why it wasn't implemented, but there was some reason given by the NCC, but I can't remember this. But I recall this before.
Any other comments, questions? No. So, you'll be looking out for a mailing list between now and September and commenting frequently. All right. Thank you very much.
(Applause)
So we now are actually five minutes ahead of schedule. You can have plenty of time to do a demo now. Next is Robert with small little things.
ROBERT KISTELEKI: So, I'll try to use my lovely Hungarian accent instead of the German one.
This talk is actually three lightning talks in a row, so please, if you have questions for them, try to hold them back until the end so I can answer them in one batch.
First one is PI usage trends. This was done by my colleague, Rena [Whelan]. We started out with some initial questions that came naturally after the 2007?01 policy was implemented in 2009, March 2009. One of them was, as you can see there, so how did things change after this policy has been rolled out and the procedures are in place? Do we see any behavioural changes there? Do the trends change? More importantly, do we see that, because of this policy implementation, LIRs started to switch over from PA into PI for various reasons, mainly financial ones? And if that is happening, is it happening on a large scale so that it actually affects the RIPE NCC?
So, for that, we actually looked into some more details. What you can see here is the full history looking into our internal database, the full history of allocations that the RIPE NCC made ever since 1947, I guess. So this is more or less up and to the right, except for ? which is trivial, I guess ? that little hole there, which is like 2001?ish, so when the industry was not that happy. But, beyond this, what you can see is that, yes, it's actually growing. You can also see the different colours represent the different regions; western Europe being red and blue is eastern Europe and the Middle East. Most of the time you can see that on the top here.
So, let's look at the PI assignments. You can see that there is a huge, huge bump around '93. That's where the NCC was formed. So that's kind of natural. But ever since, roughly, '96, '99, 2000, let's say, it has been steadily growing, except for this little hole here and the green bars. This one actually shows you the introduction of CIDR and this one introduces the 2007?01 policy implementation. So the conclusion here is we can see that, just after the introduction of this procedure, there was a noticeable dip in the amount, actually the number of PI assignments that we made.
So, why is that?
This is actually a different perspective before answering the why question. This shows the amount of address space going into the allocations. So, it goes hand in hand with this slide. You will notice that the scale on the two slides is actually the same. So, this, on the Y scale, shows amounts of /8s per months given out. You can see that there is a steady growth, there are variations for a while, but for the last three or four or five years it has been stable floating around .2 or .25 /8s a month.
If we look at PI address space consumption. Again, same scale. Not logarithmic. The scale goes up to half a /8. What you can see there, except for that interesting spike there, except for that, the actual amount of address space that we gave out for PI is almost negligible compared to PA. That spike over there is an administrative artifact. We actually had to move some of the previous assignments to an existing LIR, so it's not a real assignment; it just happens to be there because of administrative reasons.
Another perspective on this is if we look at the size distribution of locations versus assignments. So on the left?hand side you can see the allocations. On the right?hand side is the assignments, for the last ten years or so, ever since 2000. You can actually see that because of the minimal allocation size, there is at least 200, or so, IP addresses going out for each allocations. That's kind of natural. If you put that into comparison with the PI assignments, you can see that even if we made a whole lot more PI assignments, the total address space consumption is probably going to be much lower.
Yet another perspective: If we look at how many LIRs make how many assignments, then this is what we see. On the left?hand pie chart you can see that roughly 75% of our LIRs never made an assignment, okay? The middle pie chart actually zooms in on the ones that did at least one. What's interesting to see is that ?? so out of this 25, or so, percent, roughly one?third of them only made one, ever. So, this is, I guess, as of May 2010, so like a week ago. And obviously there are fewer and fewer LIRs who have more and more assignments. So if we zoom in on the ones that have 20 or more, this is what we see. 22, we have 21, that's fine. But it goes to extremes and up until 530, I guess, that's the maximum currently, or as per last week. It might be more.
Yet another perspective, but resembling a previously seen one. This is, again, PI assignments over time, but zooming in from 2000 again. But, it actually shows what kind of LIR made that assignment, so the colours represent somehow how many previous assignments did the LIRs already do when they received an assignment in this month. So you can see is, yes, from the left?hand side, it's up and to the right. What we expect, except for the dip close or actually covering the introduction of the policy. What's interesting to see here and to note here is that the green stuff at the very top is actually the LIRs who have only one assignment. What this shows us is that this actually continues even inside the dip. So the conclusion there is there are people who are asking for an assignment and this has been continuously going on, so this is not a problem. The dip is actually caused by the LIRs who had more than 20 assignments already.
So, one can theorise why this is happening, but one theory that actually says that these LIRs were actually thinking for a bit. Like, how shall we go on? Shall we continue with our processes and do them? And actually, as you can see, they made the conclusions that, yeah, life goes on, so no problems.
So, after this, we actually looked at why, if we ever see replacements of PA address space into PI, why is that happening? So we actually took the approach and looked at the cases where, at some point in time, I think it's exactly one year ago, the LIR had some amount, some number of PA allocations and PI assignments, but, today, they have less PA and more PI, so this is, if you think about it, this is tricked because life goes on and business goes on, so this is just some significant part of the cases, but when we looked at why this is happening, I am not going to read all of the examples that we have found there. There are good reasons why this is actually a natural phenomenon.
We also heard from IPRAs that there are LIRs who just say, "please do it for me, please, please, please." Then they enter into a conversation and something happens. The moral here is that we don't really see a trend based on this data, so far. The trend that would actually say that LIRs, on a massive scale, started to switch over from using PA into PI. Now, what this data does not tell you is if the LIRs started to use PI exclusively instead of PA space, but that's a bit more difficult to actually analyse.
So the conclusion is that this is not really a problem as of now.
That was talk number one.
Talk number two, which is much more text and much less graphics. Sorry for that.
Let's start here: So our registration services department contacted the science group and said, we see something happening and we would like you to look into the details and give us, you know, some data or guidance like how should we do this, and, maybe if it's useful, we'll do something; if it's not, we'll just decide.
What they actually noticed is that, every now and then, LIRs come back and they say, "So I have this prefix and I am growing and I am growing, I need a bigger one, but, you know, cannot, for aggregation purposes, cannot grow this prefix because everything else is used just next to me, so please give me another one instead." Now, that's all fine. That's just a fact of life, but many times the IPRA is using the [REX], the resources, to explain it. Why not, let's see how they used it and it turns out that the prefix is actually really dirty, and by "dirty" I mean that it is partly or completely contained in some kind of black list or spam list or bad list, okay.
There are a number of those out in the wide, so they actually asked the questions. So how often does this happen? Is this something that we should be structurally aware of? Is it significant in terms of address space? If it's more than whatever number you are going to tell us, we will look into more details. If it's insignificant, then, okay, well it's just a fact of life.
Is it true that it's statistically over the entire LIR space, or are there LIRs that are more prone to this? And the next question ?? the last question which I cannot answer because that needs some of their knowledge as well, is like so how often does it happen? That they actually come back and say give us a bigger one and hopefully it should be clear, right?
We have all the data, so we actually looked into this. Methodology was easy. We looked at the last year's allocations and assignments. We collected some basic data and we checked in RIS. I know it's not perfect, Randy, but we still did and we also looked into various black lists, notably the ones that already exist behind [WREX]. What we did was check the dirtiness of it, but, for sanity, we actually did it before the allocation, we sorted out the ones that have already been dirty before the allocation or the assignment because that's ?? well, that's just something that the LIR cannot really do anything with. They can work on it, but it's not their fault.
So let's look at these cases and let's try to play with the threshold. So if we raise the bar or lower the bar, how will it change?
Some caveats: I have to mention this because I think this is important. Spam lists and black lists, they have their own semantics, so I am not going to say they are wrong or right, but they have their own semantics. Sometimes it's easy to get on a list. Sometimes it's difficult to get off. Sometimes it means something, sometimes it's just informative. So one has to be aware of that in this context. Another thing is that any LIR can have some clients who are listed in spam lists. It's just a fact of life. There is a BotNet which has a client in your address space, sorry. Even if you have massive amounts or large amounts of blacklisted clients, that doesn't necessarily mean that you, as an ISP, are doing something wrong. That could also mean that your client population is more prone to BotNets or, you know, they're patchy servers, or their clients less often, so, therefore, they are attacked.
But if we see significant differences, that can actually help us looking at like, oh, yeah, something is happening here.
So, results:
You can see that the names have been changed to protect the innocent ?? no, to protect the LIR names. This is one of the results where you can see that I said this is the relaxed approach, which means some dirtiness is okay. I drew the threshold at some point and I said, you know, if dirtiness is below this level, then we say, yeah, okay, that just happens, we cannot really do anything with it, then grouped the address space and number of prefixes into LIRs. I actually kept the country code so you can get an impression.
So what we see here is that the total here is roughly 130 blocks from 100 LIRs. It's half of /8, less than half of /8, and it's not that bad. You can also see that, in some cases, the address space consumes ?? address space consumption is much higher than in other cases. Especially like here, this is partly because if a PA allocation gets dirty, then it's, by definition, a bigger chunk. But if you look at the big picture, this is not that bad. If we say, okay, we can just forgive for some dirtiness, then this is what we see. If we don't forgive for any kind of dirtiness, this is what we see.
Again, this means that if an address block was not dirty at all before we gave it out but it became a tiny, tiny bit dirty after we gave it out, within half a year off the allocation assignment. Then it's on this list. This is really, really too strict. But it already shows that, well, if not LIRs, but individual countries, then to be a bit more prone to this effect than some others.
Depending on your level of paranoia, you can draw your own conclusions; I am not going to say that this is wrong or it's not. This is what we see, this is the data. In any case, Registration Services is aware of ?? that this is happening, and if they see an LIR on this list, they actually look into a bit more details before just blindly giving out the next prefix, which they never did.
So, but the question here, I guess, the moral of the story is: Is this something that the NCC should look at? What do you think? Because as soon as IPv4 runs out, we are going to have more blocks coming in, returned to the LIR, and more blocks going out, so, at some point, we will reach the stage where we will receive a dirty prefix back. So what do we do with it? Do we just hand it off and say "it's your problem now"? Or shall we start a procedure that actually cleans it up? I think that we are looking for guidance here. One note here is that making prefixes cleaner after we reclaim them is not an easy task. So this is significant amounts of work, I believe, but, in any case, we are looking at ?? for your opinion and please tell us if we should do this or not.
Okay. And finally, historical BGPlay. This is actually the thesis work of a student we hosted at the RIPE NCC. He finished his work last week so if there are bugs, he ?? I guess that he still needs to figure them out.
Anyway, historical BGPlay. You are aware it has been said a couple of times that the RIPE NCC is sitting on a huge pile of RIS data. One can argue how useful that is, but it's true we are sitting on that data. We also have an efficient query mechanism that we call INRDB, it has been mentioned a couple of times on the RIPE Labs. This actually allows us to dig into this data and get, for example, years of table dumps information out of RIS in a couple of seconds. We also know that there are nice visualisation tools for BGP data. In this case, this university still has the software called BGPlay, which is using RIS as a background and can visualise the last couple of months of updates to you. So we actually gave the task to Claudio, combined all this and produced something to us and that something is a new tool. You can also try it out, it's already up on Labs. If you go there, if you are interested, you can try it out. It's very, very similar to BGP, but the major difference is that it has a long?term overview. So you can actually look at years of routing information. Now, because of that, it's just natural that you will not see all of the details. You don't want to see all of the details, this is not for looking at the details, but you will get the big picture. So, for example, how did the routing of my prefix change over a long period when this event happened, when that event happened and even didn't actually finish within an hour or two?
You can actually go ahead and try it out, and I am going to try to show it to you, how it works in real life. So what you see here, just as a starting point, is [WREX]. If you haven't tried it out, please do. I entered the previous RIPE meeting prefix into it and I said that the time range that I am interested in is roughly 2001 until mid?2004. That specific prefix had a really nice history, that's why I am using that as an example. What you can see here is because the RIPE meeting has moved from country to country and at that time the way we routed this prefix was that we just asked the local halls, "please announce this prefix". So what you see here is that this prefix actually has a nice history, it moved every time and I think in the gap we had a different meeting, we had we had a meeting in Amsterdam so we used a different prefix, the moral here is that you can see that the prefix was changing providers quite often. And then we can check how does this this look like in the historical BGPlay. I entered the same prefix, roughly the same time frame. I draw your attention to this one. The whole point ?? the most difficult part for Claudio was how can I get rid of transient events. Things that it happened for a day but it's not that important. The way he solved it is that you can have a filter that you can say, filter out everything that was shorter than two weeks or something, so that's actually highly appropriate in our case. Notice the speed. This was three years of routing history. Okay. What you can see here is the state as it was on the 1st February, 2001. The prefix is not routed at all. There are just no ?? if you are familiar with the BGP interface you know what this means F I start playing the movie, which means that we will move up here over time and we will see what the routing changes were regarding RIS prefix ?? let me just start this. So what we see there is 137, who is GARR, Italian academic research network, was receiving all the routes for a while and then all the routes were actually removed in what was that, June, July. I will stop here for a minute. Everything is gone by July. Next guy, who are they? Cesnet, I believe that the RIPE meeting was actually here in Prague at that time, September 2001. So they started to receive, they were the ones that actually announced this prefix, so every route actually ends up there, and, after a while, the meeting is over. So, in October, the prefix was withdrawn, so they no longer see anything. And that's how it goes on, I can play the whole movie for you, you can play around if you want. You can highlight ASs and so on. It's all in the user interface, but what it tells you is that it is really, really simple to visualise long term history of routing. What it shows you compared to WREX is that WREX gives you the announcing AS number and it can give you the first transit as well but it doesn't show you the full path. This one does, so if you feel that this is useful for you if you want to look at some historical event, just feel free, go to labs and you can check it out. I believe it just requires Java, otherwise it's available for you to try it out.
Just to have some questions. If you have any.
CHAIR: Any questions? No questions? All right. Thank you very much.
(Applause)
CHAIR: Thanks to my excellent time?keeping skills, and some help from the presenters, and Axel, we are ten minutes to the end, where we have a traditional open microphone where if anyone has any input or comments on services provided by the NCC or suggestions or comments or any questions from the previous presentations?
Well, okay...
That was it then. I am sorry, but you have to wait all the way to the fall again to see us. So, registration for the AGM, if I didn't say it, is outside and you will all have to leave the room now. The AGM is back in here. You will need the AGM name tags to get back in and I think the aim is to start the AGM at 18.00 sharp, so you might want to be back here a bit before that.
LIVE CAPTIONING BY MARY McKEON RPR
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE