These are unedited transcripts and may contain errors.

RIPE NCC Services Working Group ?? 26 September 2012 ?? 4 p.m.

CHAIR: All right, you can all calm down. There will be a RIPE NCC Services Working Group this time again. It's your, as you all know it's your favourite Working Group. We like to share the love. Christian can't see from here, do you want me to do it again. It's worth sharing the love.

Reminder for those of you who are, who haven't been here before. After the RIPE NCC Services meeting finishes we'll have 15 minutes and we are all going to go to the RIPE General Meeting and if you haven't registered, pick up your registration packs, now is the time to do so. That was in the break before, but you'll have a slight chance to do so.

I'm Kurtis Lindqvist. I am the Chair, together with Bijal. And the agenda for this time is that we first have the ?? you are seeing things I'm not seeing, interesting ?? about the scribe, someone from the RIPE NCC, and also someone from the Jabber, which is...

And we have minutes that was posted from the last meeting to the mailing list. I forgot to check what date they were posted but I know what date they were pested. Any other additions comments to the minutes? No. All right, that's done then.

This is being webcasted so if you do go to the microphone, in the unlikely event you will have a comment or a question on any of the slides, then please state your name an affiliation at the microphone as well.

We'll start with an arbiter's update from David Kessens, then we have the RIPE NCC report by Axel, then Alex and then we are going to go and do the IPv4 final distribution update from Andrei an and then for the first time we have a policy proposal in the Working Group and we saved quite a lot of time for discussions there, which is going to be Niall presenting that. And last we have a topic from Nick Hilliard about sponsoring LIR data. Then last, any other business. Any other additions to the agenda?

With that, I'll hand over to David.

DAVID KESSENS: I am David Kessens. The first thing to note is in the context I am an arbiter, I am not a Chairperson of the arbiter panel or something like that. I am just a random arbiter who was selected by the arbiter panel to do this presentation.

Since this panel is fairly new, we have had an update earlier on, more details on what the arbitration panel does recollect, etc. So, I will repeat a few of those items. I have very little time, because we have a full agenda so I'll only repeat a few things. So if you want to know more about the arbiter panel, there is another presentation, a year old that has many more details about this.

And that was in, also in the NCC Services Working Group May 2011, for your information.

We have now 14 arbiters in the panel. It's a nice number. We started out with just a few and especially when we are getting closer to IPv4 depletion, lots of people were worried that there would be more cases, so it was time to expand that. So at 14 we at least have a couple of people available if things happen.

We had only two arbitration cases in the ?? more or less the past year, or one?and?a?half years, it depends on how you count. And very importantly, we had an arbitration panel meeting this time that actually we have a few questions and things we would like to share with you.

Here is a nice picture of most of the people in the arbitration panel. Of course one of the missing people is me myself, but, who cares?

Important thing: It's an all?volunteer panel. So, there can be quite a bit of work involved, if somebody comes up with a case and there is a lot of research that needs to be done, it's quite a bit of work and some of it is also like pretty thankless work because nobody sees it and so, I am very glad that we managed to find 14 people who are actually willing to do this.

An important thing to also realise that this panel that deals with arbitration cases is impartial. We have no involvement in the RIPE NCC in the actual decision?making process. The RIPE NCC does support us a lot, its organising and helping us with getting a meeting organised and things like that, and helping us with facilities, website and all this kind of stuff. But when an actual arbitration case happens, they are not involved at all.

The important thing of course is when we have an arbitration case, we follow all the important policies and we try to look at that and make sure that either the RIPE NCC has followed all those policies or that any of that applies to a conflict between two LIRs, for example.

Here is a little slide about what kind of disputes we are involved with. So there is many kinds of disputes that can happen in this area that can be between two LIRs, it can be between the RIPE NCC and an LIR. All kind of variants are there.

So, the last meeting. We looked at all the procedures and guidelines and stuff like that. We have some internal procedures to look at arbitration requests. We found some issues with that, so it was important for us to have a meeting and discuss that and there will be more slides about this.

We discussed some prior cases and, again, it's important for us to review our own standards to make sure that everybody is in sync, to understand all the little issues and details of those policies and also very importantly we looked at new policies to be prepared if any problems occur later on with, especially in the area of IPv4 runout.

One of the review of the procedures is actually something that is not strictly specifically arbitration but something we get involved with, and that is we also look at cases where the RIPE NCC actually allocates IP address space or other number resources to itself and that is strictly not arbitration because obviously there is not really a conflict. But, to preserve the impartiality of these kinds of requests there has been a policy set up to make sure that the RIPE NCC is actually not involved and we get the final say, whether a request gets approved. That policy is very short and brief and that's very nice because it gives lots of flexibility. But it also means how you operationally execute that, it gives a lot of freedom to us and the community to actually deal with that. And I just quoted this little piece here that pretty much says it all, and it's important here because we had a case where a rejection happened of a request of the RIPE NCC, and people went to the Plenary and then we found some issues with that.

The big issue that we found was that that we were probably too much in a hurry to execute the process and we didn't do the proper due diligence that we should be doing as a community. This was ?? it happened just too much in a compressed time frame so we have been talking about it and making agreements that we have made with the RIPE NCC, that when requests like that or a situation happens again that we have to go to the Plenary. We will have more or less an advance warning as a community to there will be appropriate warnings sent out to a mailing list, etc., that are relevant to whatever happens, and that will give an opportunity to the community to react to discuss an issue already on the mailing list, so when a decision gets made on a Plenary, it doesn't come out of the blue sky, but people already know what it is all about and we can evaluate it with all the details. It's also important because there is a little time in between, you know, if something got missed, somebody can react and interfere and make sure that all the proper documentation and information ISP on the table and a decision needs to be made.

Furthermore, another issue that we run into a little bit is that with IPv4 runout, we are expecting that perhaps a few more cases might reach our panel. Of course we don't like that, or we hope it won't happen. But if it happens, we can see that there is a few other cases where we like to get a little bit more discussion in the community about, because there are, like, things that are currently of exclude or not entirely clear what our authority is there and those cases are basically for example, legacy address space holders are involved, inter RIR transfers and stuff like that, or for example, non?RIPE NCC members. And for some people to answer on that it might be very easy like, no, we don't do arbitration on that, but for other reasons it can be important to actually look at cases like that because we also have an important governance role, we have so show to the overall world that we are good stuarts of the IP address space and we take things seriously, so if there are parties that actually would like to us arbitrate on something, it might be important that some of those other maybe non?members are not involved. So that's a discussion topic that we have to start thinking about.

And that's basically all. Questions? Comments? Remarks?

CHAIR: Anyone?

AUDIENCE SPEAKER: Sam Weiler, Sparta. I am delighted to see that you took up the issue of the allocation incident from a year ago. However, given how poorly the process was conducted a year ago, I am wondering why we're not actually doing it right?

DAVID KESSENS: I think I'm the wrong ?? you are asking the wrong person. I mean in this sense, I'm a bureaucrat. I am the person that people ask for an arbitration request and we get involved and we do our job. Our job is already finished in that particular case. We said no at the time. So, that is completed, and it's probably more a question that the community wants to do there. Perhaps somebody from the RIPE NCC and senior management would have something to say about that, then that I can't really comment on that. I think I'm not the right person.

AUDIENCE SPEAKER: Those folks are in the room. I invite to you stand up.

AXEL PAWLIK: The question is: What does the community want? I think at the time, and it's a year ago already, I informed the community that we retract that had one particular request because it was clear that it was the way it went was not appreciated, so, yeah...


CHAIR: Any other questions? Comments? Then we're done. Thank you, David. Next up then is Axel.

AXEL PAWLIK: People, we have done it. After years and years of communicating and, typing until our fingers bled and talking until we couldn't do that any more, after many, many months of in?depth preparation, after many weeks of meticulous adherence to published procedures, your favourite RIR rather out of regular IPv4 address space. For a moment I thought you were doing e?mail.

Now, I take this as a vote of thanks to the staff of the RIPE NCC who worked their behinds off and those who supported those on the front lines in whatever they were doing in the NCC, thank you very much, folks, that was quite impressive.

As far as I am aware, the world has not come to an end. It has changed a little bit and many people will wake up in the coming weeks.

All right. Having said that, onto the regular programme.

We have members and we have more members. We expect even more next year, so this all goes still up and to the right. That's all good.

Apart from that, I have about 60 slides for you, I also have about 30 minutes if Kurtis let's me, I did a novel thing here, I uploaded the long version to the dock store and will recite from a shorter one. But basically there is lots and lots of stuff that we've been doing.

Going through that, the interesting stuff first of course, legal, always. We occasionally look through our documents and the legislation and all that and what we found out recently is that oops, through processes in the past, and mergers and acquisitions and stuff like that, some of our member organisations acquired more than one LIR. They acquired also voting rights with that. That is not quite right after, according to Dutch law. So we have contacted those guys. It's not that many, I think it's about 80 or so. And they have reacted gently and said oh, yeah, good. So that's interesting to note.

The Dutch police, you might remember that. We were asked to free some address blocks that we did, then we undid that because we thought the police or the grounds for the police were not quite sufficient. We talked to the legal system in the Netherlands and said we don't accept that. We want to find out what the proper procedures here would be. We have a hearing scheduled for end of November. Of course we'll go there and see what happens. We expect, or we don't expect any outcome from that before somewhere next year probably.

Then of course two of the affected blocks of rereleased after the members didn't pay their dues any more and, well, we have published procedures and policy, so we followed those and they were reallocated, a little bit earlier than usual because we were running out of this address space and we had to get this back into circulation.

Then we get those regular requests for information typically from some friendly neighbourhood policemen in Germany or somewhere else who said can you please tell us who used this particular address at this particular point in time? We said we can't do that but you have a nice database, and you can look at it and this is how do you this. That happens regularly. And we have been quite nice ties to some of the police forces in our service region and we help them with those things and we are thinking we might actually do a bit of a course there, a half day or so training course. So it's do it yourself next time. Saves time for us.

And we get a new quality of request recently, was sent to our German and also to Barack Obama and lots of other people from this group called United Against Nuclear Iran. Fairly heavy weight if you call that lobbying. We have acknowledged receipts of the facts. We have had this little statements on our website basically saying we act under Dutch law and all the like. We are looking at our procedures again, due diligence and the like. But also we very recently actually this week here, heard about ICANN and them having some sort of a licence or some special exemption from certain sanctioned list that the UN, for instance, has put up. So this is where we are going. I am sending all our lawyers after that: I want that too. It's I think important that we do this. We are neutral, impartial, we should remain that and why we need to be seen to be acting under Dutch law as we do, if that is an opportunity to serve all of our, continue to serve all our members in our service region, that's something that we should do. So doing that.

Talk to us, we said that, regularly. And do you, through lots and lots of feedback channels, which is all working quite well, we think.

We did this membership and stakeholder survey. We get lots of interesting and very valuable feedback from that. We got 825 respondents last year, that is more than we got before, that is very good. It's not enough of course, so the next time around, please all do take part.

Basically, it gets us into a mind frame where we understand what you want and what priority you want those things. So we do this.

The last survey gave us about, oh gazillions of things that we could improve, but we focused on the top only 50 and we have this great big spreadsheet internally where we see where we are working and what we are doing on those things and we'll publish that in the near future. But basically we are very much appreciating your feedback on those things.

We are looking at doing another survey next year and we have decided to do this somewhat in close coordination with APNIC, they are doing very similar surveys in a similar methodology and basically that enables us to do it in alternating years and maybe to some degree where it's appropriate, to compare ourselves a little bit. With APNIC.

So, yeah the whole thing of course, this whole structure, this whole community, this whole industry changes rapidly and of course this is your way again to indicate to us what's important to you.

So, the next survey will check out in May next year.

Serving our members by many different ways. You see the ticket load goes up in customer services, in registration services and I won't go into any much detail, but basically I'm happy to say the ticket load goes up but the level of stuff in this is fairly even.

We do ?? oh, that's a revolution, we do live chat with some of you and that's something that is a major break away from our old document. Oh, we do e?mail only. No, we do this now. Very carefully because it has impact on some people. Not everybody is able to do this efficiently and in the same mind frame. But we are doing that, we have doubled after a good time, we have doubled this time frame for that per day in customer services so far. We did a mini?survey of that as well and people love it, so we'll carry that over probably also into registration services next year.

Again, starting very carefully.

Main focus this year so far was stable approach to /8, I think that was quite a success, I am happy to say. Also, similar to the chatting customer services we say, oh, God, it's maybe a little bit more efficient if we do take the telephone call back with our members after the first couple of e?mail exchanges, where we don't seem to get anywhere, call them and make it easier.

So that is something that we are focusing on as well.

Live chat coming there as well and of course more v6 support to our members.

Audit. An accurate up?to?date registry is very important and will continue to be important, maybe even get more important in the future. So this is what we want to basically facilitate with the auditing. I have the idea that over the next couple of years it would be great if you would audit, for instance, every member every three years, so, that, seeing we are about 9,000 members, 3,000 audits per year, that's a lot more than what we have currently been doing. So we need to make sure that we do this efficiently and also check our members in to do their bit and make it easy for them to be part of that.

Training services. We do all those training courses. We want you to be part of that, to learn from that. We do presentations, lots of presentations at conferences also, increasingly invited by other parties. Online learning and the like. It's a good thing. It's being used and it's a bit more efficient than sending people out to all those places. But of course it's missing the direct and intensive face?to?face but it's something that we need to do.

More training, road shows, that's something that's branching off from the regular training courses a bit, but it's also very, very valuable. I'll talk about that a bit later again.

CPE survey. I think most of you saw what Mark said a little bit earlier this afternoon; if not go and have a look at the presentation, it's online and of course the website is there as well.

Lots and lots of time is spent at the NCC in making things better for you, sometimes for us, in order to make it again more efficient for you. Making your life easier. Making our members' lives easier is very high up on our agenda priority list. There is lots of things. Address management. Tools and things for you to check your address holdings and the like. Working on your knowledge and our knowledge as well internally. Training, education, all those things.

Restful API for the database seems to be very popular. The IP analyser and I won't talk much about it because Alex is going to do this in a little while. The RPKI validation tools basically is something that we said we wanted to implement very carefully according to your wishes and your concerns. Takeup of certification is, again, still quite good. More than 1,100 members have their resources certified and more than 800 ROAs are out there.

So, well, that's basically what we said. We are very much aware that the operators take their autonomy very, very seriously, we need to work towards that. A security of the system is important as well and of course making it bigger and better.

Lots of the work over the last couple of months went into the back end system. That is true for some of the things I am saying, we might not see everything of that externally but we are beavering away internally.

Of course all the time talking to our industry partners, standard bodies, ITF.

PI space and certificates. We think certification is really a service that we should offer to members only. So, having said that, moving on.

Database. Yes, do I remember coming to the RIPE NCC a little while ago, 12, 13 years, and the big project at the time was reimplementation of the database. It's been a while, so we are doing it again, because we want to make it much better, and basically the focus here is to work on maintainability and extendibility so that we can very easily and efficiently implement new features that you occasionally require from us. So that's the idea there.

In the future, of course, once the code is done, we publish it as usual. Clients like tools for you again to make you're life easier. The next step that we are currently busy thinking about is reorganising the database organisation a bit in terms of strong registry and what is needed, what can be done to make that easy on both you and ourselves.

More membership services. Now we are currently offering realtime mirroring of the database contents as well as database proxy for people who are interested. Now that's not very many. And we are thinking, those, the maintenance of those contracts is sort of a thing that is a little bit different to what we are usually doing at the NCC and what we want to do. So we talked to our Board and they generally support changing these contracts into membership services. So, a number of people using is relatively low. Most of them are members anyway. So, I don't think that's a big impact to you. But it makes it all easier for us internally.

Lots of measurements. As, you know, developing Atlas quite rapidly over the last, what is it, two years by now, and stuff is beginning to come out and you have seen that yesterday and I think the day before, already in the BoFs and in other presentations. I find it a very nice important way of reinvigorating our measurements and of course know that many probes are out there already. We are looking at ways of making it even more efficient and gaining some for functionality in the process. So the next big plan, RIPE Atlas basically is that boxes that concentrate there, we have a pilot starting about now and the goal is, it's a high number. 50 for the end of next year, to get that out, deployed and maybe there is a way to load other services on to those boxes as well

RIPE Stat. More value for the community again, looking again at any odd resources on the net in a very nice visible, understandable format. It's a great thing. That's a perfect size distribution matrix, if you can read that.

Again, RIPE Stat should be linked, will be linked, is linked from the LIR portal, again for the members with some extra functionality there. Again, we are improving the system all the time. And of course as it is quite a lot of stuff that is out there, that is sort of a, you are not supposed to read ?? you are supposed to have read all of that already on RIPE Labs. It's really becoming a very, very useful resource for all of us and we are seeing good feedback on that and of course we want you to contribute to that to get writing.

RIS is running at usual and it will be integrated into RIPE stats in terms of presentation. TTM is getting really really old and we would like to stop it now but we'll carry it on a little bit further. Basically we want to talk to the current users and are talking to them basically constantly in a way to integrate the need into RIPE Atlas, Atlas anchors possibly, and to get on with that. At some point we'll have to stop it and we have pushed it out and we are saying second quarter next year, things will be switched off. And we'll have a party, I think, as well for that.

DNSMON works very nice, we'll convert that into membership service as well next year. The current users, where they are not members already, Luisa Villa to become members, they are currently already paying a bit of a fee so that won't be that much of an impact and again makes administration for us easier and it makes it all very simple. The focus still is on TLDs but of course that becoming membership service, it will also open a bit more as we can make that possible and sustain it.

DNS. We messed up a bit. We wrote about this, explained what happened, I believe, fairly decently, and the good thing that came out is negotiations with more various service providers, we'll offer 24 by 7 telephone service in the near future, I think starting in November. So, yes, we, we learned that sometimes it's difficult to get to us for those ongoing operational needs, we'll do that. Then, of course, the full report with even more write ups about what we learned about it is about to come out.

There is this thought of even smaller K roots. You know we are running one of the K?root clusters, we have global nodes, we have regional nodes and we are thinking we could make them even smaller just for member internal use. We'll think about that and probably offer that quite soon.

Otherwise, cooperation and outreach. For a very long time we are cooperating very, very closely with the other RIRs, you know about the NRO, that's going on and you'll hear about it again on the Friday morning. And you'll see also on the Friday morning that many of the things that the RIRs are doing now of course, besides number, location, are similar. We have agreed with APNIC on the next step and formalising some of the informal things that are going on for a long term already. Basically we have a bit of an MoU that we are currently in the process of signing, it's been agreed already. It's open to the other RIRs as well, we thought we'd do it bilaterally first and then gain experience with that and efficiencies and if anybody else wants to join on this or that project or something else, we can do that. This is the list of the current projects that we are ?? if you want to start off with APNIC, basically was it a half a year ago, when we gave the presentations about RIPE Stat and also about the Atlas and Gooey for certification of our colleagues from the APNIC said this is great stuff we want that too. Of course yes, we can share all this. And I thought this is maybe the time to ask for a little bit of a contribution too. Depending on who is doing work. We have, like I said, this MoU agreed and now we have the project plans are getting into place and they are being written up and I have commitment from APNIC also to contribute especially around the rebranding thing Atlas and stat to contribute manpower to that.

So yeah, lots of stuff that we need to do anyway and Working Group gain some efficiency ifs we do this together. Some of the work will probably be going on in APNIC more than here, others more here than APNIC. And again the other RIRs are are welcome to join.

Other external relation activities. There is lots of things going on, you heard about this earlier, I think yesterday, the week is already blur ago little bit, in my head about the threat from the aptly named WCIT and other world size global conferences. We do ?? we are talking to lots of other industry partners continually, I'm sort of just back from iSTAR meeting with the other Internet groups like ICANN and ISOC and W3C and there is no "I" in there, I know that. We met the new CEO, or the about?to?be?new CEO and president, about all those perceived threats and our joint strategy on those things. We need to, and we have succeeded to some degree already to grow the influence and the name recognition of the RIPE NCC, the NRO, the other RIRs in general, and we are quite proud that we are being called upon frequently and now regularly by the governments, by some governments to come and help them or advise them.

Capacity building. The IPv6 road show I mentioned that a bit earlier, is something that our training activities branched off into together with MENOG. We have done a couple of them. They are very, very useful, obviously operationally locally but also in the capacity building politics environment. So that's something that has boosted the reputation of the RIPE NCC quite considerably, and of course now we want to also expand that as well as we can.

Internet governance: Yes, as, you know, Paul I sent him off to live in the Dubai in the terrible heat there, occasionally the air con breaks down, I don't want to imagine how that is, but he is doing also work especially when the air con works again and he has been instrumental in the first setup of the first Arab IGF there. That will happen in a couple of weeks in Kuwait. I'll be going there as well. It's important that we are seen to be helping the locals where we can. And we get lots of praise from them as well.

Then, of course, words to the end of, not even the end of the year, a couple of weeks later, the big IGF in Baku, we'll be going there and parts of our Board will be going there as well, again working for you in suits and ties even if you can't imagine that we do that occasionally. So that's important.

Other things: WCIT, WTSA, all those terrible things, weeks and weeks of conferences, sitting there, we do what we can, we can do quite a bit.

Cooperation with law enforcement. I mentioned that earlier, we have for years an annual meeting with them typically in London but also we are planning one for the Middle East as well. Again, what are we? How can we be of use? How can you rely on us? And how can we manage each other's expectations? Important.

OECD is by now a very important forum for us to work in and contribute as well as APECTEL. That's basically the Asia Pacific Economic Corporation, the telecommunications part. There was a Minister meeting in St. Petersburg, hey, that's our service region to. Apart of being APEC, Dmitry went there and Chris and I together with our friends were APNIC and tried to impress the locals there and I think that also worked.

Right, that's quite a lot and I am about to run out of time. There is lots of other stuff that I don't talk about in any great detail here, but you can imagine to be able to do all this for you, there is lots of back office stuff going on as well. Back office, HR stuff, renegotiating health insurances and stuff like that, all needs to be done as well, you don't see any of that, apart from us being here healthy and shiny?eyed and all of that.

Housing adventures. Yes, we have those lovely offices on a single canal in Amsterdam. Very old house, very nice. We are shuffling some offices around and now we own the next door building and we want to have efficient housing there and hack gates into the walls to join offices, but it's a listed building, it's protected, so because it's nice and old and it's difficult to get through all that. It's a bit of an adventure but it's also fun.

That's my slides. There is more online if you want to have a look. And of course we are all here and available and ready for your questions. Chairman?

CHAIR: There is a queue for you.

AUDIENCE SPEAKER: Andy David. What is the expected cost and expected benefit of auditing all of the members over the next three years?

AXEL PAWLIK: Well, it's something that ?? the benefit basically is keeping the registry up to date and reliable. That's the obvious goal of that. The cost I think we'll talk a bit later about in the afternoon in the general meeting but I don't think any extra cost. Basically what we sort of expected, we talked about this earlier, is that the allocation of IPv4 address space is going down a little bit, and that is also where the potential problem sits in that we don't see our members that often that we don't interact with them regularly and frequently, so this is trying to stem that a bit. So I don't think that there will be extra cost but the overall decline of activity around v4 will be not as steep as you might expect.

AUDIENCE SPEAKER: From my point of view, it's ?? I have been on the LIR side of an audit before in perfectly normal circumstances but it's enormously time?consuming which equals expensive and it must also be time?consuming and expensive for the NCC which is also the members money as well and the end result of we have still run out of IPv4. So, I'd be very hesitant to suggest this was the best possible use of time and I'd recommend maybe thinking about that idea again.

AXEL PAWLIK: I tried to say a bit earlier that the focus of the audits will go away, of course, from preserving address space, because it's too late, to assure that we know where it is being used and yes, those audits are fairly, or were fairly heavy and we want to get away from that and look at way to say do something that is similar in quality but less intrusive work on both your sides and ours.

AUDIENCE SPEAKER: Maybe that's an idea for a future discussion before this gets put into plan then.


AUDIENCE SPEAKER: Shane Kerr, I work at ISC. We are not an LIR. I have never worked for an LIR. I have never been a RIPE NCC member. Or worked for a company that was a RIPE NCC member. And I have noticed a lot of new activities at the RIPE NCC is doing are being tagged as "member only" services. And I have noticed a lot of these which don't, in my mind, have any logical need to be "member only" services. And I think probably a lot of people in the room don't notice because they are members, but as someone who is not a member I can't access these. Recently there was a mail saying why didn't anyone try our new servers and I said, well, I wasn't invited. So, I guess I have a statement about this and a question. My statement is that I don't like it. I think it's the wrong direction. I think in most cases where it doesn't cost any more money to make it public, I think the RIPE NCC should try to make their services public. I realise there is a lot of services that do make sense for members only. And of course those should be member only. And there may be cases where there is privacy or other contractual constraints. Now keep in mind that I'm not paying for any of this, so you can just please ignore my advice. But I think given the mission of being a registry that's for the good of the Internet especially in this region, I think it's the right thing to do to make these services available to everyone.

AXEL PAWLIK: Thank you, Shane. We are aware of that and what we are trying to do is strike a balance of making, for instance, of some services making them available generally but some features where it might be appropriate so for members only. The balance is the interesting question. I hear loud and clear what you're saying and this again is a process that we need to engage in and we need to hear what you and what our members, the paying members want.

SHANE KERR: I think ?? I mean watching your presentation just now, I discovered a whole new services that I didn't know were going to be member only, and generally the way they are ?? the way I feel when I see these, is that the decision has been made. It's not a discussion that's being had with either the communities or the members really. It's just sort of RIPE NCC management has made a decision that this should probably be a member?only service. So, maybe what would be nice is check first. I don't know.

AXEL PAWLIK: This is part of it ?? now the decision has been made that we want to have a number of services or a number of service variations member only, it's the general strategic direction and I think we talked about that earlier and presented that. The extent of, to which we do this for any particular service, again, we do what you tell us. And well what the members tell us most of all, because they pay for it, but I understand that you don't like that and two hearts in my... you know...

RANDY BUSH: You didn't ask.

SHANE KERR: Randy just said that you didn't ask. And that's kind of my second statement there was that.

AUDIENCE SPEAKER: Gert. There was something in your slide that you jumped over very quickly hoping that nobody would notice and scream at you.

AXEL PAWLIK: Which one was it?

GERT DORING: Well, I was primed I have to admit. The thing about the RPKI and the ?? we want you all to become members. Well, there can be different views on that. I acknowledge that. I am very much not of the opinion that it's useful to try to bring in 40,000 or 50,000 new members because your accountants are going to kill you for all the paperwork.

AXEL PAWLIK: Our members will love us for the prices dropping in general.

GERT DÖRING: No, no, your members are not going to love you because there will be 50,000 new members that are used to paying €50 a year and now have to pay 500 because that's about what it would end at, so, looking at what you did with the you're IX holders, you should really consider very well if what you are aiming to do is useful for the community and useful for the NCC as a whole and with the EURO?IX users, you messed it up horribly. So now you have a lot of alienated address holders out there. Don't repeat that mistake with the PI holders. So really think about that. Bring it before the Working Groups and get the members to voice their opinion on that, not run off.

AXEL PAWLIK: Well, it says, it's our position. And we listen, yes.

AUDIENCE SPEAKER: But you tried that before and it didn't really work.

AXEL PAWLIK: We are still working on that.

RANDY BUSH: I actually, unlike Shane, have worked for an LIR. But, let me carry it a little further, what Gert was ?? the path he is following, especially PI space. The PI holders are in control of their WHOIS data by NCC process. There is a maintainer for that. So, if you question whether RIPE has a sufficient relationship to issue a certificate, what you are ?? when you issue an RPKI certificate you are not attesting to somebody's identity. You are merely saying that somebody who has a private key that matches the public key is in control of that address space. In the WHOIS data, there is a maintainer object. And that is really very close to a public key. And the private key is the BGP key or whatever the password that is used to authenticate against that maintainer. So, you have, and are currently exercising, the relationship to the PI holder today. So there is nothing structurally in the RPKI CPCS and all that crap, it that says you don't have a sufficient relationship to issue a certificate. So, the tens of thousands of PI holders see that red box as coercing and extorting money from them.

AXEL PAWLIK: I hear you.


AUDIENCE SPEAKER: Specifically on this topic, I do think that there is sufficient paper trail that the RIPE NCC has through the sponsoring LIR or directly to actually provide services like RPKI without actually forcing them into a membership, and I think that will ab very, very bad idea.

AUDIENCE SPEAKER: Wilifred Woeber, wearing two hats, one as an LIR manager and the other one as University being a legacy space holder. And I think, I wouldn't be as blunt as some other comments have been a couple of minutes ago, but this orange?lined box, sort of smells similar to the... well, to the action during the Vienna RIPE Meeting where some stuff that just came out of the blue, there was no prior discussion. There was not enough supporting documentation. To me this reads like a very, very high?level management summary, which is not sufficient to be used as a basis for discussing the real issue, because what I'm seeing here is that we are probably on the road to have another mismatch of procedures being developed like having ERX holders capable of signing up with a sponsoring LIR like the EPI holders can, like others can. If any one of those sees that box, they will either conclude that we are stupid or you are stupid. And I don't like either of those things. So, I would really urge you, like some others have, before you set this thing in stone, before you get public with that, without the supporting documentation, please please go ahead, go to the Working Groups, go to the mailing list, have the discussion, collect the feedback and then brief your team leaders, management, whatever you call it, and then go ahead with statements like that, because we really want to shuttle up the stuff again because everybody throws the sand at it.

AXEL PAWLIK: I agree with that. And that's why we are here, that's why we are talking about this. This is our thinking, and we don't even have a policy for PI and certificates.

WILIFRIED WOEBER: Be careful, these slides are going to be up on the public website. This is not a discussion. It's a public statement.

AXEL PAWLIK: Yes, that's our thoughts..

CHAIR: After these two speakers we have to move on.

AUDIENCE SPEAKER: Hans Petter Holen from Visma. Maybe I have been in the commercial world for too long, but if I want a service from somebody, I expect to pay for it. If we disagree on that, then I think we have a fundamental problem. Then the question is: How much and how do we do that relationship in order to pay for that? And there are a lot of other certificates that you can get for a lot of other useful and not so useful stuff out there. So there is actually a market price on getting somebody to sign some digital certificate that gives some legal value in transactions with banks or e?commerce or what not. It's possible to figure out what a fair market price for this service is. And if you don't want that service from the RIPE NCC, well then, you can get Randy or me or somebody else to sign a certificate for you, well, whether that has a practical value for the address holder or not, that's a completely different question. So, I don't think we should be afraid of putting a price on this service. The question is, is it a fair price?

AUDIENCE SPEAKER: Sander Stefan. When I look to the presentation ?? and also I agree with Shane about offering service to non?members ?? I'm getting more and more getting the feeling that the NCC becomes a kind of commercial entity instead of a member?based organisation, and I am very afraid of that. So, yeah... please, the NCC was made to share with the Internet community and keep it in mind.

AXEL PAWLIK: That is what we want to continue certainly. Like I said, it's a balance and we are trying to find our way there with your help.

CHAIR: All right. Thank you Axel. Next up is Alex.

ALEX BAND: Hello, my name is Alex Band. I am the product manager at the RIPE NCC. I am not talking about RPKI for once on this stage.

One of the other projects we're working on, the IP analyser. Simplifying your IP address management hopefully. It's what we work on.

We launched this in March 2012 as a beta service. And it's an LIR portal application. And it shows a couple of things. It shows all of the assignments that you have made with all of the allegations that you hold. It shows you all available free space that you have within your allocations, and most importantly, I guess, is it shows you all invalid assignments that you have created. Because, up to now, you always needed to contact the RIPE NCC and ask your friendly neighbourhood IPRA, could I please have an overview of my invalid assignments because there is no way of actually getting that data yourself in any other way.

And the whole goal is essentially to unlock all of the information available about your resources for your registry within the LIR portal, but also outside of the LIR portal. So what we have within the LIR portal is something that we built from the ground up to replace the well known ASU tool that people have been using for quite sometime. The ASU tool when you run it locally from your command line is only capable of displaying public information and we wanted to build on top of that and also include private information about your LIR.

So what we have done in the implementation, is that we fixed many bugs that existed within ASUs, we added IPv6 support, added support for PI space etc., etc. So ultimately what we are going to offer will encompass all information that we have about the LIR resources.

The tool can also suggest free space, and it does this with the conservative algorithm in mind. So essentially the same thing as IPRAs use when they allocate address space to you, that will suggest from all of your allocations which is the best block that you could give.

And like I said, both within the user interface and within the API that we have built, it's no longer needed to contact an IPRA to get the information that you want.

This is what it looks like. Thanks for letting me use his registry as an example. On the left side you see all the allocations that Elisa has with a little bar next to it with a usage. On top there is a division for each allocation, what has been assigned what is infrastructure and which space is free. All the assignments are made within that allocation, so you can search through it, you can find information. You can find invalid assignments that you have made. And you can start from there to actually fix all of those issues and get a good overview of your address space.

Now, a comment at the ?? one that Nina made at the last RIPE Meeting was that this is great, this is a really nice fancy user interface but as your LIR gross bigger, having a nice fancy user interface like this, it doesn't really scale and I would like to have this information locally and would I like to have it maybe in something like plain text format, exactly like ASUs used to do, could you please also provide that?

And yes, we do now. In two formats. Plain text and J son. And the plain text output actually uses the exact same form as as the ASU tools used to use. You can simply grab the data using Curl or Wget, whatever you want, even a browser if you would like to and you can script around it, use it in your local IP address management application. So the only thing you have to do is to Curl and go to a certain URL and it will get the data you need. Because it's a private information we looked at API access key. You go to the LIR portal and if you have an administrator account, if you have administrator privileges you can go to the API access key section and generate a key. Now, you are responsible for this key, so you have generated a key and you can use it and distribute it within your own organisation, give it to the responsible person, you can create as many keys as you like and you can also revoke keys as needed. So it's completely in your control.

So you just create a key for the different applications that we have available with an API and with it if you visit the URLs, this is the output that you get with the AS used format. Thanks to Thomas Mangan for letting me use this as an example. So these are all the assignments that are made. This is all the free space that he has available and these are the invalids that he used to have, but since have been fixed. It's really hard for to find somebody who actually has an example of invalids and actually let's me show them. But they are fixed now so if he would check this now it would be okay. And of course, because it's hip with all the kids, we have this in J son, so you can get the same information and stream it into your local IP address management application, script around it or do whatever you want and this example also shows that the RIPE NCC doesn't do things perfectly, because I actually managed to find an invalid that the RIPE NCC has. Which has not been fixed by the way. Still working on that.

But more to come. We want to refine the user interface because what we do now is within the IP analyser we know about all of your allocations, we query the RIPE database in realtime for all of the assignments that you make through the restful API that the RIPE database has. But if you, from within the IP analyser say I am going to select this block as free space that I'm going to now assign to a particular customer, it would actually be really cool if you could start the database entry right from that point or maybe the resource requests that you would send in to the IPRAs. We also want to do active notifications of invalid. So people don't normally get an overview of invalid when they ask for it, but it actually shows you within the LIR portal that there are resources that require your attention, so that people are enticed to have a look at their invalids and actively fix them and that they not only do it when there is an actual need for it.

And if any requests, if you have any ideas on how we can expand on this idea, then please give us feedback. Because we want to make this as useful as possible for you.

Because, there is one more thing I want to mention. We have this API for all of the assignments and all of the free space and all of the invalids that you have, but we also have an API for all of your resources so the complete suite of all of your private information that resides within the LIR portal is now unlocked through the API and an API access key to use within your local IP address management. So all of the allocations, all the PI assignments, your assignment with no history, everything is available through the API and this is in Json and XML format.

All of the information on how to use this and how to set this up and how this format is put together, what you can query and what the different URLs are are available on this. We have information there, on everything you need. RIPE Stat and RIPE Atlas, so lots and lots of data you can use locally to script around and use within your local configuration.

If you have any questions, I'd love to hear them and otherwise, please send me an e?mail at that address.

CHAIR: Nina.

AUDIENCE SPEAKER: Nina. First of all, I would like to congratulate you on actually doing what I asked you to do at the last meeting. I really think an applause is actually in place here.

ALEX BAND: This is very gratifying.

AUDIENCE SPEAKER: Nina. I think from the testing I have been doing, I actually have to say you can even deal with my number of invalids and registrations and small amounts of free space, and so, I think you have done a really good job on this scaling and getting the data out of the system fast, and I really appreciate that.
Also, I think it's important that you, as you do, pay attention to old?fashioned people like me who like text and also know that at the new kids are here and they like the new fancy formats as well and I think that's a good thing. I might even have to read a book about Json at some point. There is one thing I just noted in your slides about what you wanted to work on to improve, that I might question if that was worth it. And that was the increased instigation into the database with updates. Again, I think that might be a good idea for a very small LIR, but would we not rather have also the small LIRs have their registration integrated into their provisioning tools instead of having them to work in two systems. So maybe you should look into interfacing or nice ways to interface people's tools instead, instead of having fancy web applications? And I think that was it. Otherwise, I'll write you more e?mails.

ALEX BAND: Thank you. Really appreciate it.

AUDIENCE SPEAKER: Chris. I have a question from Jabber and Tory Anderson from Redprill asks: Have you requested a public and authenticated version of the analyser that those the same information as ASUs would for any arbitrary LIR?

ALEX BAND: No, we haven't considered that, but that is certainly something we could also think about, because the line of thinking that we were on is that eventually when the IP analyser contains all of the information that you could possibly get, that we would essentially deprecate the existence of AGUs because it's no longer server appropriate. I hadn't really considered that particular use case. I'd have to think about it. I have to note that we have a fairly limited amount of resources working on this, and they can't work on this until infinity. They also have other other projects like billing software and charging scheme software so within the next couple of weeks we can implement another couple of features and then we'll probably move to some other projects after which we'll try to gather as much feedback on the current implementation as we can and then continue to work on it at a later point in 2013.

AUDIENCE SPEAKER: Wilifred. Just a very quick reaction to that proposal. I think we should be not too fast in agreeing to implementing stuff that gets thrown at us from a particular mindset, because the authoritative information that is public is actually the registry data that is accessible by WHOIS. The rest, whether I adhere to the rules and procedures, assignment Windows, that sort of things, that's something between the local LIR and the NCC. I do not see any good reason why sort of the stuff that gets potentially pulled up by this new tool should be publicly accessible. We should be very, very careful to limit the things to those audience who is do have a good reason to get access, but not sort of spill everyone with everything.

ALEX BAND: Absolutely. Anything that is private between the RIPE NCC and the LIR will at all times be protected by some means of authentication. We will never make something public that used to be private. We'll take care of that. One last thing and then I'll finish up. Right now the IP analyser has a beta label on it. We are working very, very hard at ironing out all of the little differences and discrepancies that may exist between what used to be available in as used and what is now available with the IP analyser. We don't want to get into a situation where an LIR would make an assumption or base a decision off IP analyser data and contact registration services about it and they would compare to maybe as used output and it would be a little different. If you find differences between AS used and IP analyser let us know because we need to verify whether it's either a bug in AS used that we fixed or it is something that implemented incorrectly in the IP analyser. Once we are confident that the IP analyser is a hundred percent correct in all cases we'll take the beta label off.


CHAIR: We now have 55 minutes worth of presentation to, say, fit into a 30 minute slot but I'm sure we'll work that out.

ANDREA CIMA: Hello, good afternoon everyone. I am part of the registration services team at RIPE NCC. And I wanted to bring you some exciting news today but Axel already gave away the fact that the we have run out of IPv4 addresses. Instead I'll show you a little bit of what our processes are over the past period and share some experiences.

First of all, we went through a phased approach so increase the transparency words to you and our members and also to ease internal processes as well.

Now, in Phase 0, we made quite a few changes to our internal processes. I think the main one was the creation of a single ticket queue for all IPv4 requests, so meaning new and ongoing ones. And the main change for you has been here the fact that rather than dealing with one IP resource analysis from start to end in your request, you will deal with a new IPv4 analysis each time depending on who was available. This has been done to increase the first come first served principle.

For the moment our communications department has increased the transparency about our data by creating some new graphs on our website. We created the new IPv4 available pool showing how much address space we have available. For furthermore we showed how many IPv4 requests there were in the queue and for how long they have been waiting there, so that you could be aware you could know when to expect a reply from our side.

Finally, we informed all the requesters, all the the potential LIRs as well about the fact that we were getting closer to the last /8 to avoid surprises.

In Phase 0 we also created an escalation process for large resource requests. What it meant was that requests which were for /15 or larger for PA or /18 or larger for PI were evaluated by the fault but not by one, by two IP rates. They were reviewed by the policy development officer, Emilio and myself, and by two senior managers to make sure that all the due diligence checks have been made.

Now, Phase 1 started on the 4th September 2012, when we realised that we had less than a /10 available in the regular pool at this point in time. All IP ?? to double check everything we, the principle of four eyes is better than two and to also increase consistency. Now, this of course has brought two slightly longer response times but we tried to do our best to keep this as low as possible. Also we changed our call back procedures, before if you would call us asking a question about your ticket we would call you back within two hours. In Phase 1 we couldn't do that any more because we didn't give want to give an unfair advantage so one LIR over another. We would call you back only when your ticket was at the top of the queue. And finally all approvals for allocations and PI assignments were delayed until the morning after nine o'clock for one very simple reason. We wanted to have additional time to do checks, to make sure that the request was justified, and to make sure that we were approving them in the correct order, which is very important here.

Phase 2 started on the 14th September this year, this is when we have reached the last /8. We started allocating /22, however, only from Monday 17th September. And what does this mean for our members? It means that every organisation, every LIR can receive one /22 only, and this case the LIR must also have some IPv6 address space and it can be either an allocation by the RIPE NCC or by another member.

And an important point, no new PI assignments are being made at the moment. We are receiving still, we are still receiving requests for PI assignments and we are redirecting those requests to the ongoing policy that is in place, the policy discussions.

Now, all these phases have had an impact on the RS activities but mainly Phase 1, the last month. The main focus was on due diligence, we wanted to do things well and that's why you may have had to wait a little bit longer to receive a reply but we also wanted to focus on giving you the best response time as possible. Together with registration services team we decided to not to take any holidays during the last five weeks, and at the same time, we also had to lower priorities of other activities that usually are really important. This means that we haven't been performed, but on a lower level. By this I mean audits, activities, related policy implementations, investigations and processing changes in contracts and mergers and takeovers. But we are back on top of it right now.

To give you an idea of the amount, of the number of requests that we have received, it's quite interesting to look at the ?? this is between August and September, we can see that the number of IPv4 requests has increased dramatically, almost doubled in certain moments in time and that was after the announcement that we were in the last /10 before the last /8. It's also interesting to see around the same period, those two lines. The first one, the red one, is the amount of address space that was available in the RIPE NCC regular pool. And the blue line is the amount of address space being requested at a certain moment in time and also here you can see a big jump in v4 amount of space requested during the last period. This is not only due to the increase in number of requests, but also to the fact that some LIRs have been requesting a bit more than what they could justify. But like I said before, we had all the due diligence checks in place so we found those requests out.

Just to give you an interesting example. We received a request from one LIR for a large number of addresses and they sent us excel sheet containing all the names, addresses, telephone numbers of their customers to show this huge growth. They just had forgotten to remove the "change the file name," which was still named "fake name" So that wasn't the only case, we had more like this but let's keep it at this one. That also means that it took us a little bit more time to evaluate their request because we wanted to make sure to give address space to the people who really needed it.

The last graph. This is my favourite one. It's the cumulative address space issued by the RIPE NCC on a yearly basis and it's quite interesting to see how in 2009, 2010, 2011 and 2012 we have issued the same amount of address space even though the allocation periods have become much shorter. So that means that runout fairly has done its job really well. And it's also interesting to see just different situation in 2012 just in the last two weeks where we have issued more address space than usual.

Finally, just to conclude. Some stats and numbers. During Phase 1 the last /10 we have allocated 162 prefixes to 147 organisations. The total amount of v4 space allocated has been almost 3.4 million. The total number of PI assignments during the same period has been of 186 to 140 organisations and for a total of about 230,000 IP addresses. And from the last /8, meaning since the 17th September, we had this morning, we had allocated 160 /22s but in the meantime since this morning that number has grown of course.

Do you have any questions?

CHAIR: No? Okay. Thanks very much.


CHAIR: So, next up then is Niall, to present the proposal we had for the ERX resource folders. We already had a discussion on the mailing list, a little bit. But so let's here the update.

NIALL O'REILLY: Thank you, Curtis. I'll start by offering apologies from two of the authors whose circumstances didn't let them be here for the meeting. You have seen that I have accumulated a few more partners for this, but they still drew for me the short straw as to what should present it.

I thought it would be helpful to start with what are the goals of this because they may have become a little obscured in the noise over the last while. And these are that the legacy resource holders want to become really part of the family that we help set up 20 and more years ago when the RIPE database as it was called then, the basis for today's RIPE registry, began to gather legitimacy because we were putting our records in there. When the RIPE NCC needed moral support and organisational support from the ENREN community and when this was was enthusiastically given. We want to be back belonging where we think we belong. We want to get the services we need. We want to get them ?? we want to get what we need. We don't want to have extra baggage in there and we are happy to pay a fair price. We have to talk somewhere else about what might be fair, but those are the key goals and those are the things that I think people should mostly take from this presentation.

There has been some, as I think we all know and I don't want to dwell on it too much ?? there has been some unfortunate miscommunication in both directions and this background slide mentions some of things that you know already because I mentioned them to you in Ljubljana, some of the things that maybe weren't mentioned then but it's no harm to put as background material, and those are the legacy resources are those which were distributed before today's Regional Internet Registry system was put in place, and this Regional Internet Registry system is documented especially in BCP 12, which is RFC 2050 and its predecessors, 1416 and 1366. And those are out there and they have been there for a long time. And the mandate that those documents give to the regional Internet registries is, includes a responsibility for maintaining a registry including the legacy Internet resources in their geographic region. And that's an important responsibility that the regional Internet registry has, a responsibility to the community beyond just its membership. And that's something that we mustn't lose sight of.

The NCC focus has naturally been over the past 20 years of development of our industry, has been on distributing Internet number resources to people who needed them, and who needed them urgently and the pressure has been much more in the distribution area than in the registration area, especially for the registration of resources which it hasn't had a hand in the risks of. A natural side effect of the distribution process has been the maintenance of corresponding registry data. And it's simply an accident of history that the earlier distributed resources didn't receive the same attention on the registration side.

Recently, from Vienna onwards, as Wilifred mentioned earlier, the NCC has begun and new outreach to legacy resource holders, and there has been a reaction from some of the target organisations, beginning as long ago as last November, continuing at Ljubljana and now. These reactions included alarm signals to what was perceived as threatening approach from the NCC, and I'll come back to that in a minute because I don't ?? all I'll say now is it's important to recognise that this is more a communication channel problem than a question of blame.

And the key thing for the moment, apart from the goals that I mentioned in the first slide, is a need to get on the right track and to give the our RIR, the RIPE NCC, the opportunity to avoid acting in a policy Freezone which was the only place it could act until we have a policy.

The NCC outreach, as I said, began at the time of RIPE 63. Due to what appears to have been an error in finding the right pieces of document, the message that went out to the legacy resource holders was one which they could only interpret as a threatening message, and it wasn't clear for a long time that this was probably an inadvertently the message that was chosen to give to them. And the problem with the communication was simply that the NCC checked to see, are we doing what we thought we were doing? And the answer was yes. So that they weren't getting the idea that something could be wrong, and on the other hand, people like me weren't getting the idea that this should ?? that this wasn't deliberate. And so, what ensued was a continuous turning up of the volume of the alarm signals as we thought, instead of the thought ?? and it's a simple failure of error handling. Instead of the thought, oh, they are not getting it because something else is wrong. And had that been obvious earlier, a lot of the more strident exchanges over the last while might have been avoided.

We have had progress since RIPE 64. At RIPE 64 I gave a presentation of which this is the follow?on, I introduced the legacy resource holders. I mentioned that we felt that something was wrong and that we needed to have a policy. Since then, we have drafted a policy and much, though I thought I had understood the policy development process, I had only understood the downstream end of it and the upstream end of it is a bit different. So, there were a few false starts there.

It was, however, useful false start, I believe, because it meant that there was a vigorous discussion on the NCC Services Working Group mailing list. And a lot of those ideas have been very helpful, both in terms of the analysis that various people have done, I'm thinking of ?? I'm sure I'll offend people by leaving them out, but I want to pick some examples. I'm thinking of Gert Döring, of Nick Hilliard, of Daniel Karrenberg who have made particularly helpful interventions in that discussion. There were lots of other people as well and I'm sorry, Kurtis would kill me if I took the time to mention them all, even if I could remember them. So, please don't be offended.

Crucially, the alarm signals were heeded and this is a good thing, and what we have to do now is make sure that not only has there been a change of course, but that we're going to arrive on the right track.

I don't want to spend too much time on this slide, except to emphasise to everybody in the room that that slide, which is perhaps a rather strident overstatement of what we have subsequently come to realise might have been necessary, represents the state of the appreciation of the situation in the minds of the people involved, of the concerned legacy resource holders at the time it was drafted, and although it was released after the change of course at the NCC, we're looking here at a delay in the propagation of that state. State always propagates slowly. Sometimes slower than you expect.

As I said, the vigorous discussion has been very useful. We have begun to draft a second version of this policy proposal. We have done some homework on that even while we have been here and we'll do some more before we go home. I don't expect we'll finish it, partly because we haven't heard all the comments that people may wish to make either here in this room or afterwards in a formally different room, which is probably physically the same space, in the general meeting.

And the next version of the proposal will be much shorter because it's become clear that much of what we felt was under threat, is not under threat. There will still probably be one or two contentious statements in the next proposal that will have to be talked through and understood better by everybody involved, but the focus will be on registration and related services, on fair access to those services, whatever fair will mean and that will probably be part of the contention, and to put out of scope whatever were the terms of the original grant of the resources, or to put it another way as came up in a conversation earlier in the week over coffee or in a corridor, to separate, to decouple the Address Policy issues which don't apply because these resources were handed out in an environment where Address Policies were entirely different, and those are the Address Policies which are coupled with those resources. To separate those issues from issues around the delivery of registration services because it's quite clear that the registration services also have to have a policy framework, and that we can only register our resources within some well defined policy framework. So, this will be quite a big change of emphasis from the last, from the version 1 of the document. And we could waste a lot of time, much to Kurtis's annoyance, I am sure, talking about and nitpicking over the content of version 1 of the document. I'd suggest we try to avoid that at this stage.

And finally, I'm at the end of my presentation. And happy to have discussion.

CHAIR: Any other comments, discussions, follow?up that we didn't have in the list? I want to make one clarification. Someone asked me when I sent the mail about ?? a few days ago, whatever it was, about when the policy was posed, I said I am not going to start an official time count because I already knew there was an updated version coming, so I thought it was pointless to start a formal time count. I'll do it once we have a new version released and then we'll start a full discussion, so you get some extra weeks to discuss this. Anyone that you want to have some comments that you want to have on the mailing list, you want to have a discussion now, that we'll be catching up on time now. Anyone? No, that's very good. Thank you.


CHAIR: Then, next will be Nick.

NICK HILLIARD: Hello everyone, my name is Nick Hilliard from INEX, and I want to talk to you about a proposal for publishing the sponsoring organisation for direct assignments. Here we go.

So, there are a couple of policies which are relevant here. There is RIPE 452 which defines the contractual terms for end users to have a contractual relationship with a sponsoring organisation. So that there is a link maintained between it and the end user and the RIPE NCC. And this was introduced in policy 2007?01. I am not going to rehash the policy because I think most people probably know what it's all about. But the problem was that the policy never specified that there should be ?? that the sponsoring LIR should be identified in the RIPE database with the actual object assignment. And this actually causes a bunch of operational issues, which have been discussed on the mailing list. I think probably in particular, from a philosophical point of view, the two most important documents are RIPE 506 and 559 which are the IPv4 and IPv6 address and assignment and allocation policies which specify that there is a requirement for registration of resources to allow for trouble shooting at all levels within the database.

So, the situation is, there is a couple of notes up here, I'm not really going to go through them in great detail. A policy has been submitted in the PDP process. It hasn't been ?? it hasn't kind of come out the other side, so it hasn't gone into the mailing list, but the basis of the policy is to say that this is probably a good thing, that we probably do want to know in general who is the sponsoring organisation for the LIR, whether the sponsoring organisation ?? sorry, a sponsoring organisation for the end user, whether the organisation be the RIPE NCC itself or a sponsoring LIR. And there are several reasons why you'd probably want to do it, they range from abuse handling to coordination of resource transfer between LIRs to allowing the end users themselves to check if ?? to check who their sponsoring LIR in case that information is lost within the organisation.

A couple of people have made the comment on the list that this will reveal a contractual relationship between two organisations which is to say the end user and the LIR and that maybe this isn't such a good thing and this is a valid point. I think it's important to acknowledge it. I also think that the advantages of a publication of this information outweigh this point.

So this is just essentially a heads up that there is going to be a policy hitting the RIPE NCC Services Working Group pretty quickly. This is what it's all about. And if you have any questions, please come up to the microphones and ask them, or alternatively make them on the RIPE NCC Services Working Group mailing list. Okay. So thank you very much.

AUDIENCE SPEAKER: One question. My name is Bill Strasky. So, as I understand it correctly, it's a reincarnation of 2010?10 proposal, yes? It was two years ago, and honestly speaking, I was the proposer and there was a lack of the community support for that.

NICK HILLIARD: I simply ?? there are a couple of numbers that I know, but 2010?10, I am sorry ??

AUDIENCE SPEAKER: I had to Google it. I mean ?? so that's reason I remember the number, but the comment there was two years ago there was that proposal and there was a lack of support from the community. Maybe it's time right now to raise it once again.

AUDIENCE SPEAKER: Emelio. It's in the archive. It's in the archive on the RIPE website.

CHAIR: Is it the same proposal?

AUDIENCE SPEAKER: Emelio. Slightly different, that proposal wanted to change the contract of the relationship. As far as I remember. This is a similar scope but a different approach.

SANDER STEFFAN: I have it here. The title is: "Adding reference to sponsoring LIR in INETnum and..." it was withdrawn at the time.

AUDIENCE SPEAKER: If I recall correctly the scope is similar, but that proposal wanted to change information to the contractor's relationship, to the contract term. This is something different.

AUDIENCE SPEAKER: I wanted to add just a link between those.

AUDIENCE SPEAKER: Nick wants to add the technical solution to a request, but you speak yourself...

CHAIR: So maybe Nick will want to go back and reread 2010?10.

NICK HILLIARD: I don't really recall the proposal, but I will check through the mailing list archives and take a look. Thanks very much for bringing it up.

CHAIR: But are you proposing to actually make a formal proposal for this or how ?? I mean, how do you want to proceed?

NICK HILLIARD: Dave and I have sent in a first draft of a proposal into Emelio and it's going through the mechanism of changing from that into a formal proposal which will hit the PDP, to this Working Group, to the NCC Working Group, exactly.

CHAIR: Okay . Thank you, Nick.

NICK HILLIARD: Thank you very much.


CHAIR: So, this is the third time today that I finish on time. And I think that's pretty good. So with that, if you have any other business for the open microphones, you have around 4 minutes of open microphone time. You don't have to use it. That's fine. Okay. Thank you all ?? one last thing before we go though ?? while Wilifred goes to the microphone. The AGM is going to be in this room, so when I said we are done here you have all to quickly leave. Leave the room. Before that we have Wilifred.

AUDIENCE SPEAKER: Wilifred Woeber, and this time wearing the hat of the Database Working Group co?chair. We had a discussion today about the potential merits and views and flaws and whatever of the geolocation functionality in the registry. And my attempt to get feedback on the usefulness or not on the Database Working Group failed miserably, and during the discussion there were ideas to actually broaden the sort of the spread of the information that this functionality is there as a test case. And you might see in this Working Group, sort of a couple of questions or a short writeup or a request for additional input because from the Database Working Group point of view, we don't want to have the RIPE NCC spending resources on something which is not used. On the other hand, we don't want to stop that unless we really have confirmed that there is no interest. Thank you.

CHAIR: Okay. Thank you. All right. Folks, with that we are done. Thank you all for coming and see you next time. And Nick here is going to chase you all out of the room. If you are the last one outm, he will forcefully lift you out. So thank you all. See you later.