Archives
PLENARY SESSION ‑ 12 MAY, 2015, AT 4 P.M.:
SPEAKER: We are about to start, please take your seats. Hello, we are announcing the candidates for the upcoming two seats, the Programme Committee seats and I would like to ask them to come up here, Joshua Sala, and Benno and Shane, could you guys come up on stage. Joshua, are you here? So we have three candidates, I would like to ask to you say a bit about yourself.
BENNO OVEREINDER: Well, Benno Overeinder, I have been PC member for the past two years. I really enjoyed working with the team, with other people in the PC, and enjoyed getting the plenary programme organised and getting in contact with the people here in the room. And, well, running for a second time, I want to really contribute for another two years, making this plenary interesting programme and interesting for the community. Thanks.
SHANE KERR: So, I am Shane Kerr, I am also been on the Programme Committee for the past two years with Benno, we were actually elected at the same time. I have enjoyed it very much and I have been very proud of the results we have had, I think the RIPE meetings have been very good. I think I work very well with the rest of the PC and I am committed to doing this in the future if you guys vote for me.
Joshua: I am fairly newcomer to RIPE but I have been a long time participant in various groups in North America and New Zealand and I would like to take take a greater role in the RIPE community and help develop the programme and, there is a ‑‑ it's big shoes to fill, the existing committee has done an excellent job but I would like that opportunity. Thank you.
SPEAKER: Do you guys have any thoughts on what you would continue doing and what would you change, any sort of platform‑specific ideas?
BENNO OVEREINDER: I am now stepping out of my role. We have a very tight schedule and ‑‑ I would like to talk about this. Please, talk to us in the room, we are here for the next two‑and‑a‑half days. We have to get on with the programme. Sorry for ‑‑
CHAIR: The voting is going to be open now. It will end on 5:30 on Thursday, and the results will be announced on Friday. And we are starting our next session. Thank you everyone, thank you.
(Applause)
Our next session is building a secure Internet and we have panelists, we are going to start with the presentation first.
BENNO OVEREINDER: So, a little bit awkward, different role. Just as a regular contributor now. So, for the next 30 minutes, we have a panel ‑‑ thank you ‑‑ a panel on building a more trusted and secure Internet. So a little bit about the logistics. First I will gave very brief introduction, five minutes, so I will not give a decent overview of the different initiatives but the contributors will do that. I will mainly point out the similarities in the initiatives and then we go into questions.
So, what must we trust. So, it's an article posted by Steve Bellovin in the past years security was all about separation between trusted components and not trusted components and that was easy, we had kernel space and user space and it was our trust, there was the separation between trust and untrusted. Systems became more and more distributed and interconnected so this trusted computing base became more and more irrelevant, and we can see similarity in networking, actually, so in the early days we, or actually not me but you or some of you here in the room, they built their first networks in a tight community with close collaboration links and everybody new each other but the Internet grew to a large global infrastructure (knew) and with that the trust base deteriorated and made less sense in that respect. But unfortunately, a lot of our infrastructure, we work with, is still based on the idea of trust between the different players and components of the system. So the question we want to discuss here at this panel is, is there still ‑‑ there is definitely a need to reinforce this trust base in the /KAOUL tour of collective responsibility and is there a way that we can create a trusted networking base.
So, before starting off the discussion with the panelists, I want to give three examples of current initiatives. On building is trusted infrastructure, trusted network. One is the trusted network initiative in the Netherlands and I want to quote the sub title, it's a last draw bridge in case of big DDoS attacks. And you see from the example here or from the picture, website.com is just connected to the Internet and to trusted Internet, and in case of a big DDoS it holds up the drawbridge, disconnecting from the global Internet but still the partner in the trusted network is still connected to website.com.
Similarly ‑‑ sorry, how is this realised? Well, it's realised by having a VLAN with a number of exchanges in the Netherlands, NL IX and AMS‑IX, two of the sponsors of RIPE meeting here. They have a trusted route server and in this way they connected with each other in trusted infrastructure and they have the global routing network, the global routing Internet.
And of course, very important, there are policies. So, there are technical measures you should take before you join, there are organisational, etc., etc.. Mark will definitely go into more details.
Similarly in Czech Republic, there is the Phoenix project. And again, this also is a trusted environment, in case of DDoS and it's also based on VLAN at the ISP. They have also technical and organisational requirements and it's good see they also require IPv6 and DNSSEC. An extra, I guess. I definitely ‑‑ yeah, I appreciate that. And also, there is, of course, who is in and who is out, the reputation. So, that is important.
I can ‑‑ well, it's important, it's self‑governance so independent from the IXP, it's run by the partners. And different from previous initiatives, is the gov IX, the government ex change in Austria. It's not open for any partner, but it's specifically targeted to public administration organisations that provide important services to these public offices. And interesting enough, I want to point out is that they also run their own DNS serves within this infrastructure, from the route delegation to .at and gov.at. So, and jumping slides, interesting also enough is that they run it as a kind of default, so these governments organisations, they run on the these trusted infrastructure by default, that is the preferred path, not if they are under attack.
Finally, I want to mention MANRS, local initiatives, that is has a global perspective on this. And it's not a technology, and rules code of conduct, Andre will tell more about that later on but it's important to note that it sets a low barrier for entrants, so three of many ‑‑ some simple rules you have to obey if you enter this ‑‑ if you join the MANRS effort. I think for the time I will go to the panelists and introduce them very briefly. So J ma lieu from XPM, chief information security officer and Ondrej Filip from cz.nic, a participant or running as one of the members of Phoenix, Mark Howe is responsible or partner in the trusted network initiative in the Netherland, Andrei Robachevsky from the MANRS already presented a number of times and Wilfried Woeber from ‑‑ known for his years and years co‑chair of the Database Working Group. Having introduced very briefly our panelists, I want to go to the first question. So what is the focus on the problem you try to solve as your initiative, and how did you approach the problem, what kind of technical solution did you apply. And I want to ask Wilfried to kick off this question, please.
WILFRIED WOEBER: Thank you. Thank you, Benno. I got the job to start this whole thing going. So the first set of topics would be like what are the common components in these approaches and what are the differences, and on top of these slides that you have seen already, as a fastforward show, sort of what are the key elements or what are these things that we, in our projects, perceive as interesting and of relevance to the wider community. So I think let's start with you.
ONDREJ FILIP: So, I think our project was actually invented or started out of very high DDoS flood in Czech Republic when we found out that the infrastructure is definitely for ready and not just the infrastructure but the more importantly, the technical teams around. So we started to think what can we do in case of next and we thought let's create a group of people that we want to cooperate closer, let's step up some technical for them to defend such attack and develop some community that is able to cooperate much further than before. And that's how the idea of creating and first time it was called secure VLAN appear so we create add special VLAN for you to be able to connect you have to reach a certain threshold and we set up the threshold really very high. We didn't just concentrate on security things but also wanted to have technical, very capable companies so that is why we included stuff like IPv6 and, you know, in rules there is more described what that means. DNSSEC as well and other requirements, for example we require dual connection to the exchange point, so the flow or single port has to be at least double if you exchange to the exchange point. So the threshold is really very high so we are aware of that, probably the most complicated way how to start this thing. We believe that means some value, so all members are really companies that are very technical cable, they run a list authority so that started sort of a huge list of Czech companies trusted by introducer just by this project and we continue on that. So again, technically capable, aware of security issues, admintive ready and in this environment, we know that people that joined this group can share some information, they are trusted people, they know what to do with information and how to deal with that and there is the reputation, so every member of the exchange point needs to wait at least for six months to be able to join this project and they must be recommended by the members and there is a voting procedure. So threshold quite high and we are concentrating on the exchange point. It is not really tight, it's supported by NIC.CZ and in Slovakia, the group itself is governanced so they own rules and they can grow up independently of the exchange point. And we have nine members currently and we hope some new to come.
WILFRIED WOEBER: Let me continue with our situation. The similarities is that it's built around the exchange point technology, although it is not in this particular case local one, like in Vienna, it is a distributed exchange point infrastructure, well, again, using a VLAN technology, and with this particular target group, public administration and their support entities, of course we didn't have the opportunity to look for sort of a very high technical expertise and local knowledge, because some of them actually do that, they do have that in‑house but some of them are using regular ISPs and outsource services so we were focusing on reliability, availability and business continuity, that is also the reason why this infrastructure is used on a day‑to‑day production basis, because we didn't want to go to every other week, like a test drive, is still everything working, so if anything breaks it should become obvious on the spot. This was one thing. The similarity is that there is an admittance procedure so you can't just show up at the door and say, give me a plug. And the thing that's maybe relevant, also, for other environments, trying to achieve a similar goal, you pretty early on recognise the chipping packets Layer 2 or layer 3 is not enough to do business continuity so you have to provide infrastructure, which we did in the form of default DNS tree, as you already pointed out, and the next biggest step to come and it's already in the pipe, is actually trying to collect certificate providers to this infrastructure, because you need to have access to certificate relocation lists and all of their services. And the open issues that we are still having and we are working on is that most of the collected organisations don't have a comprehensive sort of list of applications or dependencies and list of DNS things. So this is something which goes beyond this. So I am passing on the microphone. How how so the trusted network let me tell you where it's coming from and I will look at the similarities with the other projects. More than a year ago there were a lot of big attacks in the Netherlands, even at companies that had scrubbing solutions already and many of those companies did not really trust their current scribbing solution because you never know are those attacks 40 or 80 or 120 gig or God knows what kind of volumes will those attack raise. So many of those companies had the desire to have one more emergency solution to protect in case your normal solution would not work any more. And that was the start of the trusted networking initiative so it's not a new ‑‑ it's an additional last resort solution, just in case you never know, your normal scrubbing doesn't work or many companies are being attacked in the same flow or whatever the reason might be that the normal solution is not working. And then we figured out if we do a solution for that let's keep it cheap and simple. So what is more cheap and simple than to continue based on the peering solutions we have already for 30, 40 50 years in the Internet anyhow. So the solution we designed was a solution where we used a route server not to primarily send the traffic to but only send your traffic to in case of emergencies, or more or less the other way around as with peering. So all the current members will only centre traffic via the trusted routing route server and in that one or two weeks per two or three years that they just need an emergency solution.
So that is the concept. And it's working out already, 13 members and the similarities with the other projects, well, already eight or nine months ago we discovered in Czech they were doing pretty much the same thing so we used their policy to look at and we spent the whole day together with the team to see how can we adapt this policy and do it the same. If it's needs to be different let's do it different. On a global basis people working in routing policy, so our policy were already included the demand that you are aware of the risk project, that you look to do project as well and all the current trusted networking initiative members who are also part of MANRS are being marked on our site and people see the similarities and at the end of the day things come together at one big global project.
AUDIENCE SPEAKER: As an operator these kind of initiatives concern me. Because there is no such thing as temporary when you look at operators building new networks and what this seems to me a lot of these seem like new networks and the first, with all due respect, when it was first introduced to me the trusted ‑‑ it was introduced as national emergency network and I thought, hey, that is a good idea, if it's not national, not only used in emergency, and we are not creating a new network, then it's a good idea. But you know what we really need is we need a long‑term solution that is and scaleable and sustainable, and I believe, in those kinds of initiatives, far more than Zen phobic splinter net or potentially damaging complex routing infrastructures that won't necessarily add anything to what we are really trying to accomplish, which is better hygiene from everyone participating, thank you.
(Applause)
MARK HOWE: Can I comment? So the input was very helpful and we adapted her input so the project is not necessarily a national project, it's an international project but you have to start somewhere so that was the reason why we started nationally but more companies from abroad are welcome as well, which are two of the biggest Internet Exchanges in the world, so potentially we can connect thousands parties already to this solution.
BENNO OVEREINDER: Maybe Andre, kick off the second question.
ANDREI ROBACHEVSKY: Thank you, Benno.
BENNO OVEREINDER: How do we scale this up to global?
ANDREI ROBACHEVSKY: Maybe a few words about MANRS. This is an initiative which is global in scope and in fact it's built on understanding of the property of the global Internet where your own security depends on others actions or inactions and the thing is understanding a traditional approaches where you build a wall and protect this wall, they do not really work. MANRS consists of two parts, end of security that we would like all operators to conform. And the second one is social aspect of the things. Well I mentioned this kind of inter dependency or reciprocity so when you deploy something it's very important to understand you are not alone, that they are a growing group of other operators that do the same. Which is kind of increases your return investment when you do such things. So, MANRS is both the documented defined actions and more detailed than it was shown on the slide so please visit the website. And it also shows the growing list of supporters, people that adhere to these actions and in our understanding, the more we grow and the thing is what I also wanted to mention, that it's also built on some of the elements that I heard in those initiatives that just presented. One of them is this standard of adherence, right, many of the initiatives require their members to deploy certain best practices and certain ‑‑ and another thing is that the local aspect, although the initiative is global, right, I mean, really, I think the peer pressure fact it has this proximity aspect, so local communities, local Internet Exchanges are the best flies promote global baseline. Thank you.
BENNO OVEREINDER: So can you comment on that as a global operator and how ‑‑ you already mentioned that, how do you ‑‑ at a local initiatives should grow to more global initiative.
SPEAKER: We are a signatory to MANRS, I genuinely believe that is the way we need to go and to be fair to Mark, I do think there are some good elements in there so there are MANRS and with the Czech exchange, the requirement to have a cert, to make sure your organisation is ready, you have technically capable people, all good, but Czech ‑‑ Czech and Slovaks I think it's still important to these approaches all need to scale up and there is that temporariness factor that worries me the most, if I could encourage you, what do you require for to actually succeed, for a trusted network initiative to succeed it requires each and every single operator in the Netherlands to be a part of this, because otherwise you can't route user traffic to that website. You need all the operators on board so they can give the connectivity at least 80%, none of those operators are currently here because they share similar concerns, as I do, about these kinds of initiatives. So ‑‑ I am talking about not the peering providers. And to be ‑‑ peering policy means that your peers and a website with all good intent is not peer of KPN.
MARK HOWE: I think we only disagree about time line, because I fully agree with you that the only real final solution is that you approach things on a global scale, including BGP 38 and all those projects so at the end of the day the whole world is safe and the risk for DDos is almost zero. For the next couple of years I would not dire bet on the facts that in the meantime nobody gets hurt, nowhere on this planet by a huge DDoS attack which might be a very important bank or important Tax Office or important, what other kind of critical website. I don't dare to bet on that for the next one or two years.
WILFRIED WOEBER: Just a very brief comment to the sustainability. I am fully on your side, I don't think it's any good to have small island of special treatment of special communities. On the other hand, in our particular environment, we also put the focus on the community building and also on the educational aspect because what we are seeing is that some of those parties are pretty far on the development path but some others who ‑‑ which are forced to join in, they need some /PAFRPerring and some peer support, and whether this is going to sort of be soaked up by a more secure general global Internet within five or ten years, yes, please.
BENNO OVEREINDER: Some final comments.
ONDREJ FILIP: We are in very good situation what you have said, because in Phoenix there is incumbent operator in the country, in Czech Republic ‑‑ the situation in Slovakia is different but in Czech Republic we have very strong position, we have the local /TKPWHRAOG he will ‑‑ C Z which is the major content provider in the country so from that point of view, this system is very viable at least locally so we hope we can grow further and we started to grow in Czech Republic and now ex /TPAOPBD Slovakia and hope to inspire more exchange.
ANDREI ROBACHEVSKY: Just one little comment. I think, yeah, I fully agree with that, temporary aspect is also wore /AOERBGS there is nothing temporary in the Internet. What we seed in the Internet grows and lives its own life, so I think we need to be very conscious and careful when we develop solutions that they are compatible with the properties of the Internet. So I think there is no such notion of national Internet; it's kind of very, you know, close thinking in this respect. But I think the elements that we all showed here, they have long‑term kind of trajectory and certainly should be enhanced.
BENNO OVEREINDER: Thank you. So I want to close ‑‑ well close ‑‑ I want to ask the audience if they have some questions, come up to the mic.
AUDIENCE SPEAKER: Yes. So we are running a little over time, it turns out half an hour for five people to discuss a complex topic is not much. So we will likely run over, I will take responsibility for that. Statement your name and affiliation and try to keep your questions brief and to the point, if there are questions.
BENNO OVEREINDER: No questions. If people are interested, you have ‑‑ you heard all the ingredients here to work towards more trusted Internet. We can organise a real bar BoF afterwards, contact us and keep on going with this discussion. Thank you.
(Applause)
CHAIR: Next up we have another hot topic, the IANA stewardship transition and what are the next steps for the RIPE community. CRISP also, the RIPE CRISP team representatives will give you an overview of this topic.
PAUL RENDEK: We don't have a break between these sessions, they are two very different topics. I am the director of external relations for the RIPE NCC. For the remainder of this session, we are going to be talking about the IANA stewardship transition, we have come a long way from the beginning when this was announced, pretty much a year ago, we have made some great headway and we have got three panelists here today that are going to bring forward to you what is going on, talk about a specific perspectives, Nurani Nimpuno from Netnod is going to give you on overview of where we are in this process, what is happening and what has been done and what the community has given to us and what we expect from the community going forward here. The next up will be Athina, the legal counsel, legal counsel from the RIPE NCC. She is going to actually be touching on the SLAs, is there particular topic inside of the whole process that needs to be sorted out because it will be the contract that we as the RIPE NCC, or we as RIR operators will have with the IANA operator. Which in this case currently is ICANN of of course. And then Andrei Robachevsky who is also a member of the CRISP team will be talking about the way forward, what can we expect, what are we expecting from the community because we do have a ways to go until this process is finished. With this, I will ask Nurani to come up. We would like to make this as interactive as possible, we want your questions and comments. I am proud to see that the RIPE NCC if, we look at the different communities that are involved, are RIPE community here has been pretty active in giving us feedback and we very much appreciate that because it makes it much easier for the CRISP team which some of you may know, Kistelekis of Nurani, Andre and myself from the RIPE region, it makes it easier for to us bring these principles forward.
NURANI NIMPUNO: Thank you. And good afternoon, everyone. I am the RIPE community, one of two RIPE community members on the CRISP team, and I am also the vice‑chair of the CRISP team so the CRISP team is the team that was tasked to represent the numbers community in putting together a proposal on the IANA transition.
I am going to try to keep my presentation fairly short, because it's mostly an overview of the proposal and where we are now, and I think there will be some, we are hoping there will be good discussion at the end so we are hoping to get enough time for that and we really want to, through this session actually, invite your engagement in the process.
So as you all know, early in 2014 the NTIA announced that they intended to transition the stewardship of the IANA functions to the global community. And the IANA coordination group was put together to coordinate input from the whole Internet community, so to speak. And there were three very clear stakeholder groups, operational communities that were identified, the numbers community, this one being one; the protocol parameter community; and then the names community.
So in June 2014, this coordination group came out with an RFP to the three communities to respond to on behalf of their communities. But I should really say that as soon as the announcement happened, all the Internet regional started discussions within their communities on how to proceed with this. At the end of 2014, this consolidated RIR IANA stewardship team, CRISP team, was established to prepare this proposal and submit to the ICG, and there was also global mailing lists put together, the IANA transfer mailing list, which was an open mailing list that anyone could participate in to provide feedback on the drafts and the text provided.
So, at the very end of 2014, a few of us worked very hard to put together text that is we hoped represented the community input that we had put to the community and got feedback on, twice, in order to or in two separate drafts, in order to produce a final response to the ICG.
And I think this is an overview of the process but I think it's also a bit misleading to say this is an overview of the process of the IANA stewardship transition discussions in the numbers community, because, in effect, these ‑‑ the preparation or the foundation for these discussions have happened over a very long time. I think the maturity of the RIR community showed that there were discussions about this common management of the resources, how do we develop good policies to manage these resources, how do we create structures witness the numbers community to handle these functions so even if there weren't discussions about the actual IANA transition, there were discussions about how to handle those common resource. And I think when you look at it, you look at the process at the very end it looks like we had a very simple task to perform, and in some ways I think that's correct but on the other hand, you need to keep in mind that the foundation for that was actually put in place long before the CRISP team was put together.
So, apart from the numbers community, there is obviously the names community and the protocol parameters, also known as the IETF. And the IETF submitted their proposal in January, just like the CRISP team, the numbers community, but the names community very early on indicated that they would not going to be able to meet this deadline of 15th of January. And we will come back to where we are at the moment, but as it stands now, the CWG, which is the names community Working Group, have come out with a second draft for the names community, which they are seeking input on now. But they will produce their final proposal in June.
So what are the components of the numbers community's proposal? Well, to start with, the IANA function stability and reliability was very clearly identified as an important key element. The RIRs and the RIR communities have been happy with ICANN as a provider of the IANA numbering services to the regional Internet registries, and in order to ensure stability and reliability, the proposals says that ICANN will continue as IANA operator. However, it also states there should be provisions in place for an orderly transition in case another operator should be selected at future point in time.
Another element was to replace the role of the NTIA with the RIRs, so the RIRs would enter into a service level agreement with ICANN as the IANA numbering services operator. And there is also an element of a review committee which consists of representatives from the community to provide advice to the RIRs on the performance of the services, and finally there is also an element of Internet intellectual proper right issues such as IANA.org and trademark, that needed to be clarified in the proposal.
So this very pretty chart is an attempt to give an overview of the IANA accountability and in these discussions not so much really in the numbers community but in the wider community there have been a lot of discussions about ICANN accountability and what are the accountability mechanisms in the numbers community. And as you can see, if you look at the current state, the NTIA is one who has contract with ICANN, there is contractual accountability there. ICANN then has IANA is running the IANA numbering operations, and that is an organisational accountability there. So really, the replacement of the NTIA with the five RIRs, shown here, really is a very simple replacement of NTIA but also with the inclusion of the review committee, which provides community advice to the RIRs.
So, throughout the whole process, it was very encouraging to see that there was, despite the very tight time line, despite the quite unfortunate time line over Christmas and new year, there was quite ‑‑ it was very encouraging to see the engagement of the community, and I think in a way, it also showed the maturity of the processes that we have in place; the understanding of what consensus; how to discuss things in a constructive way, there was certainly not agreement on all points from the very outset, but it was very clear what issues reached consensus and what didn't.
So, as soon as it was established that the RIRs were to sign an SLA agreement with ICANN or the IANA operator, there were discussions about what level of detail needed to go in the proposal. And as CRISP community members we certainly felt that we are here to represent the community, I am certainly into the lawyer, and so we also felt that putting for the community to do a group exercise in trying to write a contract between the RIRs and the IANA operator was not ideal, but it was also very clear that the community needed to give the RIRs guidance on what to put in the proposal. So, the agreement was to come up with eleven principles, these are described in the proposal and these ‑‑ these principles were meant to guide the legal text that the RIRs would produce. And as many of you are aware, there is knew draft SLA text published by the RIRs, and Athina will cover that in the next presentation. I am not going to go into any of the details of these but we are very happy to answer questions about them and explain if anything frankly...
So what is the review committee? It was really a mechanism to ensure sustained community involvement, and as the RIRs, as the contractual holders of the agreement with ICANN, they are obviously the ones who will have to manage that legal arrangement. But it was felt that it was important also to have community involvement on reviewing the performance of the IANA, so the review committee is made up of community representatives from all five RIR regions with equal representation, and selected in a bottom‑up manner.
So, this was ‑‑ this is an overview of the feedback received on the global, but as I said, I think in a way it's interesting to see these figures and it's quite encouraging to see the amount of discussions on that list, but keep in mind that a lot of discussions happened long before the CRISP team was put together, long before we had the global list but we also had our regional lists where we gathered input and feedback.
It was also encouraging to see that not only was the opinions on the text, when the actual final proposal was published, there was active endorsement of the proposal, which I think is actually not always that common; I think in this community, wave tendency to speak up when we disagree but when we agree we are quite happy to be quiet so it was quite encouraging to see that active endorsement.
At the last ICANN meeting in Singapore in March, earlier this year, the ICANN Chair, Steve Crocker, also made a statement and said that the ICANN board felt that there was nothing fundamental in the proposals from the number and the protocol parameters communities, that they have a problem with, full stop.
I think, again, for our community, the CRISP team and the community quite quickly felt ‑‑ found a good way of working and developing this proposal, and for us, and I think for the community as well, the expectation was that there should be an entirely transparent process. So that fell quite naturally as we developed the proposal, and it was also important to, we felt that it was important to record each feedback that we received on the proposal, all the comments received on the global list were responded to, and they are also collated and put together in a big spreadsheet that is publically available so anyone could see that the process had been transparent and inclusive. And I think even though we have submitted our proposal now, I think in the discussion we will have later about the next steps, I think that the experience of the RIR community, not only in this process but in the way we operate in general, is that transparency is really key, transparency is our friend and it's also what will help us in the future steps ahead.
Consultation with other operational communities. Well, as I said very early on, it was both the IETF and the numbers community published their proposals in January. We have had discussions with the IETF Chairs. There was a request from the coordination group about potential conflicts between the proposals, which were resolved, and it was found that there weren't any conflicts between the proposals, and the issue of the intellectual property rights were also solved in that the IETF trust went out and said they are willing to host the intellectual property associated with IANA.
So, in the very last few weeks, the names community has published their second draft for ‑‑ on the IANA stewardship transition. We felt as they were developing their proposal, given that the time line has been shifted and we are getting quite close to the end of this process, we found that it was important for us to be proactive in coordinating with the other communities, and not just leave it in the hands of the coordination group to solve everything at the 11th hour so we communicated very early on with the names community Chairs and said, if there are any elements of your proposal that will effect the numbers community, please speak to us, and we also, as they had published the second draft of their proposal we also had a telephone conference with them to try to clarify some of the issues and it's encourage to go see that the Chairs there also see this type of communication will be constructive in the process.
And I will stop there. With that, I will hand over to Athina who will speak about the draft SLA and hopefully, will have a good discussion later on led by Andre.
PAUL RENDEK: Thank you very much. We will have Athina come up and do the SLAs. I would like to keep the question to the end, for the questions but it's probably better for to us give you the whole picture so that then you can ask your questions after that. One thing I wanted to touch from what Nurani has said, we talk about conflicts between the proposals, for those of you who are aren't following that, you have to understand that these proposals, from the three functions of IANA, have to come together into one proposal and be submitted. If there are conflicts in that proposal, 2010 goes to the next part of the pipeline it's going to be trusted back, so it's probably better for us to already be talking to the other constituency, you names folks and the IETF, making sure that we can already spot whatever their conflicts with we can iron out so we can move nicely forward as a larger community. So that is that perspective. Please, Athina, if you can ‑‑ Athina is going to take us to one portion, which is the SLAs, the Service Level Agreements, which is the contract between the RIRs and the IANA operator. Very important point, because if you look from May of last year up until December when we stopped and reached our principles as a community, those principles have been translated into this SLA. And it was very important for us to make sure that we kept to the principles of the community in forming this SLAs, so Athina is going to walk you through where we are standing there.
ATHINA FRAGKOULI: I am legal counsel of RIPE NCC and I am going to talk about the draft Service Level Agreement ‑ SLA. Before I start talking about the SLA, let's remember what were the requirements from the CRISP proposal, what was expected from us to do. It was expected that the RIRs will draft a specific language for the SLA. It was expected that the RIRs will cult their communities, it was expected (consult) that they will be guided by the principles of the CRISP proposal. And that will use ‑‑ will share some of contractual goals and mechanisms of the current NTIA agreement. So based on this requirement, we drafted the SLA, and who is "we"? We are the RIR legal team. It's a group of counsels and advisors from the five RIRs. It is important to highlight that the draft has not been approved by the NRO EC, it has not been reviewed by the CRISP team and it has not been negotiated or shared with ICANN. It's from us to the public, to the community and to all of you, and it is important to highlight the different roles of the different players. So, let's make a distinction of these roles. The RIR's legal team provided the first draft. They have an administrative role, we do not make any decisions, we purely translate the principles of the CRISP proposal into operational clauses and we will explain the processes ‑‑ the processing of the comments we will receive from the community. The NRO EC again did not give an input to the first draft. And they will give a feedback, together with the rest of the community. And they are the ones that will sign the agreement so they will decide on the final text.
ICANN did not give an input to the draft. And they are more than welcome to give feedback together with the rest of the community, transparently. The CRISP team, again, did not give input to the first draft but will coordinate this discussion and will comment with regards to the compliance of the CRISP proposal with the ‑‑ sorry, of the SLA with the CRISP proposal.
So, how was the SLA drafted? The SLA we drafted is meant to be signed as part of the IANA transition. Not before that. As part of it. As requested, it's based on the current NTIA contract and also based on the principles of the CRISP proposal. We include it for your convenience, footnotes next to each article, with a reference to the relevant principles and the relevant NTIA clauses. It also includes some legal important provisions, and let's be more specific. This slide is borrowed from the previous slide, from Nurani. You can see here the principles and the articles in which each of these principles were incorporated.
And next to these articles, of course, there are some provisions that are important for a contract. So there are description of the signing parties, the background, definitions, the joint obligations and right of the RIRs, governing, miscellaneous and signatures.
I would like to highlight here that the SLA is between the RIRs and ICANN. It regulates the IANA numbering service and it outlines the obligations of these two contractual parties to each other. This SLA does not include any obligations of the RIRs to the RIR communities. Therefore, you will not see any mention of the review committee there, will not see any mention of the transfer of trademarks to the IETF trust. You will not see any commitment of the RIRs that will provide access, say, of the registries to the public domain. The SLA cannot be used as vehicle for the implementation of everything that is included in the CRISP proposal; these issues will be dealt with separately with different mechanisms and tools. So draft was published on May 1st. We welcome comments until 14th of June. And our goal is to have a final draft by the ICANN meeting in June.
How you can participate at RIR meetings, and, well, the APNIC meeting and ARIN meeting took place already but we have LACNIC meeting and AfriNIC meeting until beginning of June, reports are available and will be available for each RIR meeting in the discussions regarding the SLA, and in the ‑‑ on the NRO website and of course, you can follow and participate in the discussion in the IANA transfer mailing list. And with that, I give it back to you, Paul.
PAUL RENDEK: Thank you very much. Like I said, I will hold the questions on this so. That is the SLA portion of this. I think if we look at this we can see the important points Athina has raised, fine the SLA is one portion. There are still some things that are left that need to be dealt with separately. Nurani made a point, transparency is our friend. When we look at the other piece that is have to be dealt with, we want to do that in inclusive and transparent way which means we have a bit of work to do with the community moving forward. The SLA is out there and there for the comment and we are hoping and expecting the comment back that it stands true to the principle that is this community has come up W if I can ask Andre to come up, to talk about some of the things that we can expect looking forward and the kind of participation that we are expecting from this community.
ANDREI ROBACHEVSKY: Thank you, Paul. So, interesting question where to from here. I think that is the question probably many of you ask and, well we sometimes ask ourselves. So let's look at the time once again. And of course there is one track, which is ICG preparing the consolidated proposal so they are collating input from these operational communities and delivering consolidated proposal. On its way they are identifying possible conflicts and overlaps and approaching respective communities to sort this out. That happened already between the numbers proposal and the parameters proposal was successfully resolved.
There are also two elements which can be seen as implementation of CRISP proposal, definition of the review committee. I will talk about this in more detail later. And wave tentative deadline which is ICANN meeting in (we have a) average ineven in in June.
So, what are the challenges? First challenge is time. Although this project seems to have little deadlines, there is some time frames. First of all, this NTIA contract expires in September and although they have said this is into the real deadline, I think we understand the implications of this date. So the ‑‑ if you look at the CWG plans and this is the group working on names proposals, they are planning to submit proposal on 25th of June but after that the ICG will require some time to identify possible conflicts and consolidate and prepare one single proposal and NTIA will require sometime to review the proposal as well.
So, so deliverables as far as numbers community is concerned, so deliverables for the numbers community is the proposal itself, which is done, I think, we delivered this time on 15th of January (on time) with great help from this community and support. There are also other pieces, final text on the IANA Service Level Agreement needs to be agreed and formation of a community based review committee needs to be sorted out. There is also one I think that NTIA recently asked to get updated on the time line and provide comments so they can figure out better about the extension, the possible extension of the contract expires on 30th of September. And these comments are due in June, end of June.
Well, there are also other IANA communities, I mentioned IETF but the names community came with a proposal in April which is now open for comment and we are reviewing this proposal might have implications for our proposal, right? How they all feeds together, that is very important because there will be only one proposal. Of course, they are facing different issues. They are probably more complexity, if our compare our time line with the names community is you understand the difference complexities here. Well, the draft suggest a new entity which is called post transition P T I which is legally separate and wholly owned by ICANN, and of course further discussion is needed how that feeds in with the numbers proposal. For instance, there is some ambiguity with regards to what elements of this new entity, the P T I actually relate to specifically to name services and which of them cover all three IANA functions. So that is an important discussion to have.
Then there is also ICANN and NTIA. Well, negotiations SLA has to be agreed with ICANN, right. There are two parties to this SLA, and there is some speculations about what is the desired outcome for ICANN, what is desired outcome for our community. There are also political questions on the United States of America landscape. There is all speculations, fear, uncertainty and doubt, which are not the good guiding tool for our discussion, I think. But we have good guiding principles here. One of them, as I think we all committed to the success of this transition, I think that is very important. Transparency was mentioned many times here and that is extremely important, I think indeed it's our help, our friend and we need to be as transparent as possible. And last but not least, and probably one of the most important, that we have already principles agreed by this community that we shouldn't compromise on. I think as soon as all three things are in place and we adhere to them, they are good anchors that will ensure successful and smooth transition.
PAUL RENDEK: Thank you very much. So as you can see, Andre has given us an overview of some of the issues that we have moving forward, some of the things that we have to do and some of the things that we don't want to compromise on. So with that, actually, I would like to open up the floor now and have any questions or comments from any of you here, please.
INGRID WIJTE: I have got a question on chat from Daniel Karrenberg, who says I wonder why we are bothering the community with legal language at this level, I have a question for the room and the panel. Should RIPE not stop at discussing the principles as we usually do and leave the em preliminaryitation and the legal language to the RIPE NCC. Of course the SLA should be public but do we need to discuss it in this room?
PAUL RENDEK: That is very good point. Does anyone from the panel want to pick up that.
ANDREI ROBACHEVSKY: I personally I agree with Daniel. I think what we are talking about is we need to ensure that SLA ‑‑ well, just one step back. I think when CRISP team worked on the proposal this were exactly the position CRISP team has taken. We are not legal experts and legalities of those agreements are better left to the professionals and that is what we did, produced the draft, did a good job. We need to ensure that this draft SLA is conform ant to the principles of CRISP proposal.
PAUL RENDEK: Yes. Thank you. Thank you very much. The next person up was Hans Petter Holen.
HANS PETTER HOLEN: Chair of RIPE. I would like to thank the CRISP team for the tremendous work you have put into this. It's really impressive to see what you were able to pull off over Christmas and what you are still able to pull off in pulling this through. So a couple of comments. I think the process you are doing now with producing the SLA and posting it for public comment, whether it's a good idea or not to let us comment on it, but I think that the openness and transparency in this is very good and I really like the idea of also asking ICANN to put their comments in public. I think that is really put the strength in the negotiations back to the open bottom‑up community rather than behind closed door in the cooperations. The idea ‑‑ the point about the review committee, I think that is a great idea anyway. I think we should establish that more or less independent on this process because it would be good to have a small entity that would review the IANA performance however we end up, and get that going. Because there are some reports out there and it would be very interesting to see an analysis of what is in those reports and put it together. And then I have a comment towards this thing comes up, the P T I, and I think that the RIRs are our legal experts who do a risk assessment on whether to do and contract with ICANN are a wholly owned subsidiary because to me it seems when I in my corporate world wants to reduce risk and make it easier to limit my expose use, I put it in a subsidiary, if ICANN wants to ex reduce their ‑‑ may not have been thought entirely through. So thank you.
PAUL RENDEK: Thank you very much for those comments. As far as the review committee, I think it's very important that when we look at this as well, we have had a push inside the RIRs to make sure that we actual lie identify and outline the model that review committee. I think it's important that we have that established because one I think that we probably wouldn't want to have is any cross wires of seeing other kind of review committees from maybe other areas being brought forward as maybe the model to use. I think that this community needs to be responsible for how it wants to have its review committee formed, have that model put forward and stick to those guns. But thank you very much for that. If I can come back up to the front.
AUDIENCE SPEAKER: Milton Mueller, also here as a member of the ARIN advisory committee and I am speaking to you mainly as an active participant in the names cross community Working Group, to talk about some of the coordination issues, although I am also a member of the ICG, I am definitely not speaking for the ICG, but I am in that capacity very aware of the coordination issues as well.
So, the main thing I want to say, I think one of you said there was some ambiguity about the P T I, whether it included the full scope of IANA functions or only the naming functions. I don't think there is any ambiguity. I think it's ‑‑ whether it was stated clearly or not in the proposal, it is the intent of the names community to propose that the entire IANA, all three of the functions be moved into the separate legal affiliate and it doesn't make any sense to do anything else. And in that capacity, Ied to address the issue that Hans Petter raised which was who do you contract with and I think there was a letter that came from the NRO today which suggested that maybe you should contract with ICANN as opposed to PTI, and now again speaking totally as an individual in terms of how I understand where we are trying to go, I think you want to contract with PTI, and I think for the numbers people, given the two requests a month you make of IANA that this is not a very risky proposition, and that contracting with ICANN on the other hand, sort of muddies the model we are trying to create which is to have a clear separation between the policy making entities and the implementation through IANA so I would hope that the NRO would reconsider what it's recommending here and try to go along with the model. And of course, the problem here is that IANA functions are all bundled up in a naming policy environment and we are trying to get it out and so there is a clean separation.
PAUL RENDEK: Thank you very much for that and I would love to hear some other comments on that. I would like to ‑‑
ANDREI ROBACHEVSKY: Just one clarification about the ambiguity. I think I wasn't very clear, I think the PTI itself is non‑ambiguous but some of the elements of the whole model, it's not very clear where the customer sending committee for instance or the board ‑ dish mean cover the whole three functions on the names.
PAUL RENDEK: And where we would fit into those and I think the community needs to very much understand that and that discussion still needs to be had. Thank you for pointing that out, we are not ambiguous about what is being brought forward, I think we understood ‑‑ immediate to understand our footing.
MARIA HALL: Thank you very much. Member of the RIPE NCC Executive Board but also CEO for the Swedish university network. I would like to say thank you very much for the presentation, you managed to cover really complex area in a fairly short amount of time. But also I would like to agree with Hans Petter that did you a huge amount of work, during Christmas, before Christmas and right now. Thank you very much for doing that. Because I know it's a complex area and you tried to cover it as good as you did, thank you for that again. But what I would like to elaborate on a little bit or actually hear if you would be able to, and I am sure you have, what are the risks, actually, that you see, because I saw the PowerPoint slide you had Nurani was before and after, that looked neat and nice, but I also know we have some problem with time lines and synchronization with other groups and so on, so if you have time to elaborate a little bit on the risks, if you don't happen to end up in this after nice picture that you said, and also it's a little bit complex for all of us to follow because there is a lot of groups with three or four‑letter acronyms, so ‑‑ anyway, apparently ‑‑
PAUL RENDEK: That is fantastic question, I am going to ask somebody from the panel to answer this, because transparency is our friend and time is not our friend and I would really like somebody from the panel to take this up.
NURANI NIMPUNO: OK. I guess it depends if your question is about what are the risks within the numbers community or what are the risks in the whole process. Trying to address, I think if we start with the numbers community, I think the proposal is very simple one with a very simple relationship, so I don't think that we see any major risks with that. It doesn't mean that it's a perfect model or that we can't continue to improve our structures. But I think the risk is fairly low there. Time is certainly, as Andre said, is a challenge, don't call it a risk we can call it a challenge. I would like to say that, so, together with the Azumi or Catani, the Chair of CRISP, we had a conference call with the CWG, that is the names community Chairs, it was an informal first initial attempt to contact them, to just to try to better understand the proposal. It was very encouraging to hear that first of all, they see that this type of coordination is a positive one and that it's good to coordinate before they submit their final proposal. We don't know what the final proposal from the names community will be, right? So we also don't know if there are potential conflicts in there with the numbers community. What was encouraging to hear, though, was that they stated quite clearly that when they crafted the names community proposal, they did that conscious of the other proposals on the table. So they have really attempted to minimise any potential conflicts.
What I see as a challenge is that because a lot of elements are still not in place, it is very hard for us now to judge will there be things that affect the numbers community. And I think, as Andre also pointed out, there is a lot of speculation floating around, a lot of fud and hearsay about what various parties involved in this may or may not accept. And I think ‑‑ I think Andre put it very eloquently, that is not ‑‑ that is not very good principle of guidance for us. I think what we can say is that we will stick to the principles that the community has provided us, and that we will not start compromising or trying to change the numbers proposal to fit some potential model that we think we might see half year down the line.
PAUL RENDEK: Thanks. I wanted to sprinkle some more risks out there for you, maybe a little bit more contentious. The time issue, we all know that in the new year, the US elections start. Because the names people were late, OK, they were late and Nurani was very sweet in saying OK, we had a great meeting with the CWG Chairs, which I know that her and Azumi did did have that. I think there was some pressure being put on to our names folk to make sure they don't scuttle this whole deal, we put our proposal and we did it on time. It was not easy. True, their area is probably a lot more complex and took them a lot more to get their bit started but they have put us six months behind schedule. With that you have to understand the, the next bits along the time chain also shift, some six months. So, if this thing was to work, we would probably seeing things happening somewhere along the end of the year. Now this proposal needs to be coordinated and submitted and it needs to be reviewed, right, by the US authorities, by the NTIA and the like, on that side, by the US administration. 2010 gets there it needs some time for that F it gets there too late, and they start and they shut down all of their processes inside the States because they go into the election period, this thing will be thrown out the window, in my opinion, and I don't think this will come back on the table again so quickly so this is one big aspect of the time issue that we have got going. The second is let's take a look of this, blow it out the window, the whole thing is done, we spent our time on it, a bit wasted, tried it not happening. Is this going to affect the bottom line of your business here in the RIPE NCC service region for those RIPE NCC members operating here? Probably not. So most of your are probably saying I don't really care in this. What it does do, it may not affect your bottom line but there are political ramifications that will come through if this doesn't, somehow, work or something doesn't happen here, that we will all feel, I think, as operators in particular countries. I think that you will probably see a lot of countries that aren't supporting the bottom‑up open and inclusive model of working which you all hold very close to your hearts, also be something that is put on the table to say this model doesn't work because these people couldn't get their stuff together to make this happen and we are going to have to take this into another discussion. And this will probably happen in something called RISes and we will talk about this tomorrow in the Cooperation Working Group and it will be discussed further I think on Friday as well, we have separated this and I will explain that. If it happens and they bring this whole multi‑stakeholder issue up and whether or not they want to operate in this way, I am talking governments and regulators and the like, we have another problem and this train is approaching us so we have got a few other little risks that happen along with this and I just wanted to put that out there. I think being diligent and putting pressure on the names people to step up and make sure they can get their stuff organised is very important. The last bit, if you look at their proposal brought forward, sure the, RIRs we have gone through their proposal and seen are there any conflicts, let's try to see them now. We don't really see any side of the conflicts inside of the names proposals so we can confident that this can move forward nicely. I wanted to throw those out for you.
NURANI NIMPUNO: Can I add one very quick comment. I think ‑‑ I think that the principles, sticking to our principles and keeping this process transparent will be sort of a good foundation to stand on. I would like to add another element and that is the external communication. I think a lot of us who have been part of this community for a long time, we take these principles for granted and we assume that everyone knows about the RIR communities being bottom up, include circumstances of transparent, etc. And at the end of this process, there will have to be an acceptance of the proposals and in order to facilitate that, I think we could also do more in terms of explaining not only the proposal but explaining how the numbers community works, and that will instill trust and confidence in the process.
PAUL RENDEK: We have got ten minutes.
JIM REID: Thank you very much. Speaking for myself. First of all, I would like to say, my congratulations and thanks to all of the CRISP team, they did an excellent job in a very short space of time and I think we are very should all be very grateful to them for that. It was also what Paul was saying a second bag getting our act together. I happen to be in a meeting early in this year where the discussion amongst government regulators was these Internet people are not going to get their act together and get something submitted in time. And I was rather pleased to be able to say in actual fact, guys in the RIR community have got the proposal just about ready and it is going to be in on time. That really surprised a lot of people. So I am very grateful for that and if that has not been recognised before I think you have to take great credit for doing that.
I would like to move on to the question of risk and one thing that is not quite clear is this nature of this SLA and there was a bit of discussion about that on the transfer list and about jurisdictions and all this kind of stuff so it's a little bit unclear to me and maybe to others, is if and when we get to the point where this SLA is signed, we are talking about who is going to sign it on the ICANN side but who is going to sign it on the RIR side, will it be the NRO, or each RIR individually or collectively, how is that going to be handled? I know from my previous time on the board a few years ago there was some great deal of difficulty trying to get coordinate with one voice about what they are going to do about their contribution to the IANA function at that time so I wonder if things have moved on since then and if what we are going to do with that once we get to the point where the SLA needs to be signed.
PAUL RENDEK: I can answer that, but perhaps you can answer that, you are right by the microphone, on behalf of the RIRs.
AXEL PAWLIK: RIPE NCC and the NRO executive council. The SLA would be signed by all of the RIRs individually on the one sheet of paper. We have done that before with the NRO and with you as well. That works.
PAUL RENDEK: Actually I have to give this to Samuel.
Samuel Weiler: Speaking for myself. I want to echo the thanks from Maria and from Jim. I appreciate the faithfulness with which you all are representing the values and interests of this community. I want to jump to the IETF for a moment. As you may be aware the IETF has an ongoing SLA with the IANA. That they review every year. And a couple of weeks ago the IETF leadership announced to the IETF community that in this year's negotiations they had a little bit of a roadblock, there were some terms that they were trying to get acknowledged around ‑‑ one was around the possibility that IANA might not always be at ICANN. And some set of these terms, I don't know exactly which set, caused some push back from ICANN, they said they could not accept the terms of the proposed agreement. What I am wondering is, have you heard any such similar push back in the RIR community and do you anticipate the road blocks from such in this process?
AXEL PAWLIK: Thank you, Paul. That is the main point here. We have the SLA out and the NRO EC has not formally commented on that. We need to review it in full and comment on this. This is one of the things I wanted to ask for feedback on. We have had some feedback in terms of ICANN as you said. I have not heard anything from the RIRs communities and my understanding personally, my understanding on termination clauses is that my authority, this community, needs a termination clause at least for failure of operations in IANA. That is one thing that I hear very, very clearly. We have, in the SLA text, and I agree with Daniel we have not the termination clause for renewal, so every so many years renew with IANA possibly at ICANN, and maybe renegotiate and I would appreciate any feedback from all of the RIRs communities on what we are supposed to do there. In the meantime we would review the SLA also with regard to jurisdiction and the like and comment on that. And I think that is more or less what I would say.
Probably with the first transition IANA contract with ICANN directly or with the PTI, as far as we are concerned we would ‑‑ this draft text is done possibly ICANN would assign the contract to the PTI if that ever came to be. We don't know that entity yet. I have asked the ICANN board to publically comment on the IANA transfer mailing list as well.
PAUL RENDEK: We need to have our facts straight before we commit to something.
AUDIENCE SPEAKER: I didn't quite hear the clear answer that I wanted.
PAUL RENDEK: Let these folks... be as fast as you can Patrik .
PATRIK FALTSTROM: I am co‑chair of the ICG which is trying to get the whole thing together. So I also would like to thank you for doing your work in time. A couple of information points that hopefully answers a couple of questions. First of all, regarding the time line you bring up really issue, Paul, and as some people in the room might know, I have, as the other co‑chairs of the ICG and also the accountability across community Working Group, we got question from ‑‑ regarding the time line and what time line they are using in ICG. What we are now doing is we are moving it to phase where we are updating our time line to be able to do that we have requested the ICG members to, within their communities, look at how much time it would take to actually not only be ready with their proposal, which of course two of three communities are ready with, but also to implement them. So one of the information points that we need to be able to update our time line is to know what kind of guess, for example your community believe it will take to implement what you are coming up with because we need that for our time line.
That is the first thing.
The second thing regarding participation, we have also seen these discussions and words about ICANN negotiating with various entities. We, yesterday, released a statement where we quite strongly encouraged everyone participating to participate in whatever processes the operation communities have defined themselves, and not start sort of side discussion in a non‑transparent manner. ICANN just informed that what we released yesterday, we just ten minutes ago, we also sent that information directly explicitly to Steve Crocker as the Chair of ICANN board for a clarification of ICANN internal policies on the participation. So that is something that ‑‑ and regarding those negotiations on SLA, I encourage everyone to not mix up negotiations on existing SLAs and agreements that might exist or have to exist until the transition happens to whatever the operational communities have defined. Those are two different things.
PAUL RENDEK: Very smart.
AUDIENCE SPEAKER: Azzumi: First of all, putting on the hat of the CRISP team chair I really want to thank the RIPE community for all the contributions that you have made on developing our proposal and reaching consensus. What is really helpful to have your implicit support for the proposal and actually, we have completed submitted the proposal but we are still continuing this phase that we have to work on the implementation and we are asking for your consultation and feedback on the implementation of the SLA and likely to come up with the plan on the review committee. So, it would be really helpful if you could continue to watch the process and if you feel that what is being proposed makes sense, then if you could positively explicitly express yourself, that would be really helpful. And on the point that Nurani has made about communication, I think we really want to advertise to other communities that we have support, not just from the ‑‑ on the proposal, but we are actually like being very, very consistent on what we agree on implementation on the slides, the importance of transparency and consistency with the proposal. This has been agreed in APNIC meeting that happened in March, and ARIN, we are really building on so each of the RIR communities agreeing on the principles to ‑‑ for implementation. So, once we come up with implementation plan, it's important we communicate to the outside. We have built on the implementation based on the basic concept that has been discussed within the communities, not just on the proposal but the implementation aspect so that might be something we want to communicate. And regarding the possible risks, we want to, of course, watch on any impact on the names proposal but we also want to make sure that we make ‑‑ come up with implementation in time on the targeted goal for other numbers proposal so we really have to, industrial a bit of work to do within our community.
And lastly on a point about the names proposal, we are actually planning to do analysis as the CRISP team on how it could impact from the numbers community and happy to share our analysis with the ‑‑ on the global mailing list and it's important that anything that is not clear and vague on the names proposal, we want to be proactive and say this is the direction that we want as the numbers community so that we can make a good collaboration with the names and integrate the whole proposal with the three communities. So thank you, once again, to the RIPE community and hope we can keep the engagement.
PAUL RENDEK: You are brilliant, thank you. I am going to wrap this up if I could. There was some great points brought up there. I wanted to touch on Samuel's point a bit. Sure, we have some principles there son what termination means to this community. I think when you turn that into a contract, and you bring the legal folks in and you bring RIR operators in there, they need to translate into some ‑‑ into that something that can be digestible and signed between two parties without actually deviating from the principles that the community have set. This is the balance that we are looking for. I hope that answer Samuel's question and if it doesn't I bring you to bring it to the IANA transfer list. There are a few pieces left for us still to discuss, so we are looking for the community input here. Lastly, Patrik Falstrom brought forward that the ‑‑ publishing their new time line. We are going to work, we are committed here, to make sure we take a look at the time line and see what we need to do with our community to get our work done and we will be communicating that with you and urging you to participate so we can finish this in a timely process as a community.
I want to thank our panelists, it's fantastic to work with these guys. I want to say there is somebody else that isn't on the stage and that is ‑‑ Athina is not part of the CRISP team but there is a lot of legalities in here in here. Chris Buckridge that works so hard together with us so we are a great team and we enjoy working together and it has been a joy to work with you folks so thank you for that. But lastly, I think this community owes a real special thank you to Azzumi Nockatami who was just at the microphone.
(Applause)
She is a fire cracker, I am telling you and she has been a fabulous Chair for us. She has been a wonderful ambassador for the numbers community out there, to the other folks, and she is guided us very nicely through this process and we are on time and we have done it in a lot of harmony and we owe you a big thanks for that. On top that have, both Azzumi and Athina are in the cross community Working Group inside of ICANN deals with ICANN accountability in general and also ICANN accountability with regard to the transition. So these two have got rale lot of their plates that keeps them up at funny hours working through this, and they work very diligently representing you and we look forward to all your comments on the IANA transfer list with this. Thank you.
CHAIR: So that brings us to the end of the general plenary for today. We still have some BoFs at 6:00 and I would like to remind you, if you have not voted yet, please vote. As soon as you log into the RIPE website there is a drop ‑‑ drop‑down menu programme and then a Programme Committee and then elections ‑‑ election forum. That is all you need to do. I would like to announce one more thing, at 6:00 there is going to be an IETF DNS op meeting, if you want to join that it's going to be in the Mereman room, it's actually remote participation. Mereman room at 6 p.m. All right. Thank you.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES RPR
DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.
WWW.DCR.IE
