Archives

Cooperation Working Group session
6 November 2014
11 a.m.



CHAIR: We're back to get started clearly.

Anyway, it's time. It's 11:02, soon 11:03, could everybody please sit down and we can start the session. Thank you very much, I just got to say a couple of words. We are, Meredith and me, are the three co‑chairs for this Cooperation Working Group. Anan, the third one, couldn't make it for this meeting but we had a job to plan two sessionings of Cooperation Working Group that's going to take place today, now in the morning and then in the afternoon. Anan said hello to everybody and said he actually wanted to be here but he couldn't because he made ‑‑ he changed his job actually, so now he is working are to for the European Commission, and that's also very good in the mix of the three of us, our pro files for being co‑chairs for the Cooperation Working Group, I think it's great to have Alan at the commission again. He was there before.

MEREDITH WHITTAKER: Welcome to the first of two cooperation group sessions. This is going to be a special presentation focusing specifically on the IANA transition and a number of hot governance topics that so many of you are aware of. We are going to turn it over to the RIPE NCC who have been very diligently handling this and there's going to be lots of time for questions and discussions to prepare to be engaged.

Before we move forward with the good stuff, I just want to accept the minutes from last meeting. They were released on the list around June 10. There were a couple of comment. Those were folded in. So any objection to say that? I don't see any objections. That sounds cool. And then Chris Buckridge over here has volunteered to be the scribe for this meeting. So he will be taking minutes and he will be sending those back out to the list and we'll repeat the same thing next time. So, with that, thanks again for being here and I will let you all get started.

CHRIS BUCKRIDGE: Good morning. My name is Chris Buckridge. I work forth RIPE NCC in the external relations department. We're going to do something a little similar to what we did actually at the last meeting with this. I'm going to provide a little bit of background on this IANA stewardship transition discussion.

I can show you the agenda we have here. We have released a few some principles in draft form to the corporation list in recent weeks and also published them on our website. So we want to take you through the process of how this is all working, what this draft RIPE principles looks like at the moment. How we see a possible way forward or way ‑‑ future vision for oversight of the IANA functions and then look also at some of the developments that have been happening in other RIR communities and other affected communities of IANA.

My colleague, Athina, is also going to discuss accountability and so that's in the context of accountability of ICANN, but also accountability of the RIRs themselves. And all how that relevance to this IANA stewardship discussion. So she'll give a brief presentation. And then really the majority of this session we want to hand over to you guys, to get the community discussing, talking about some of the proposals on the table, what's important for this community in looking to the future of the IANA function management and oversight and Paul Rendek will lead that discussion.

So, I'll start very briefly with some background on this. I'm assuming most people in the room have a fair sense of what this is about, but just for those who haven't been following.

In March this year, the national telecom and information agency Cap 5, an agency of the US Department of Commerce, announced that they would intend to transition away from their oversight role of the IANA functions. And so this is something had a ‑‑ well, those IANA functions include management of the global pools of IP v4, IPv6 and autonomous system numbers so the RIRs and the RIR communities are obviously very important stakeholders in this discussion and in what results from it.

That announcement by the NTIA started a global multi‑stakeholder process to identify what this oversight would look like in the future, who if anyone, or what if anyone, would step into that role that the NTIA has filled historically. And so that work is now going on, that discussion, that development of ideas and proposals primarily in the three affected communities of IANA, so that is the numbers community, the RIRs and the RIRs communities; the names communities, so that's the TLD operators and communities both for country code and generic top‑level domains; and also then in the IETF, which is responsible for the protocol parameters registries which is part of the IANA functions.

So, to start to go through what this process looks like at the various levels. We start off here with the five RIR communities: AfriNIC, APNIC, RIPE, ARIN, LACNIC. All of those communities are holding their own discussions about what they feel is important, what they think future IANA oversight should look like. We were quite fortunate in the RIPE community in that we had a meeting in May shortly after the NTIA made its announcement. We have actually already had some discussion in public as well as on our Cooperation Working Group. The other RIRs had meetings quite recently; APNIC, ARIN and LACNIC have all had their meetings quite recently to have their first face‑to‑face discussion about this. AfriNIC will have a meeting in a couple of weeks time where they'll also have face‑to‑face discussion. But those discussions are already taking place on mailing lists, in forums and in other forums around the world.

So the output from those five RIR communities is expected by early December 2014 ‑‑ that's a mistake on the slides, I'll change that. So basically, in an about a month, a month and a half. From the RIPE community, you can see the summary of the discussions that we have been having already at this URL, it's easy to get it from the ripe.net home page, just go through the IANA stewardship link there. But those discussions are happening in the Cooperation Working Group mailing list archive. There is also then summaries of other discussions that have happened in some of the regional forums that we help facilitate and that we attend. So that includes, ENOG, MENOG, RIPE NCC regional meetings that we have had in a few other countries, the southeast European meeting. And then that page can also link you to discussion archives from the other RIR regions and also to global discussions, because this has been heavily discussed in places like the ICANN meetings and the Internet Governance Forum.

So, the outcome of those five RIR community discussions will at some point need to be formed into a single Internet numbers community proposal, and so this was mentioned in the Plenary earlier this week, the CRISP team, consolidated RIR stewardship proposal team is the solution for that problem. It will consolidate the four RIR communities into a single proposal and that CRISP team is currently in the process of formation and will have representatives from the all of the five RIR regions selected from community members, two community members from each region and RIR staff, one RIR staff from each region.

Part of the timeline, the process of that CRISP Working Group will be to also feedback what it produces to the RIR communities for their comments. So this is not a process of just handing over output from the RIR communities to the CRISP team and then having it passed forward. There is going to be an iterative process here where there'll be further transfer discussion.

And so, the CRISP team will also be doing its work transparently via that public mailing list. So if you have an interest, if you were keen on following that work and those discussions, you can sign up to that list and follow what's going on there.

At the same time as this is happening in the numbers community, there are other parallel processes happening in the other affected communities. And so you can see that here. At the top here is the Cross‑Community Working Group to develop an IANA stewardship transition proposal on naming related functions. And so this is a group that was formed quite recently, had its first and probably only face‑to‑face meeting at the ICANN meeting, ICANN 51 meeting in LA a couple of weeks back. And its goal is to produce a single output from the naming community, and what they see as important and how they see the IANA function oversight as looking in the future.

At the same time, the IETF has been working on its model, its proposal for what IANA stewardship would look like, particularly with regard to that management of the protocol parameters registries. So there is an IANA plan Working Group that's been formed within the IETF to look at this, there are like all IETF Working Groups that's open, transparent, you can look at the archives, join the mailing list, see everything that's being discussed there.

And the IETF has been doing this for a bit longer than the naming community, because they have basically been working on this since the NTIA made their announcement, so they are quite well advanced.

So the output from those three different groups, those three different communities, will be then forwarded to the IANA Stewardship Transition Coordination Group. And so this is a group made up of about 30 members from different stakeholder groups, that includes a lot of supporting organisations in ICANN, the ASO, the NRO from the numbers side, also the Governmental Advisory Committee, so there's a lot of different people working there, and this ICG has been working now for a few months producing, among other things, a request for proposals document, which is what will be the template for those proposals from the three communities and from those three proposals, the ICG will attempt to consolidate a single proposal which will eventually go to the NTIA and hopefully facilitate the transition of the stewardship of the functions.

As with the CRISP process, this will be iterative. It's not a simple straightforward one‑direction process. The ICG will produce a proposal and this will be communicated back to the three communities, to all of the RIR communities, for their feedback, for any sort of identification of objections or problems with that and then finally we'll proceed to the NTIA. And so this gives some idea of the time lines that we're working with here. The end of this timeline, at least the assumption for now is that the current contract between the NTIA and ICANN expires in September 2015. To prevent renewal of that contract, there needs to be agreement in place well in advance of that date, so that the NTIA can make all of the changes and the work that's needed to do to transfer itself or to end this contract, to transfer itself out of oversight.

So, as I mentioned, December 2014 is when the RIR communities will produce their outputs and deliver these to the CRISP team. The Chris.team will basically have until the middle of January 2015 to produce a single consolidated output from the RIR communities including the iterative process going back to the communities, that will be a compressed timeframe for that work to happen. Once the ICG has the ininput from those affected communities, names, numbers and the IETF, it will then have from middle of January to around June 2015 to consolidate a proposal, send it back to the communities for any final input and deliver it to the NTIA. So the whole timeline really is very condensed and this is something one of the big challenges of this project.

So, as I mentioned, the CRISP team is currently being formed and this is something that's going on particularly at this meeting now. All five regions are ‑‑ have ‑‑ are putting out open calls for volunteers, two community members, one RIR staff member. The RIPE call for volunteers is now open. And officially we're going to keep that open until the end of this session, the end of the discussion in this session. We have had two people already submit their names for consideration to the Cooperation Working Group list, that's Narani from Netnode and Ray Robachevsky from ISOP. And we are also happy for anyone who wishes to volunteer to either send a mail to the Cooperation Working Group list or to stand up today and make a case on the microphone. That's also fine.

The RIPE Chair will work in collaboration with the executive board of RIPE NCC, select from the names that we have received, two community representatives and that will be announced, those two names will be announced in the Plenary this Friday for support, endorsement by the community.

As I mentioned, the CRISP timeline includes community feedback before going to the ICG. There will also be an obligation on that CRISP team to communicate to the ICG, so to the global coordination group, if it seems like consensus can't be achieved between the five RIR regions. We're not expecting that to be the case but that's a final responsibility of that team.

So, I want to quickly now just walk through the draft community principles that we have published on the website. So this is essentially the basis for the discussion that we want to see here today I guess. To hear your feedback, to say yes, these are good or no these don't cover everything that needs to be covered, or these misrepresent the community position.

The first point is that the RIPE community asks the RIPE NCC to work with the other RIRs to produce a common proposal for a legally binding agreement such as a service level agreement, between ICANN or the IANA operator, and the RIRs. And so that service binding legal agreement would replace the numbers‑related elements of the existing ICANN NTIA agreement. This proposal needs to meet the requirements of the RFP produced by the ICG. That doesn't necessarily mean it needs ‑‑ that we expect it to be in the format of that RFP. The CRISP team will certainly have to produce it in that RFP format but I think at this point it seems more straightforward to deliver a sort of streamlined set of principles that can feed into that CRISP process.

The proposal should bring the provisions of the agreement related to services and service levels up to date with current requirements where necessary. So this is basically just saying, part of the process will be to review what actually these requirements are, what the service levels are, do we need to consider changes to them or are the current arrangements acceptable to the community?

The work should be coordinated with other users of the IANA function as much as practicable, and with the aim of producing an agreement that can fit with those other proposals. And so this is working not only between the five RIR communities, but also with an eye to what's going on in the naming community and the IETF.

The RIPE NCC will keep the RIPE community informed about the progress and content of this proposal. So that's our role as secretariat there is to ensure that the community has access to the information about this transparent, open process.

And the RIPE community asks the RIPE NCC to complete the proposal and submit it to the ICG before 15 January 2015.

So these were produced before the CRISP team formulation was developed. So possibly that last item will need to be adjusted to fit with the model that we have discussed about the CRISP team. So that would be one further edit that might be necessary.

So, obviously the key point, the first point in those is the development of an SLA, and a legally binding agreement. We don't want to go in the community into a full detailed discussion of what that contract would look like, that's something that needs to be developed, I think, by the lawyers, by a smaller team. But I do want to walk through what we in the RIPE NCC have looked at and think an SLA would look like at a sort of more general level.

So, the IANA operator ‑‑ so these are basically the elements of that contract. We would say that the IANA operator will execute global policies according to the global PDP, which is already detailed in the Memorandum of Understanding between the ASO and ICANN.

It would include the process, time lines for communication etc., for how that work would be carried out.

Any other specific obligations on the IANA operator in terms of performing the number related IANA functions.

It would establish a review mechanism to ensure that those obligations are fulfilled.

And it would lay out a specific consequences for what would happen if those obligations weren't met.

It would define the term of the contract, so the length of the contract.
And also any, the means by which either party, so the RIRs or ICANN, could terminate that contract.

And finally, it would define a process for the resolution of disputes between those parties to the contract, and the jurisdiction under which such resolution would take place.

So, this is just our first look at what that SLA might look like. We're happy to hear feedback, keen to hear feedback on any ideas that others might have about what's necessary to include there.

And so my final slide here and my final, I guess, bit of summary of where we're at is in terms it of what's already been discussed in the other RIR communities.

So, APNIC was the first RIR to come out with a solid proposal and it's relatively similar to what we have outlined here, what we have outlined on the site. With the one difference being that it includes establishing a new memorandum of understanding between ICANN and the NRO. So this would be a non‑binding or non‑legally binding agreement in addition to that SLA, which would essentially state the multi‑stakeholder nature of the organisations involved and the processes involved. And would eventually replace, as is my understanding, the ASO, MoU which is currently there.

LACNIC, more recently, produced their proposal which builds on that APNIC proposal. So it includes the development of a new MoU, but it also establishes a further body, a multi‑stakeholder Oversight Numbers Council with would provide and overview of how the IANA operator is performing those functions.

ARIN is also working its process through. After their recent meeting they conducted a survey to their community and the results of that survey on what they feel is important have been published online.

They are currently in the process of appointing their community CRISP team representatives, and my understanding is that those CRISP team representatives, once they're in place, will help guide their community discussion and formation of some output. I'm sure others from ARIN can explain that further if necessary.

So that's where I'm going to leave is in terms of a summary of where we're at, how we got here, what we see as the way forward. As I say, we do plan to have most of this session devoted to discussion from all of you. But before that, I'll invite Athena to come up and present on the connected related discussion of accountability in ICANN and the RIRs.

ATHINA FRAGKOULI: Thank you Chris. Good morning everyone. I am the legal counsel of the RIPE NCC. And I'm here this morning to talk to you about accountability issues.

This is the new buzz word actually, and we hear it all the time. And so, it sounds a bit abstract, we don't really know what it is so let's put some context on this word.

What is accountability? How do we at least understand accountability? So accountability for us, for our community, is the requirement to comply with what the community wants. How do we do that? We have our policy development process, which is open, inclusive, transparent, bottom up. And we are in communication all the time through meetings, through mailing lists so we understand each other, we know what each other wants.

Also, accountability is operational accountability. The RIPE NCC is a membership‑based organisation. It has a Board that is elected. This Board is responsive to what the membership wants. We have corporate governance, we have it documented in a transparent way and we refer to that. And of course this framework is not stable, it's dynamic and it's continuously evolving. And it's similar for all RIRs.

So, why are we talking about this now? We have to realise this is not a given. This is an achievement, not every organisation is like that. So, in the discussions about the IANA transition, this question came up, how accountable is ICANN? And we realise there is a big distrust towards the board of ICANN. And we got the impression that this whole ‑‑ this doubt will come to us, will come to our organisations as well. So, we figure out, wait a minute, we believe that our community trust us, and we have to show how accountable we are, we have to defend our system.

So, we realise we had to communicate to the rest of the world, like outside our bubble, how our accountability works. And we have to document it in a comprehensive way for others to understand it, and for all RIRs, not just for the RIPE NCC.

So the first thing we did, we created a matrix; a matrix with categories of all accountability issues and links to documents that each RIR had for these categories. And we published it on the NRO website. And we did something more. As we were sitting in the sessions about ICANN during the ICANN meetings or the IETF meetings about this whole thing about transition and ICANN accountability. We were writing down all the questions participants had had on the accountability. And we were trying to make this ‑‑ to change this question so that, what have these questions were addressed to us? How would that look? And we tried to answer this and a set of this questions and answers are also published on the NRO website for others to see and understand how we work. And to be honest, when we were doing that, we were ready to defend the system, we were like okay, what else can happen? What else are they going to ask us?

So we were in a defensive mode a bit. But what happened is not only were we were not questioned, not only were we not in doubt, we were getting congratulations on how accountable we are, on how the RIRs and the RIR communities with rely on the system. So we're very happy on that.

But of course, the decisions are evolving and so we have to keep listening to what other questions may come up, and our next step is to reply to these questions that came up. For example, in the ICANN meeting in LA or in our round table meetings we have with governments, we understand that we have to show in a transparent and clear and simple way how our Board is structured, how many members the Board has, how are they elected? For how long? How decisions are made for the budget, for the activity approval, for the fee approval, and how various documents are adopted or amended. And so we are working on that, presently I'm tasked to write down this document. It's no the that we don't have this documented, only we have it documented in a way that we understand it, we need to show it outside our community in a simple way. And also, we're working with other RIRs to do the same. So we're going to publish this again in a collective manner.

So, when I ask then why do we care about ICANN so much? If we're fine, we're fine, and we don't care what ICANN does. However, ICANN's accountability is an old discussion, it was there since its establishment. And it's important for our community, the accountability of ICANN. Because ICANN is the one that puts a stamp on our global policies. And we have to make sure that ICANN will respect the community's decisions. And will not start building other accountability mechanisms outside of our system in parallel, so, especially now, due to the IANA stewardship transition, this is relevant more than ever, and I'll explain to you why.

NTIA indeed did not have an active role in what we were doing. So one might think, NTIA, what's the big deal? NTIA, though, had a contract with ICANN, and is this contract specified ICANN's obligations and one of its obligations of for ICANN to comply with what the communities want. And if ICANN would not comply, there were concrete consequences and these were all part of the contract.

So if the contract goes, what happens with these obligations? How do we make sure that ICANN will comply?

So, the whole discussion started. In the beginning, people were saying, well, okay, ICANN's accountability, it's such a broad topic, let's not have it linked with a whole IANA transition discussion. However, many voices were heard saying that no, ICANN's accountability is also crucial for the transition for the reason mentioned before.

So, finally, it was agreed that okay, sure, part of ICANN's accountability is relevant for the transition, other parts of ICANN's accountability are broader, this whole discussion led to the creation of the accountability Cross‑Community Working Group, the CCWG as they call it.

So, initially they put together a drafting team for the charter of this Working Group. The RIPE NCC was in this drafting team, myself was there, and as an ISO representative, together with Izumi Catani from the APNIC region, and what Izumi and I tried to do was to make sure that this Working Group, the works of this Working Group will not delay the transition, because we can talk about ICANN's accountability for years but we have a deadline here.

So, the Working Group will have to focus on number 1, accountability issues that can't be solved before the IANA transition deadline. Or, they might be identified ‑‑ issues that may be identified as crucial or as relevant to the transition, but can be solved a bit later, after the transition, and that is very important.

Work stream 2, of course, can deal with broader accountability issues, that can take for years, but so be it.

Also, very important thing is Izumi and I managed to put in this charter was that accountability issues of RIRs should be out of the scope of this group. Because RIR accountability is an example, and we can only give our experience to this group, but the group should not jeopardise our accountability there, they should not have a chance to do that.

So, according to the charter, participants can be from each SO or AC and also individuals. An ASO is now working on which representatives to send to this group, and also, the charter ‑‑ the draft charter is right to be circulated and it will be sent to the mailing list shortly from RIRs.

And with that, I think we can start the discussion. Thank you.

PAUL RENDEK: Thank you very much Chris and Athina. I already see Randy ‑‑

RANDY BUSH: Two things. One for Chris is, in your development of an SLA, with IANA, there is within the IETF, work on an SLA with IANA, is that being at all coordinated?

PAUL RENDEK: Can you say that again?

RANDY BUSH: The IETF has had, for years, an SLA with the IANA. That's being developed and modified under this adjective, and I am wondering if the SLA that you are developing, is it all being coordinated with that?

The second question was to Athina, is ‑‑ and it's not so much a question, apologies ‑‑ there can be no accountability unless there is transparency, and the ICANN has been a brilliant example of lack of transparency, and there are transparency problems within some of the RIRs, not so much this one. So, I think ‑‑ I would really love to see transparency and accountability not just accountability.

PAUL RENDEK: Thank you, Randy, that's a very good comment.

ATHINA FRAGKOULI: So, you're saying that the IETF has already an SLA, right ‑‑

RANDY BUSH: With the IANA.

ATHINA FRAGKOULI: And it's about this particular function, the IANA function.

RANDY BUSH: Well, in our case it's the protocol segment of the IANA function. But it has to do with responsiveness and all those ‑‑ many of the things that aren't down to the actual details of the protein, of course like most SLAs, it has a lot of carbohydrates.

ATHINA FRAGKOULI: Our SLAs would be for the numbers function but I agree with you it would be a good idea to coordinate with the IETF and get some inspiration also from their SLA.

RANDY BUSH: You can beat me up and I'll try to introduce you to the folk on the IETF side responsible.

DANIEL KARRENBERG: I put the hat of ICG member on, that's the, what's on the slide as well, that's the people who actually have to take the three parts and sort of see that the compatible, consistent thing gets produced that all the communities are happy with.

It's part of the whole process that the IETF, the names and the CRISP thing talk to each other from the get go. And whenever the CRISP thing is constituted, certainly myself, but also Adiel and Paul Wilson, who are members of the ICG, will do our best to make sure that the CRISP thing doesn't work in isolation.

Also, just to be nitty gritty, the SLA that the IETF has with IANA is actually formally an SLA that NTIA has with IANA. It's in that stack of paper. And there's also an SLA in there that, if you wish, the RIRs have with IANA, but it's still formally NTIA's. And what I foresee is that none of the communities will ‑‑ all of the communities, to put it positively, will use that stack of paper as a beginning. So, there is ‑‑ hopefully already, some coordination by actually looking at the status quo and it was in Chris's slides, look at the status quo and see where it needs to be improved or changed. So, the short answer is yes, this coordination will happen. And if it doesn't, the whole thing cannot succeed.

CHRIS BUCKRIDGE: I just wanted to make one other point and Patrik Felstrom if he is here can speak to this as well. The Security Advisory Council at ICANN recently produced a document which explained the contractual arrangements that are existing there which is quite useful if others in the community wanted to get some more background information on that.

PATRIK FELSTROM: Let me emphasise what Daniel said, I am also part of the ICG and, the reason why I went to the microphone, we produced two documents. The first one tried to explain what IANA function at ICANN is currently doing. The other one is explaining what is covered by the contract between the Department of Commerce and ICANN, because these two sets are not one to one mapings to each other. They are things they are doing that is not covered by the contract and vice versa, so that is something to keep in mind. So read both. It's 67 and 68.

RANDY BUSH: Just need to make one comment to that. Daniel, actually, the SLA between the IETF and ICANN is under the contract but is not part of it and is negotiated entirely separately. And since everybody wants to throw titles around, I have to confess, that I'm actually on the IETF Internet Administrative... da da da ‑‑ but the piece of the IETF that actually worries about this. So I'm worried. Look at me...

AUDIENCE SPEAKER: Alexander from Russia. I have two questions: One is simple. One is more difficult. Maybe my English is not well, and I have not understand Athina completely, because in Russian, accountability is accountability too, you can be transparent, as Randy mentioned, but when you are accountable, there is an entity which could check you and do something like this. And believe us with the international community there will be countries, or organisations, or something like this, who will say no, this is not accountability under our laws or under this laws. And Athina has not mentioned how this problem is going to be solved, because, believe me, if we're talking about transparency, it's international. But when you say accountability, Russian Government will say, no, accountability to US Government is not accountability at all. That's a problem, I would mention it. Simple question. And it's more difficult because we are talking about NTIA transitions for a long time, I have seen presentations at least four times, actually this one is the best one, and I'll explain why. Because we are talking about processes. Let's make this, let's make that and so on. I work in a commercial organisation. When I came to my boss and started talking about process, I will not translate Russian what he might say to me. Any process should lead to result. Today, we heard the word SLAs, and Daniel mentioned this pack of documents. So, let's not just talk. Let's see from our secretariat at the RIPE NCC, maybe analysis of this type of documents. Actually, I have tried to read all this, and I think I have not understand everything. But maybe some analysis should be done and also some documents which contains possible decisions should be presented. We talked about processes a lot. As I said, today's Chris mentions could ‑‑ the result could be up here sometime. So let's talk about results. Currently it's only ‑‑ let's form this Working Group and that Working Group ‑‑ not Working Group, Working Group is good. But something like this.

PAUL RENDEK: Thank you. I can assure you that the legal teams of the RIRs will be coming together; they have started to look at this and we will share this as this is going forward. But thank you very much for your comment. I think Salam was first.

AUDIENCE SPEAKER: Salam Yamout from Lebanon. Is it too early to imagine what we want as a community? Can we imagine ICANN in two years given that the NTIA has stopped the contract with it, what does it look like?

PAUL RENDEK: Well, that's a very good point. That's a good point. I think really what we're looking for is maximum stability here and probably not massive change insofar as how we're operating as RIRs. So, I mean, it's difficult ‑‑ I think Athina tried to separate the processes here. There are two things that we're looking at. We're looking at this NTIA function, the stewardship function here. It is very, very specific. You cannot lob that process into the whole ICANN accountability sphere. I think if you do that you are moving yourself into a recipe for disaster, and I think you would be moving yourself into a process that will not have a positive outcome for the stewardship moving forward. So, it's very important to maybe separate these, although they must function in parallel, which I think is what Athina has shown. Izumi and Athina did a wonderful job inside the CCWG, because you must understand, it wasn't just folks from the RIR communities. You were dealing with people from very different walks of life, very different aspirations in what their Internet governance structures look like. So when you come with a team like this, to be able to show that understanding that if you actually went down a certain road you could derail a process. So, let's move the NTIA stewardship transition to maybe one side for a moment because it's easy to look at it.

If you look at ICANN accountability down the road, I think what Randy ‑‑ you just hit a lovely nerve, Randy, with what you said. Sure, we have got accountability within the RIRs, we're at different stages of that, we are different regions, right. We are trying to move towards this process kind of moving forward. We have transparency; is it perfect? Maybe not. Is there work to be done? Yes. But are we an example inside of ICANN's accountability where this process ‑‑ where a process like this can be done? And I think we are. Which is one of the reasons why the RIRs got together and did the accountability matrix document, or looking how that's going to be developed moving forward.

RANDY BUSH: Congratulations, the RIR looked good compared to the most unaccountable untransparent and horrifying organisation in the Internet.

PAUL RENDEK: Thank you. Well, that's a nice position to be in. But, I think that we have to be an example moving forward. And like I said, the perfection isn't there and there is a lot of work to be done with transparency even within our own pieces and accountability. But I think we have the model that can move us in that direction and that is something positive to put in the ICANN sphere because as you well know, and maybe some of the folks here don't deal with it or see it, it is a very big world out there, it's much bigger than what we deal with here in these ‑‑ in our area.

AUDIENCE SPEAKER: Carsten Schiefner. I have a small question possibly about CRISP presentation on page 1, I guess it was, of the draft RIPE community principles when there was a notion that the RIPE NCC or the RIRs in general are about to enter into a contract with ICANN, and I just wonder whether that is a sad fact already or that whether that is the intention? Because it's not ‑‑ at least to my knowledge, it's not crystal clear that it is only ICANN that can fulfil the IANA function in the future. I just wonder whether that was a glitch or whether there is any kind of intention behind it? If there is intention, then possibly you could clarify about that.

DANIEL KARRENBERG: I'm wearing no hat. Of course it's not crystal clear whether that's the case in the long run. But being Daniel and having some experience in this stuff, I would warn against making too many changes at the same time. In fact, if you look at the whole SLA thing, we are happy campers, the reason the folks are doing a good job. There are not that many things that they implement. If you look at the number of global policies that we have, we have three of them. One for IPv4, becoming less and less important; one for IPv6 addresses; and one for AS numbers. All these policies fit on one A4 each roughly. I am just doing for the general consumption. Implementing them is not so difficult. The number of transactions per year you can probably have on you know two hands. They do it well.

So, if you look at it from the purely operational point of view, let's do the political side, i.e., get the contract in our own hands in one step, make sure that the principle that's in there that says the term of the contract will be clear and the way to terminate it will be clear, and then think about maybe why we would give it to someone else. That's my advice and that's, I think, also the current way I hear people thinking.

AUDIENCE SPEAKER: I just think that although we possibly all know that right now it's most likely to be the ICANN fulfilling the IANA function, I just wonder whether that should actively be stated in such a draft principle.

DANIEL KARRENBERG: That's something for this group actually. I think the NCC would definitely like to hear guidance, so, are you saying that we should publicly say keep this more open or should we say we want stability?

AUDIENCE SPEAKER: Both.

DANIEL KARRENBERG: You can't have both.

CARSTEN SCHIEFNER: Well I guess we can have a rather more neutral way of calling this.

DANIEL KARRENBERG: I don't want to Monday applies this. But Carsten, this is not neutral. Inside this room, that would be a neutral formulation. In the room where the politics happen, it will be a statement; you get my drift

CARSTEN SCHIEFNER: Fair enough. Okay. Thanks.

AUDIENCE SPEAKER: Tahar Schaa with currently no head on. I have to perhaps two silly questions. One is: What are the risks of this? So, what I'm missing is somehow a clue about what are all the risks with this transition of this contract? And the second is, do the RIPE NCC have an opinion on this if it is a good thing to transit or is it a too risky thing or what could be the worst where we could end up?

PAUL RENDEK: Actually those are two very good questions.

I'll attempt to answer them. You know, the idea of transitions is nothing new for this community. I think that ever since ICANN was established this community has already discussed the fact that we could probably walk away from some oversight like the NTIA. So this isn't very new. As far as ‑‑ you know, it's very difficult when you ask the question what's RIPE NCC's position on this? I think that from the membership and communities come the guidance of what they want to see there and the RIPE NCC is as is secretary would execute this into any contractual obligations. The risks there? You know, to be honest with you, I think one of the risks at that we would have status quo, right at worst and then we would probably see what kind of reap cushion would say come after that. That's one risk I would identify. Is that really a risk? I think for the last 15 years I haven't heard many people in this room comment about the fact that NTIA is there and it's this big cloud and we don't know what to do with it. You know, what are we actually trying to solve is maybe a question that you want to ask. But what are the risks? I'm hoping that in moving forward, there's a few ways we have looked at this.

One is yes the process will go. We have followed what is necessary to with our obligations with NTIA and the state department and they say right we feel that things are ready to go, let's walk from this. Give these folks the bits of the accountability they need to build and the mechanism they have at the top at looking at their oversight.

That's one. And then there is the second which is a potential risk of we've got status quo. Now, I think for the RIRs I don't think that's necessarily a bad thing. I think we understand that we would continue to operate as we always have, right. There would probably be repercussions on a different level politically outside of maybe the technical community. We would have to deal with those and obviously have to have or play in that field. I think that's its way that I would look it. And interestingly enough I did want to say something. That point came up. We had a round table meeting in Brussels recently that we teamed up with centre, with the ccTLD folks and RIPE NCC and we held kind of a joint round table meeting to walk through this process to Government. The high level Internet group of the European Commission was there, the European Commission folks and other governments from our region and they did say this. They said well, you know, what would be the potential risks? Can we not live with the status quo? And you know, many things that I heard in the room was that, all right, this doesn't seem to be too disastrous. So I think we have to put things into perspective that way. Thank you.

AUDIENCE SPEAKER: Filiz Yilmaz speaking on her own behalf. I think this is an opportunity. I think this is a good time to bring the good RIR principles and I'm a good believer that we have good principles, that has been in application over the years. To those parts of the world and other parts of the Internet community, maybe where these accountability issues are still quite edgy, so we can stet a very good example and create a very influential environment bringing our own principles. So, I think that works on its own. I have no issue with that.

One risk, talking about risks. What I see is, as communities, RIR communities, we are very agile. We have never had the legal words, we never SLAs before in thesen environments, and now we are getting into that sphere where statements are going to be made and they will stick.

So I think in terms of the principles, it will be good to bring, and I see this as an opportunity. I'm sure you guys are thinking of it already, but flexibility and maximum stability that you mentioned, needs to be part of those SLA documents in wording, I really do support that.

And I would really ‑‑ I think one thing is while we are talking about maximum stability, I also don't want to see this status quo and getting stuck, so it is a hard job in that sense, that's the risk we need to think about it well, and as a community, it's not only us, I am glad that the legal team is taking a lead here, because that will be very legally worded. I really hope that whatever we come up with in the next ten years or so, the boat will not be rocked again, that's the other thing, because this needs to continue working. Thank you.

PAUL RENDEK: That's wonderful. Thank you very much Filiz and as somebody who I know spends a lot of time in IG circles or has followed that, we need to have a very firm understanding here that we do not want to jeopardise any of our principles moving forward. We hold true with them. And I'm happy to see that we use a lot of community people to push those out there in those different areas. And I think we are an example there. And you're right, the maximum stability statement, thank you very much for the comments of what you feel needs to go into the SLA. We have noted those down and certainly we will look at those. Ashley.

AUDIENCE SPEAKER: Ashley Heineman NTIA, I just wanted to thank you for letting us have the opportunity to participate or at least sit in and observe these discussions, it's very helpful for NTIA to prepare four selves to understand what the communities are thinking but also as we get closer to reviewing a proposal that ultimately comes in, so thank you for the opportunity to sit in.

Also, I just wanted to make sure it was clear that we're happy to be a resource where we can. We are being very hands‑off with respect to proposal development obviously, but if there is ever any questions with respect to our role or the current contract, I'm happy to be helpful in those circumstances. And just to echo something that Randy Bush said earlier, but it comes to the SLAs, we fully recognise and have pointed to them on numerous occasions but they were solely the purview of the IETF in this particular instance, so I just wanted to make that last clarification. Thanks again. And I'm happy to be of resource whenever appropriate.

PAUL RENDEK: Thank you for being here. I can say that the RIRs, and particularly RIPE NCC, we do enjoy a very positive working relation with the State department and the NTIA and it's great you're here following to see what our process looks like in the mix. So thanks very much for that Ashley.

AUDIENCE SPEAKER: Nicholas from the RIPE NCC. We have a question from a remote participant. It's Sandy Murphy from Parsons. The NTIA announcement asked for proposals that they might consider. The announcement did not promise that they would accept the proposal they received. Has that changed? Is NTIA now committed to accepting the transition proposal? Can they say thanks very much, but no?

PAUL RENDEK: That's a very good question. Ashley, can you please answer that? Sorry, Ashley, sorry.


ASHLEY HEINEMAN: From our perspective we're very committed to this transition process. I think we have made fairly clear what some of the kind of basic requirements that we would need to see in a proposal and what we would not want to see in that proposal. As long as they are within the framework of those guiding principles, we are fully committed to reviewing a proposal with the intention of approving something. I can't say that everything is a guarantee, but our full intention is to go that road.

PAUL RENDEK: Thank you very much, Ashley, if I can can actually add to that. I can say that in the various circles that I have been running around, ICANN meetings or what have you, you can imagine that I am approached by a lot of people saying Rendek, what are you going to do if this thing consistent going where it's supposed to be going? And my reply to that is, we are very committed to a very positive outcome on this. We are working very hard inside the company putting the is resources where it needs to go to come to a positive outcome. So this is the road we're taking. So. Thank you. Jason?

AUDIENCE SPEAKER: Jason Schiller, Google and the ASOAC. I have a question for this community. The LACNIC proposal suggests that the contracting party on our side should be the NRO. The RIPE proposal suggests it should be the RIRs. Is that distinction at all significant; and if so, how does this community feel about one versus the other?

AXEL PAWLIK: Alex for RIPE NCC, and secretary of the NRO currently. The NRO is not incorporated. It doesn't legally exist. It is a vehicle for the requires to work together, that is what we're doing. Any agreement that we would sign would be signed by the RIRs individually or jointly.

PAUL RENDEK: Thank you. Patrik.

PATRIK FELSTROM: I would like to continue on this coordination of the proposals to be actually able to merge into one. I want to point out, regarding these three different communities that we saw Chris describing, the names and numbers and parameters, that one of the findings that we have is that of these three the names is a little bit special, because that is ‑‑ well, I think everyone knows that ‑‑ but anyways, if you look at the contract and where, for example, and where NTIA actually do have some operational participation at all, it is in the actual operations of the names where they are part of the authorisation and sort of acceptance path all changes made and so they are sort of part of that flow which they are not in the case of the numbers and protocol parameters. I just want to point out that to this community, when you ‑‑ when we come closer to, when these protocols, with these different protocols are to be merged, that this community sort of will have to work together with the communities that have slightly different needs.

PAUL RENDEK: That's a very good point, Patrik, and I mean it's no secret that in the discussions that you see when you are walking around on this, that most people are saying, oh well, yeah, we see the IETF, wow, they are very forward‑reaching, and then you have the RIRs, they seem to be moving quite nicely. Oh gosh, what's going on with the names? This is just general comments that you see applying around here. You are right. The naming community has a lot of work to do. They don't traditionally operate or have the same kind of ‑‑ they don't have the luxury of having the same kind of communities that we have in moving forward here the so, yeah, they have some work to do, but we, as the RIRs, we are certainly looking at the different groups that are there to see how we're going to have to work with them to bring this positive proposal forward. Definitely the IETF first hand.

PATRIK FELSTROMl: Let me be very, very explicit. No hats on, just speaking as Patrik, okay. If you look at the audit or SLAs that the protocol parameters have that I see also the RIRs are looking into, they are doing an audit. Let me call it, use that term in a sort of non‑legal sense, sort of every quarter, or every year or whatever the community feels like to see how IANA function has been performing, okay, which means that for each specific individual request that is made, you trust the party that do the request and IANA to be able to work together with each other and take care of the request without any third party intervention or oversight. In the case of names, they do explicitly do an audit at the time of the requests. So they have a third‑party validation of the request and/or the process like we don't have to go into the details of the process itself. So they have a completely different audit and oversight mechanism for the actual sort of management. That was the difference I was thinking of.

PAUL RENDEK: Right. Okay. And I think you will see that, I think you will see that the oversight mechanisms that come out of this are not going to be homogenous, Patrik, and it's great that you pointed that out. And we're going to have to make sure that we understand what that is for for the RIRs. Randy?

RANDY BUSH: I specifically cannot speak for the IETF, but my perception from experience there is that the IETF is quite happy with the IANA's performance for many, many years. I am aware that the RIRs are also, I believe, there were some problems back many years ago, and I think that's all been straightened out. I think both the protocols and the address issues are the IANA has been what it should be, which is bookkeepers for the Internet. Names, there's too much money. There are more lawyers involved in the name side than there are address blocks and protocol numbers put together.

PAUL RENDEK: A very good point, Randy. Actually in the round table that we had recently in Brussels at the beginning of October, we identified what our relationship was with IANA. We also identified to them how many times we actually had formal deliberations with IANA, and the actual three documents that we have, the global documents of what IANA does and they are only about a page long each. And I think we literally floored the governments in this because they had no idea that it was such a simple relationship in that sense. They because ‑‑ they are all busy very much looking at the names space and they are looking at the name space and they come over and look at the RIR space and go, literally, oh my God and then go back to the name space. So I think we were very clear in our ‑‑ in what our relationship was with IANA, and I think that's made the governments very much aware of where we sit within this. Thank you. Heather.

AUDIENCE SPEAKER: Heather Schiller, Google Fibre. I think Randy said and I believe he was referring to ICANN as the most unaccountable and horrible organisation on the Internet, and so my question is: What about any of this process will improve the transparency and governance of ICANN itself? Because that's the part that's concerning to me. I think a lot of people are quite comfortable with, as Randy was saying, the relationship between IETF and the RIRs and the IANA, but it's the level above IANA, that ICANN organisation is so bad.

PAUL RENDEK: Absolutely. Heather, I know you have been to ICANN meetings. We have probably ran around there. I know we have met each other at those meetings before. If you take a look at that we are not entrenched in that ICANN community if you want to call it, because that's maybe the one of the points I'd like to bring up. Our role there, or our visibility and our activity, there seems to be pretty much on the wayside, like we're not the inside the funnel of what's going on inside of ICANN. I think that actually when ICANN was being established, the RIRs consciously made the decision of what its relationship would look like there. We had big discussions at that time, what our relationship would look like. And if you see the accountability bits, yes, we're going to be involved for sure. But what can we add to the accountability space? I think that we're making sure that we can show what our bit would be. I think one of the other pieces that I think we can bring to ICANN's accountability is a sense of community. I think that ICANN community is probably the first step where they probably need to form some kind of community there because there really isn't one, if you dig a little deeper, in my opinion. Not maybe the classic way we would say community in these circles, in the technical community. So, that's a very good point. But, I don't think we will be the leader of the discussions inside of the whole ICANN accountability space. But we better make sure that our gardens are nicely trimmed inside of that space and that's the most important piece for us.

AUDIENCE SPEAKER: I think what Randy was saying is very accurate. I think because of the monetization of domain names, not as much attention is paid to the RIRs because there is a lot of money to be had over there. And then their groups are so isolating, and excluding parts of the community. So, that's very concerning to me and it's not so much, like I'm saying, it's not so much about the RIR part, it's the NTIA transition to the ICANN and concern about the ICANN organisation, and I know that's not necessarily like an RIR specific thing, but for the NTIA folks.

PAUL RENDEK: Heather, that's the reason why you saw the two streams that Athina brought forward and I have to say that from the RIR community, that was pushed very heavily to have those two streams because we felt that if you brought the IANA stewardship transition into the whole ICANN accountability space, you'd derail it, the train would go off the rails. At the end of the ICANN accountability, I would imagine that someone like yourself inside of ICANN would probably look at ICANN and wonder what their community would look like going forward. Once you establish that you would understand where this, these communities, the RIR communities, would fit into that space. Right?

AUDIENCE SPEAKER: I think my concern is I would prefer to see the stability of governance and transparency of governance in ICANN shored up before this happened. Like, I get that we're all in good shape. But that's a mess.

PAUL RENDEK: Sorry, John I will pass the mike. I would I like to answer this if I could.

You know, again, we need to make sure ‑‑ look, ICANN's accountability process, in my personal opinion from what I have seen and how the pace of things move out there, is probably going to be with us for the next two to two and a half years, easy, easy Heather, that's my opinion. We have to get this right by next summer, right? We need to have something here by next summer. So, I have the feeling that ICANN's accountability will far outlive the IANA stewardship transition. And I think we need to concentrate, we need to be very careful, like I said, these are happening in parallel, but we cannot confuse the two issues. So let's get one thing off the track, which would be the stewardship, and in parallel, let's keep looking at ICANN's accountability and what our space is there. Right? So, yes, this is a long road, Heather.

AUDIENCE SPEAKER: Hans Petter Holen speaking with my own hat on. A couple of things. I think it's important to look at what the RIPE NCC is; the RIPE NCC is an organisation that's accountable to its Board. The Board is accountable to its members. On the same time, this construction is accountable to RIPE as an open policy forum. So, we have an open and transparent system. Yes, it can improve in many ways, but let's sort of start with that simple model.

What we want, what I would like to see as a community member, is that the RIPE NCC and the other RIRs enters into a contract with an IANA operators that can do what we need. So actually the IANA operator should be accountable to us, it should be accountable to the global community, to the global Internet. That's sort of my vision when there was a question here, what does this look like in a couple of years? I think that's important. If we enter into a contract with an organisation that's not transparent and open and blah, blah, blah, we need to make sure that our lawyers make that contract watertight for us so that we can change operators in case this doesn't work. Since I care about the Internet and not just the numbers, because in order for my services to work, I also need names, I would love to see that ICANN would become more transparent so that ICANN should not only be accountable to its CEO, the CEO accountable to its Board, but it stops there. So the ICANN Board need to be accountable to its members. It doesn't have any members. That could be us, and the names folks and so on. So we need ‑‑ ICANN needs to establish or do something there.

So then the big question is, can we actually trust an organisation that's not yet open and transparent with our contract or not? Maybe. I like the idea of sort of parting the elephant up in smaller pieces and eat one at a time. That's kind of the big question and one one of the big risks.

PAUL RENDEK: That's a very wonderful statement. Thank you and you have made that clear and Hans Petter what was ‑‑ I love what you said at the end, but at the beginning, you mentioned that we have these bits of accountability, we have the processes there. I can tell you that in all of my deliberations with NTIA and the State department through of all of this they have always been saying, Paul don't make it up, because think about this. I mean, the coin dropped of course for me. No responsible administration is going to release any kind of oversight to something that has not had any longevity, certainly not a government body. This we should all know. This is probably not rocket science for us. So I think we also as a community need to stick to our principles and stay true to ourselves when we're moving forward, because we have these bits that are here, we just need to formulate them. Let's not make it up. We have them.

JOHN CURRAN: President and CEO of ARIN. I'd like to pick up on Hans' comments and Randy's earlier comments. This is ‑‑ I said this in the ARIN meeting a month ago. This is an extremely boring and routine transition and probably the most frightening transition we will ever do, both at the same time. It's boring to the extent that ICANN, the DNS policy body, the RIRs and the IETF are respectively recognised as the policy authorities, and so to some extent we're not changing anything and if ICANN is the IANA operator an we contract for it to be it, the present operator, maybe not the eternal one but the current one, a lot is not changing. What everyone has to realise is the removal, if NTIA transitions its stewardship to the community respectively so that each of us are the policy authority for our respective registries, what that really means is very little, except the fact that it means we are effectively eternally in that role. There is no one who can step in and say the RIRs have done something wrong, or ICANN has done something wrong or the IETF has done something wrong. What this means is what Randy highlighted earlier: Yes, we need to figure out how to contract with IANA, yes, we need to be able to contract and make sure the IANA operator is accountable to us. But we have to spend a lot of time staring at our own accountability to the community as the RIRs and as ICANN and as the IETF. And it is true, compared to ICANN, we look great in a beauty contest, okay. That may not be saying much though. So right now you need to take a moment to look at the RIRs collectively and say, are you comfortable that these organisations are accountable to the community and will remain so for decades to come. That's actually the question I see that's most important, because while nothing is changing, the ability for someone to intervene in this would be going away in a stewardship transition.

PAUL RENDEK: Thank you very much, John. I am actually going to close the mics with the three lovely gentlemen I have here and I'll start with Jim and move down the road.

AUDIENCE SPEAKER: Jim Reid, just speaking for myself. I wanted to pick up a couple of points that Heather made earlier about the ICANN stewardship and accountability and stuff like that. I think it's very important we don't allow ourselves to be sidetracked into that swamp. I think we have to focus solely on what we have to do for the IANA function and keep well away from the rest of that stuff because I think that the ICANN issues are probably intractable and I don't think they are going to be solved any time before the death of the universe.

PAUL RENDEK: Thank you very much Jim. And like I said, the draft charter is out there and it does have these two streams. It's very much identified the difference between ICANN accountability big bucket and the IANA stewardship transition and what the accountability is there. And there will be people from the community that are put on that from the ASO that are appointed by the ASO. They do not even want overlap between the two streams, right. They want to have people focusing on one and people from the community focusing on the other and those that are focusing there need to concentrate on making sure this process goes. Thank you very much Jim.

AUDIENCE SPEAKER: The whole point is the IANA function is fairly clearly understood. The ICANN thing is a different thing entirely.

PAUL RENDEK: Absolutely. Which is why I have given it the longevity and poor Heather was shaking her head.

RANDY BUSH: Sorry to come to the mike yet again, but at least I am terse. I disagree with you, Jim, for two reasons. First of all, to whom are we responsible? And I think we're not just responsible to the people in this room and our immediate community. We're responsible to the users. We're responsible to everybody. Yes, taking on transparency and accountability in ICANN is a real large problem. There's a reason that's a real large problem. This is the last chance to get it solved because you have got fodies kishkies over the fire on the transition. Solve it now. Sorry, I don't like it either. It's a swamp. But it shouldn't be a swamp. There is no reason for it to be a swamp. Buckle up, face it, deal with it. Sorry... it's no fun, thank you for going out there and doing it but stop shirking the task.

RUDIGER VOLK: Randy was asking and making a suggestion about to whom we are responsible, and the discussion was saying, yes, we are transparent and accountable to the community, which, in my understanding, first of all, is, is actually a fairly small stakeholder group and well, being good citizens and good humans of course, we have the good of the world in the mind if we are working nicely, but for mechanisms that are being discussed here, that's kind of out of scope.

The question from me is, the discussion I heard here it sound like we are feeling comfortable about this RIR working with its community, small set, small scope of stakeholders. I wonder whether that scope is actually in the discussion and in the NTIA decision sufficient, looking at what you presented about what the other RIRs are doing, I at least see that the Latin Americans obviously are thinking they have to reach out more. I guess, trying to go there is actually walking into a swamp. So, I personally would feel much more happy if we can stay out of it, but I have the question can we actually do that?

PAUL RENDEK: That is a very good question, Rudiger, and I think that if you can see what's being brought forward by maybe the LACNIC community, the word multi‑stakeholder was in the presentation that you just saw. You probably have noticed that the word multi‑stakeholder was nowhere inside of the documentation or any of the principles brought forward from the RIPE NCC. We have been operating as a community for many years with a very long track record as bottom‑up, open and inclusive, which, in my opinion, is something we have stayed true to and we have been able to brace anything that's been coming towards this community in the past. I don't think we need to go reinventing anything by establishing bits of areas that ‑‑ well as Rudiger has put it, is potentially a swamp and we have no understanding of where that's going to take us. So that is a very good question, and thank you ‑‑ or a very good comment and thank you for that. We will note that.

I need to bring this to a close. I just wanted to thank you very much for actually your discussions here.

I wanted to just close with a few small statements, if I could.

We took this thing onto the road everywhere we went in our regional meetings, our in any deliberations we had with community and membership. I mean, we have even had these discussions out in Kazakhstan, so that far reaching into our community. And the resounding thing that keeps coming back every time we approach our membership and community with this, they keep turning around to me and saying, Paul, how is it go to affect my business and is this going to affect my relationship with you? So, at the end of the day, from all of those pieces, I think what we have actually summarised inside of the RIPE NCC is that we definitely need to stick to our principles and we need to understand what our community and members want from us. And having heard that from all the different pockets of the region, we will be moving forward, we do not want to jeopardise the principles, we want the maximum stability, and we want to give our membership what they want from us and that is what we will continue to do.

So we have still sometime in the RIPE community because we don't make any firm decisions here at a RIPE meeting, we need to take these to the mailing list as well. I'm hoping that people that will look at this transcript or have heard this discussion will pipe up and include their comments on the mailing list so that we have got all that we need to move forward. So thank you everybody for engaging and enjoy your lunch. Thank you.

CHAIR: Thank you very much, Paul, and RIPE NCC. And now it's lunch and I hope to see you at the second Cooperation Working Group at 2 o'clock this afternoon. We will talk about technology and social responsibility. See you then.

LIVE CAPTIONING BY MARY McKEON RMR, CRR, CBC

DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.

WWW.DCR.IE