1 conference.apnic.net/38/program/IANA Stewardship Transition DISCLAIMER: Due to the difficulties capturing a live speaker's words, it is possible this transcript may contain errors and mistranslations. APNIC and Media Scriptz accepts no liability for any event or action resulting from the transcripts. >>Tony Smith: >>Sunny Chendi (APNIC): Good morning, all. Please take your seats, we will begin the session. We are already running a little bit late. This is about the consultation session on IANA's stewardship transition, and we have Masato Yamanishi as the moderator of the session. I invite Masato to the stage to begin the consultation. I like to invite our APNIC Chair, Maemura Akinori, to introduce the consultation session and begin with the proceedings. >>Maemura Akinori: Thank you very much, everyone. My name is Maemura Akinori, the chairman of the Executive Council of APNIC. Here we are gathering for the discussion of the IANA stewardship transition, and then 2 the IP address community asked by the IANA stewardship transition Coordination Group, ICG, to develop the IP address community's perspective on IANA's stewardship transition. I will have the -- today, in this session, we will have Masato Yamanishi, who has been serving as the Chair of the Policy SIG -- Co-Chair of the Policy SIG, he is from the community and he is very good at moderating the discussion. Then to have the discussion fully of the community, we asked him to serve as the moderator for the session, for the community to discuss. Then we will have Paul Wilson, our Director General, and also a member of the ICG to explain the facts and the background for this IANA stewardship transition. Paul, please come up. Then we will have some explanation. Myself, I will follow Paul Wilson's explanation, to explain the proposal, the proposal which has been shared with you through the APNIC blogs for two or three weeks -- two weeks. Then to explain what the proposal is, which will be the basis of the consultation of you. Paul, you will have the floor. >>Paul Wilson: Thank you. Thank you, Akinori, good morning, everyone. This process has got quite a lot of background to 3 it. There is quite a lot of assumed knowledge that some of you may have or not have in this room, so I would like to give a few points about the background. It won't be completely comprehensive, because I think many of us do know where we are these days, but I want to full in gaps. Of course, during the discussion, if anything is not clear, let's come back to these slides or discuss any questions that you might have. Let me start with the background. I need a training lesson in how to use this thing, I'm afraid. It's a little slow. Ah, the keyboard! Apologies. This process is about IANA. IANA is the Internet Assigned Numbers Authority and it has always operated as a sort of office coordinating these sets of recommend industries that are required for the Internet operation. IANA has always operated more or less under US Government stewardship over the decades since the beginning. In the early years there were a series of changes that were made in terms of who was operating IANA and what the arrangements were. We are not talking about the early history here, we are talking about the history that started in 1999, because after a lot of deliberation about how IANA operates and under whose control, the US Government 4 established ICANN and its aim at the time was, in brief, to privatize the stewardship of IANA. That's what ICANN was actually designed to do from the start. The word "privatize" was used at the time, it predates this idea of a multistakeholder model but in fact that's the approach that ICANN took, because ICANN involved the technical communities, the names and the numbers and the protocols, but it also involved governments and involved what they called the at large membership, the Internet users at large. So ICANN did actually implement a multistakeholder model, because those groups are all different stakeholder groups. It did that from the start. It operated since then, since 1999, with this expectation that it would ultimately take full stewardship of IANA. But that's only become a reality or a possibility recently because through that entire period, through the last 15 years, ICANN has maintained a contract with the US Government to operate IANA. That contract has been going for 15 years, it's been renewed and modified a few times, but finally, in March of this year, the US Government announced that they were prepared to transfer the stewardship of IANA to the Internet Community, basically to allow the contract with ICANN to come to an end and to allow IANA to operate, 5 I suppose, independently under the stewardship of the community in general. One point about this is that the timing may have been a bit of a surprise but the fact of that announcement was no surprise. It's in fact what we have been waiting for, expecting, it's what we've been calling forks actually, for much of the last 15 years. Just put very simply, ICANN is illustrated here on the left and the US Government on the right, there's a contract between them, for the operation of IANA within ICANN, so ICANN is effectively contracted to carry out these functions. The dotted line indicates something that is quite important, that doesn't affect us directly and that's the fact that the US Government, the only operational step or process that they are involved with at all is in technically approving the root zone updates that happen to the DNS root zone. IANA, as I mentioned, is a collection of registries. There are many hundreds of registries within IANA and they are grouped under three different general communities of interest. In the numbers space we have essentially three registries we care about, for IPv4, IPv6 and autonomous system numbers. In the protocol parameters area, there are hundreds of registries for 6 different protocols for the parameters for different protocols and they sit with under the stewardship, I suppose, or with accountability to the IETF. The third part is the names side, which actually really has one registry of interest, which is the root zone registry, and it sort of almost uniquely corresponds with this thing called the root zone file. That is in red because it is a kind of hot issue. The root zone file is directly part of the DNS infrastructure. If it goes away then things get immediately shaky, whereas, of course, other registries, being just list, can sort of go away and the Internet keeps operating. If you want to know why names are a problem, or a challenge -- I'll correct myself -- then that's part of it. The point about this diagram is the registries operate independently, and in fact the fact that they are all in the one office of IANA is a kind of historical thing. They could be operated differently or operated in different organizations, but historically and for administrative convenience they are all in the one place. The RIRs have been quite happy with that situation and have stated that we are quite happy with the fact that IANA has this overarching responsibility 7 for all of those registries. The point is that the three, what we call operational communities -- names, numbers and protocol parameters -- are three separate communities with an interest in separate groups of registries. This brings us to why the Internet, the IANA transition stewardship Coordination Group has been happy to kind of refer the responsibility for planning to each of those three communities. More of that in a minute. One thing that's important for us to understand here is that this is not about the policy process, it's about the implementation and the arrangements for IANA itself. On the left-hand side of the diagram we have the RIRs, the ASO, the PDPs, the fact that very cleanly the ASO channels policies into ICANN for implementation by IANA -- that's a very clean, successful model. That left-hand side of the diagram here is not in question in this current discussion. Now, some more background. There is a useful page on the NRO website which lists all of the different public statements and communications that the RIRs have made through the NRO in relation to these matters. I am putting this up here because, again, we have been expecting this transition for quite a long time. The RIRs, through our processes have made a whole set of 8 statements which talk about the way we have imagined it running, so again this is not exactly new work, this is something we've been thinking about and talking about -- and you would have -- some of you will have definitely seen many of these statements we have made. We have made submissions to the US Government about the operations of ICANN and IANA, we have had a public exchange of letters with ICANN that is about our mutual recognition relationship. We have made submissions to ICANN, we published something called the Montevideo statement just last year, which was also about the same topic. If you would like to look at the specifics of the statements made, as I say, there's a long history there. The current situation, as I've said, the US Government announced in March that it was prepared to transition, that is to allow the IANA contract to come to an end and to transition that stewardship responsibility to the Internet Community. It asked ICANN to convene a process for creating the plan and ICANN did that through a consultation in April and May, and of course the NRO contributed to that consultation process. In June, ICANN announced the creation of this thing, the ICG, and that's the group of ICANN community 9 representatives which is tasked with producing this transition plan. That's the plan that's implemented when the IANA contract expires in 2015. So that's underway now. On 9 September we released an RFP. As I alluded to before, the request for proposals goes to each of the three operational communities to actually specify their expectations for how the IANA arrangements will be conducted after 2015. It's also a completely open process, so it's available for anyone to read, to comment on, to respond, and the ICG will be doing its best to take everything into account and to produce a final plan which will go to the US Government by about June next year, so that they can make their decisions by September. That's some background. As I say, I'm sorry if some of you know this well already. If any of it's not clear, we can come back to this during the discussion. But it's the background to the proposal that Akinori is going to talk about now. Thank you. >>Maemura Akinori: I will continue with some explanation. If you have any questions in Paul's part and my part, then please don't hesitate, but feel free to go in front of the microphone to make a question, and then we will 10 come up again to answer your question. I will explain the draft proposal. RIRs consultation process: the RIRs part of the proposal is asked to consider to the RIRs, then the RIRs, beginning with the APNIC Conference here today, all RIRs will have their own meetings, from September to November timeframe. Then these autumn RIR meetings series, each RIR will consider their own position for the IANA stewardship transition, ending with AfriNIC at the end of November. Then all RIRs will have such a process and then NRO, the Number Resource Organization, as the collective RIRs, will welcome and consolidate the regional consultations. Then ICG, the Coordination Group, already submitted -- called for proposals with a deadline of the submission on 15 January 2015. Then the NRO will submit by this deadline with the IP address community's input to the ICG. Then the ICG will do the further process. Then the ICG's target to submit the final proposal to the US Government is set in June 2015. What I said is quite well illustrated in this slide. Please look at it. Then as the IP address community, we have some 11 discussions to develop this proposal in front of you, to present it in front of you. We think we have the possible issues to consider. They are listed here. ICANN is the current operator of the IANA function should be ongoing or not; then operational security of IANA functions; how should it be secured; and then policy compliance by IANA; how should it be retained; and then whether we should have IANA oversight mechanism or not; or, if any, it is what kind of shape; ICANN's accountability to operate the IANA function to the RIR communities, what kind of accountability should be equipped there; and finally, agreements between ICANN and the RIRs/NRO. This table is actually simple enough, but the current proposal from APNIC. By the way, this proposal is compiled by the APNIC Secretariat for your consideration, and I am, as the Chair of the Executive Council, that means in between you and the community -- it's you and the Secretariat. That is the reason why I am now presenting, expanding on this Secretariat's proposal. This is the whole of the draft proposal. Then we have the three points: the first point is the US Government to terminate the IANA contract on 30 September 2015. This is actually the expiry date of the 12 current IANA contract between ICANN and the US Government. Then the first point to be proposed is we would like to have this contract terminated at the expiry of the current contract. The second part -- this is the first principles, which is technical stability and continuity. We definitely need the stability and the continuity with IANA functions because in the Regional Internet Registries serve with the IP number resources to the ASO members and the broader community, with that resource which is provided by the IANA. If this provision of the resource and the management service goes unstable or is not to continue, then we, RIRs, have a big problem to serve you, then therefore the entire Internet Community will be suffering from the problem with the lack of the provision and lack of the management of our number resource. That is the first point of the principle. The second point is the transparency, consistency and completeness in all agreements. So this provides us the confidence on ICANN proposals -- this proposal like to have ICANN as continuously the operator of the IANA. But anyway, the transparency, consistency and completeness in all agreements will provide us with the confidence to the ICANN or as the IANA operator to deal with, and then to put the trust in their operation of 13 the IANA function. Then under these two principles we have some concreteness of the transition plan. For the technical stability and the continuity, the transition plan should be in this draft proposal that ICANN to continue as the operator of IANA. Yes, we can, it is possible for us to consider a different organization to run the IANA function, but ICANN fulfilled that operator's position for 15 years and then they are obviously at the best position to run the IANA function. If we think of the change of the operator of the IANA, then we need to have the huge amount of additional provision to make sure that the other -- that another entity to run the IANA function. The second point is the NRO, as the collective RIRs, to enter into a Service Level Agreement, SLA, with ICANN as the IANA function operator. The Service Level Agreement, which is assured the service quality of the IANA function, then that should be clarified, again. That is the point. For the principle of transparency, consistency and completeness in all agreement, we have two points under that. NRO to review current agreements with ICANN, and NRO to enter into an affirmation of commitments with ICANN. 14 For the clarification, affirmation of commitments is one term which is also used to the agreement between ICANN and US Government to provide ICANN and the US Government's commitments to affirm. But in this case, this affirmation of commitments represents the newly established enforced agreement which provides the commitments from both sides. This is the entire draft proposal which was compiled by the APNIC Secretariat with the association with all RIRs, for you to consider. I guess that many of you might think this is a really simple, but I think -- I like this proposal and this is simple enough but this is quite sufficient. Somebody may think that such accountability and oversight function to the IANA operation needs to have more rich or sophisticated process and scheme to fulfill, but the IP address management is largely done by the five RIRs, with the cooperation with the IANA function as the manager of the origin of the number resources, and then that kind of accountability and assurance of the operation, sustainable operation, is possible to be fulfilled by the agreement as the -- of those who accept the IANA service, IANA function service, by the ICANN as the IANA's function operator, to us. 15 There is actually, in my view, this is sufficient for retaining the accountability of the IANA function in terms of the IP address management. In this proposal, I think you might have some questions: what are the current agreements; what does the SLA between ICANN and IANA mean, what is the affirmation of commitments? I did my job to explain to you as far as I can, but I think I would like to invite Craig Ng, the general counsel of APNIC, to have much more crystal clear explanation on this provision. . >>Craig Ng: I'm not sure about crystal clear, but it will be clearer than mud. I suppose I want to put some context behind the contractual framework. Us lawyers look at contracts and why we need a contract. The numbering community runs pretty independently of ICANN, but we need ICANN for a couple of things. We need ICANN, IANA, to allocate the numbers to us in the first place and we need ICANN to implement our global policies. In terms of independence, those are the two main functions they do. The three agreements, we as the RIR community work collectively through the NRO, the number resources organization. The three agreements that currently exist 16 between NRO and ICANN is pretty lightweight and it is lightweight because it assumes that there is a contract between ICANN and US Government that actually deals with a lot of the nitty-gritty of provision of numbers and things like that. So we in the numbering community are piggybacking on the contract that exists between US Government and ICANN. What we need to do is look at what the gaps are. The current three agreements, if you look in there, the MOU that was signed in 2004, really just says that the NRO NC will perform the role of ASO. So ICANN, as you know, has GNSO, CCSO and ASO. The ASO function in ICANN is performed by the NRO NC and the 2004 MOU simply really establishes the ASO and the provision of the function by NRO NC. It also deals with how global policies are developed -- so a very small part of what we do and our interaction with ICANN. In 2007 there was an exchange of letters. There is a good reason why there was an exchange of letters. People maybe don't trust each other completely -- there were a lot of issues that we really wanted to put into the agreement that didn't make that agreement. The exchange of letters was again very lightweight. It really was very softly talking about, "We support each others's activities and commit to each other's 17 relationship." It's kind of like not even an engagement or a wedding, it's a very softly, softly agreement. The 2009 exchange of letters simply is like a renewal of vows, it simply says, "Okay, we kind of like what we had in 2007 and we will continue what we had in 2007." The reason we are here today is that if and when the US Government exits and there is a gap in the contract between the US Government and ICANN, then how do we continue to make ourselves comfortable and assured that we will continue to receive the services and continue to have the relationship with ICANN that we currently enjoy? What's missing in the three agreements, or the MOU that currently exists, is that we are trying to put in and fill the gaps via the affirmation of commitments and via the Service Level Agreement. In the Service Level Agreement, what we are looking for is a commitment -- a mutual commitment to the recognition of each owes's role -- this is what we do, this is what you do, it is well documented, we all know what it is, but it is written on paper that we commit to each other's role. We commit to the multistakeholder model, because at the moment that is just set, it is not in any agreement between us two. We commit to acting in 18 the best interests of the Internet Community. We both commit to good governance, good accountability and good transparency between us and our stakeholders and it is a commitment to perform the services, assuming it is the entity that we want to provide the services. In the Service Level Agreement, there are the specific nuts and bolts of how the services are to be delivered, how the number are to be allocated, the timeline and timeframe, very detailed, just like an SLA you see in a technology contract, for example. That's what I wanted to talk about. The message really is that in pat we had a US contract which is kind of helping us to fill the gaps between the arrangements we currently have. In the absence of that, we need to fill the gap and we are proposing to fill the gap by the affirmation of commitments and SLA. >>Maemura Akinori: Thank you, Craig. That's all for the explanation part. Based on them, I would like to pass the floor to Masato, to moderate the community discussion. Thank you, Masato. >>Masato Yamanishi: Thank you very much for inviting me as moderator. Before starting the discussion, let me say -- let me explain my intention of the session, 19 because I'm the person who challenged the current APNIC outreach activity in the last meeting, so some people may feel it's a little bit strange that I'm doing the moderator of this session. In my understanding -- as Paul already explained, IANA stewardship transition has three -- (pause) -- right now we have a transcript issue. This time, we only have one transcriptor in here, but we have another transcriptor in the APNIC office and she is working remotely. Miwa asked to continue the comment when we stopped, but I cannot remember. As Paul explained, IANA stewardship transition has three perspectives. Correct, Paul? One of them is the number part, and APNIC, which is an RIR -- not only APNIC, but also other RIRs -- are direct stakeholders for that part. So we should discuss what we can handle this issue inside our community. Then that is the reason why I accepted this moderator and also -- sorry, talking a little bit long -- but I want to make sure that the goal of this session, we have -- in my understanding, we have two goals of this session: the first one is getting better understanding about this, about IANA stewardship transition in this community, and also another one is, 20 of course, hearing your views or your comments about this proposal. As I said, the first goal is getting better understanding of this issue. So please don't hesitate to ask questions about the background and also about this draft proposal itself. If you want to start questions -- whatever you have, please come to the microphone and ask your questions or say your comment about this thing. I forget to mention one more point. As I said, we are a number community so I would like to focus this discussion to the number part as much as possible. Also, I know that we have many participants coming from outside the region, but please respect the participants coming from this region, because the goal of this session is hearing from this region. >>Chris Disspain: Good morning, everybody, I'm Chris Disspain, CEO of .au and a member of the ICANN board. I just wanted to take a couple of minutes -- respecting completely about what you have said about this is the numbers community and so on, I just wanted to make two very simple points. In the same way that APNIC needs to work closely with the other RIRs to come up with its number piece of what the bigger picture is going to be like, the ccTLD 21 community and the gTLD community needs to work together to come up with a names piece and the IETF or the IAB presumably needs to work on its own or within its own community to come up with its protocol parameters piece. The key to it is to remember that all three -- or possibly four, because the gs and ccs will end up with slightly different needs from IANA -- all four need to be sown together to make one piece. So it is incredibly important that while you are working on your numbers piece, you keep an eye on what's going on in the other places to make sure that there aren't any future train wrecks that might occur because the pieces aren't compatible. I want to say one other thing, which is that I've heard in the last couple of days that I've been here a number of people talking about, "Well, the worst case scenario would be that the numbers community comes to a consensus about what it wants and that will be fine and that will happen by September next year, and if that ends up happening on its own, that's okay." I very, very strongly doubt that the US Government will agree to doing this piecemeal. They will only agree to doing this as one move, which means all of the pieces have to fit together, therefore that makes it even more important for everyone to keep an eye on the 22 bigger picture. That's all I wanted to say. Thank you. >>Dean Pemberton: Thank you. I'm Dean Pemberton, InternetNZ. I have a number of notes but I'll start from the top. The first point I had, I think, has kind of been covered by yourself and Chris. I just had a couple more comments. If you bring up the draft proposal, I just want to get clarity around whether we are talking about just the numbers piece here or when we are talking about the three or maybe four functions. When we are talking about the IANA function and all that, we are just focusing, argues the APNIC community, on the numbers piece, right? >>Masato Yamanishi: Yes. >>Dean Pemberton: I am seeing some nods, awesome. That's great. What I think as well is to acknowledge that we do have a good working relationship with IANA, over a number of years, and we do enjoy the ability to more or less be the masters of our own policy destiny. We have the Policy SIGs here, we decide how we are going to do all this sort of stuff, but in other areas of the IANA function that's perhaps not the case. It might be an option for the three parts to not 23 look exactly the same. So while I take Chris' point that they absolutely need to be compatible, I don't know that they need to be identical. This is all about establishing a shared understanding. I would ask -- I would say that it could be a possibility for APNIC or the NRO to come out in support of the names community, so that they can have a similar sort of masters of their own destiny function as we enjoy, and that might be an option. My other points really go to accountability. Where does the accountability lie within this model? We have got some language around "Agreements should specify", but this is such an important part -- >>Masato Yamanishi: You mentioned about accountability, but accountability in which organization and to what? >>Dean Pemberton: Accountability of the IANA function. For instance, does IANA review and audit their own work or is their independence in the review accountability function, et cetera, et cetera? The language around agreements should specify -- I think we need to talk a little bit more about that at this stage, rather than leaving it to the agreement stage. Where is the accountability for the function? How does that fit into this? The rest of it, I'll wait 24 until we get a little bit more conversation. Thank you. >>Masato Yamanishi: Regarding the accountability, we have to make sure of one point. As shown in this slide, currently, from the numbers perspective, ASO has accountability for IANA function. No? Who has accountability? >>Maemura Akinori: ICANN has the accountability for the IANA function. It should be accountable. It is responsible for coordinating the discussion of the global policy, which is the policy for IANA function to the IP numbers service. That is the position. >>Masato Yamanishi: So you are talking about accountability as operator, right? But we also have policy proposal, and policy proposal is ASO. I'm not saying my comment -- just to make sure what you are talking. >>Kuo-Wei Wu: Can I comment about the issues? I think accountability is both sides, to be honest. I think because ICANN can have accountability for the numbers community, of course, but at some time, don't forget the ASO global policy or number policies, you have a similar accountability for the Internet user globally. So I think the accountability is for all sides. We also have -- maybe we have a different target but somehow we all have accountability issues. So 25 accountability now is on the ICANN or IANA side; the ASO also needs to have accountability to generate a good global policy to the user. >>Kenny Huang: Kenny Huang, Executive Council member of APNIC. First of all, thank you to the ICG folks to make this effort to make it happen. I have two questions. The first question is the effort we try to make, either it is SLA or AOC -- sorry, I'm not a legal guy -- from my observation, that kind of effort to strengthen the relationship, either via an application between ICANN and the NRO, but from my observation, that kind of effort can be exercised from time to time without IANA transition. So I didn't figure out what kind of relationship between that kind of effort and that relationship between US Government and IANA. So what is the implication after we are doing this? That's the first question. The second question is: although we propose the proposal as consensus from the community, but the things probably didn't work out as we anticipate, do we need a plan B, just in case, to run another exercise in the next year? Thank you. >>Masato Yamanishi: Can somebody answer the first of Kenny's questions? Nobody? Is that an open question? 26 >>Dean Pemberton: Hopefully we don't need a plan B because we are going to get plan A right. >>Craig Ng: I will answer the accountability. This is Dean's question about accountability. What we expect to see is mutual accountability -- mutual commitment to accountability -- not one way. So we commit that we will be accountable to our community in terms of policy making and everything else about governance that we talk about and we expect the same from ICANN. >>Dean Pemberton: Would that be in the non-binding agreement? >>Craig Ng: Sorry, Masato, more dominating this. >>Masato Yamanishi: That's okay. >>Craig Ng: The question about binding or non-binding is a very difficult one for a lot of people to get their head around. I'll give you my opinion. We are talking in this case about global arrangements that deal with Internet addresses. There's no point really in my mind that we have to go to a court, whether it's in the US, Australia, China or Hong Kong, to try to deal with a breach of contract, because if we have to go there, then something is already really, really broken. What I see that is necessary is that the affirmation of commitments of is done in a non-binding sense, but in 27 terms of the service level, the nitty-gritty of things that we need, then both parties, NRO and ICANN, should enter into a binding arbitration arrangement so that we have a third party, an independent party, who can't award damages, by the way, but who can force a party to say -- request "you need to do this." So if IANA doesn't provide the numbers, for example, or is very slow, we need to have a mechanism where we can go to an arbitration centre and ICANN/IANA will be forced to do that, or the same thing, if our accountability is not clear, we need to have a binding direction that we have to do that. >>Izumi Okutani: I think what Craig has explained and the proposal that comes as a draft from APNIC makes a lot of sense. It is kind of probably boring to just say simply agree. I am interested to hear from the others if they feel that this itself is not good enough, either in terms of accountability, that's been discussed a lot, or in terms of keeping up the service level. Firstly, from the numbers perspective, and then I think there was a point that was raised from Chris, that this proposal will be integrated with other IANA functions. If there is anything that we should consider in balance with possible alternative proposals that 28 might come up and affect the model for the numbers function, either in terms of accountability or keeping up with the IANA function. If we have extra time, I would be interested in discussing what would be the kind of differences, maybe the perspective from the numbers perspective and from the names, possibly the protocol parameters, and what are the things that we may be able to -- what do you call it -- compromise? >>Masato Yamanishi: Do we need to discuss that point at this stage? >>Izumi Okutani: No, I think the priority first would be to agree on what we feel with the numbers. But if we -- >>Masato Yamanishi: We also need to consider it. >>Izumi Okutani: Yes, exactly, that's my point. >>Masato Yamanishi: Thanks. >>Ole Jacobsen: I want to make a more general point. All the things we are talking about that IANA does right now works very well. Plus themselves, I don't believe I am in great need of being revised, perhaps documented better, might be one step. But generally speaking, whenever I go to meetings like this and hear the discussions about the future of the IANA, all sorts of people want to get involved in human rights and accountability and transparency, and gee, why is ICANN in California, and all sorts of things. 29 I would really urge those of you who are intimately involved in this process to try to stamp out and avoid that as much as possible, because if we end up in a situation where every time the root zone is going to be updated it needs to go out to community for a 90 day review to all these constituencies, we are really screwed. Thank you. >>Kuo-Wei Wu: I think, just for Izumi's talking, I try to, from another angle to answer part of what Izumi is talking about, and also maybe try to add to what Chris mentioned about not only talking about the numbers, you also need to watch the other communities, like the names, the cc or g, because somehow eventually the ICG will come out with one proposal, it is not spread. Of course, you have different sections, but APNIC is one proposal. If that is what you are asking, saying why we need to watch the names in this proposal, let's take one simple example. I came from this numbers community, as you know, I was APNIC EC for 12 years, I was participating in APNIC from 1996 until now, and my point is, as we know, at this moment I think we are really working hard in this numbers community to try to promote IPv6, and also, don't forget that because the whole 30 Internet Community or Internet infrastructures, the DNS, plays a very important role, and DNS definitely is kind of merged -- well, it's the names and numbers there, you know. So we definitely is not isolated in the whole Internet World or Internet Community. We definitely need to somehow work with the names and numbers, you know, together. I think this is one of the examples why we need to watch all. Of course, we need to have consensus in our numbers community, that is the number one priority, but it doesn't mean we don't need to spend some time watching what the names community is doing. Because maybe they come out with a very different concept or idea. >>Kuo Wei Wu: I think I just try to answer Izumi also, you know, just adding a little bit what is Chris talking in the beginning. I think first of all, this is one proposal and also we also need to be careful, because somehow the name and number is in the whole community, it's not we are not isolated one. So that is my comment. Thank you. >>Masato Yamanishi: Yam any she. >>Donn Hollander: From APTLD and we are very interested in names and also the region. So my question is, for the APNIC community, are there any regional issues in the Asia Pacific community that APTLD, the names community 31 and APNIC the numbers community, need to work together on and so far in this proposal, for discussion I see nothing and in APTLD's discussion on Monday afternoon, there were no regional issues, but I just wanted to see if this community felt there were, so that we could work together, if there needs to be. Thank you. >>Masato Yamanishi: Paul or Akinori, do you have any comment for that? >>Paul Wilson: It's a good question, Donn, it's also a good -- a number of good points that were made for instance by Chris earlier about the potential interactions between names and numbers and protocols, because the ICG this asking for these three responses is not really under the illusion there there no interaction or inconsistency or issues to reconcile between them. In fact, if you look at the ICG charter, it is very much about maintaining communications from all of the communities about the processes that are under way and the discussions, the conclusions, the plans as they are being developed and emerging and it is also a very clear expectation that all of these processes happen transparent I will, so hopefully the relatively small ICG is not the only place where people are watching more broadly outside of their communities. 32 So I would point out that we are in fact charged with reporting back and keeping that information flow running and it's going to be part most of the challenge over the next three or four months until the plan is actually sort of put together. I take it Donn's point very much about the Asia Pacific region and I think the point of the session is promote awareness and understanding and to gather views and opinions from within this community and I think what we can do to support each other is to make sure that the information is flowing out into the community as much as possible again to promote awareness outside of this room, but amongst our community across the region. Thanks. <>Masato Yamanishi: , I think ICANN as supplier is good comment. One second. Sorry for interrupting. I'm only seeing people who should know well about these things, but as I said, first goal of this session is getting better understand from this community. So is there anybody -- nobody has question about this? Have you already understood where very well?? 34 Can I have paper test? >>Kuo Wei Wu: Can I comment? This room, I really encourage you, might be many of you already know and some of you might be just a part of the information. You can go to the ICANN website. There is IANA function stewardship transition site and they have all the description, from the IANA function, from whatever the NTI statement what it's saying and go down to how the ICG is formed and who are those ICG members. Also, including the three teleconference, two face-to-face meetings, all those information is recorded in six different languages. You always can go in to listen or to read. Every ICG meeting in is a realtime, you know, broadcast online, you can always sign in and pick up the language you want, six languages available. So including Chinese, Spanish, English, Arabic, Russian and -- what else? Which one I miss? French, sorry. I should not forget about French. So this is you can go more information, just like you're saying. Also, all the documentation is open in the drop box. You can download whatever to read what is the process, version 1, version 2, version 3 and more than that, you always remember in that microsite is available for anybody to make your comment to the ICG. ICG will go through your comments into the discussion, 35 just some information share with you. >>Masato Yamanishi: Kuo Wei, I don't think we need to make it so broad. This slide shows it's very clear that RIR is end user of IANA function. IANA is address number resource supplier, so if they would not provide number resource as we expect, there's going to be a problem. So we are direct stakeholder of this thick. Anyway, go ahead. >>Izumi Okutani (JPNIC): I very much agree with the statement that Ole made. Let's just focus on practical things and how this would affect us. So I think all this -- a lot of the discussions might be for people to suddenly join in, so let me start with one of the elements of the proposal. One is saying that I think the proposal says that it supports that ICANN continues to be an operator of the IANA. So start with the position of JPNIC, we support this because we think that the IANA maintains the current service level is very important and if we think about an alternative organization running the IANA, it might degrade or have the risk of some not some transfer not being made properly and might decrease the level of service that the IANA currently provides to the RIRs. So that's why we support this. I wonder whether the others feel the same or they 36 don't care or they support other organizations running the IANA functions. >>Masato Yamanishi: For time being, in plan this session will be until 12.30, right? Now it's 12.20, so we only have 10 minutes. So let me focus on this proposal itself from now on. Is that okay? Okay. Silence is agreement. >>Dean Pemberton: I just wanted to make one small point. We have heard quite a lot of people saying that we need to be worried about the thing as a whole. I agree, but there are those of us organizations that have one foot in numbers, one foot in names and we certainly are keeping our view across both, but if you're an organization and you are just concerned about numbers, I think this is definitely where your focus should be. >>David Huberman (Microsoft): My input here to Paul as a member, as an executive member of the NRO, is on the SLA, the most important thing that I think the IANA does for us is the administration of IP6.ARPA and ARPA. Right now they do it exceptionally well this my experience, in my opinion. There's defined processes through interfaces to update /8s, /12s, there are processes that you can -- that the engineering staffs of the RIRs can use to make up dates to the parent zone files. The IANA conducts this activity exceedingly well 37 and within any reasonable SLA, I hope that the NRO will put that in writing, in any agreement. >>Masato Yamanishi: I have related question for Craig. Do we have any content as we can call SLA in -- where is Craig? Do we have such contents in existing agreement? >>Craig Ng: No. There is no content, but there is proposed content. In the current framework of the three agreements we talked about, there's nothing on SLA at all, nothing about service levels at all, but they are very much contained in the agreement between US Government and ICANN currently, the one that's about to finish. So my idea is that we can actually use a lot of the materials that's currently there, where US Government -- where ICANN has committed to the US government as a basis for SLA. >>Masato Yamanishi: Thank you. Is there any other comments? Okay. >>Kuo Wei Wu: Yeah, regarding for this, I think the SLAs maybe is you try to make some kind of the much firm relationship between ICANN and NRO,; is that right? That is my, I suppose. Actually, don't forget that we already have some kind of relationship between the ICANN and the NRO. Not only from those exchange data, remember that in the NRO, we have to appoint board 38 member into the ICANN board and it's very important to select your appoint member going to the ICANN board to present your viewpoint. I think we all remember that since 2010, staff from I think it's ICANN Cartagena meeting, we continue every ICANN meeting with the ICANN board and senior staff is met with the NRO and also ASO member and this is very important communication go with in both sides. So don't just limit our relationship only on the exchange data, more than that. >>Craig Ng: I suppose what I would like to kind of refer back to what Chris was saying, that the relationship between ICANN and RIR community is not just of a customer supplier, but it's a partnership, so in the two agreement, the way I see it is that the AOC is a partnership agreement, the SLA is the supplier, the customer supplier relationship, because the relationship is kind of both. That's why we are proposing that two things. >>Masato Yamanishi: Okay, got you. >>Donn Hollander: This is a question for Craig. You are suggesting binding arbitration and I guess my question is in this model, what happens if things turn to custard? What are the remedies and would you expect the RIRs to -- what opportunities will they be able to take 39 and if you could put your older ccTLD thinking hat, how that might apply to names as wellings but focus on numbers here, too, of course. >>Craig Ng: It's a very tricky one to answer politically, but the reason why it's non-binding is for that precise reason. It's non-binding. So it's like having exchange of vows, but you can still have a divorce. >>Donn Hollander: So it's okay to have a divorce? >>Craig Ng: Yes. >>Paul Wilson: I think we have heard questions about the back-up plan and/or plan B. The plan B is really that the status quo continues as it is. The US Government has provided an opportunity here to achieve something which we have asked for in the past, which provides the independence of what we do from that one element that actually attracts a lot of attention, that is the special role of the US Government. That attracts a lot of attention, it attracts some negative press, frankly. So we have this opportunity to achieve what we have asked for over the years. If we don't achieve that opportunity, if we don't take the opportunity or if we don't achieve it to the stated expectations, then the back-up plan is simply that the USG will go ahead and renew the contract, we expect largely the same as it has been before, but the 40 future is unknown. I don't think it would be possible for the USG to say you have another 12 months or you have another 24 months to achieve this. I think we are simply back to the status quo, because the fact is that in the next term of the IANA contract, if it's renewed, there will be US elections, a change or a renewal of the US administration and really no one is going to make promises that are going to be able to endure through that kind of change in the US. So back-up plan is simply that we continue the way we have been continuing for years with reasonable success and satisfaction. But the opportunity is there. I would like to suggest one thing for the session, which is could we see some indication of the level of comfort with this proposal with support? >>Masato Yamanishi: That's what I'm trying to do. >>Paul Wilson: Thanks, Masato. I'll leave it to you. >>Masato Yamanishi: Give me five minutes more, then I want to make sure these items in current draft proposal is comfortable for everybody or not. I want to make sure that point. Okay. Then as Paul already mentioned about first principle, which is USG to terminate the IANA contract, but I think we can call it as assumption, not principle. Right? I think we don't need to discuss about this 41 first principle. Then let's go to second one, technical stability and continuity and also I think -- I don't think we will have any complaint about that point, but I want to make sure. Do you have any comment about second principle, which is technical stability and cotinuity? >>Dean Pemberton: Paul has asked for some measure of the room about how people feel about this draft proposal and I think that's very important. I mean, it's come from the Secretariat. They have come for us for consultation, they need to know how we feel about that, so InternetNZ in its current form thinks that this is a great starting point in the numbers space. It doesn't talk about the names and that's good. So in the numbers space, InternetNZ supports this as a good starting point and thinks that there needs to be a level of detail fleshed out around this, there may be some points in that that we might some more clarification on, but as a starting point, we think this is great, so thank you very much. >>Masato Yamanishi: I think we need to make sure this proposal is from number perspective. I don't see any number, word of number in this proposal. >>Craig Ng: It's because the SLA is really just going to be talking about numbers, so we haven't actually got the 42 details in there, but everything, all the service levels that will be referred to will refer to numbers and I suppose the other point is that the agreement is between NRO on behalf of all the five RIRs and ICANN, so by logic, we can't bind the numbers community, because jurisdiction, if you like, is in the numbers. >>Masato Yamanishi: Can I assume second principle is accepted in this community? Is it okay? Let's go to transition plan for the second principle. There are two items. First one is ICANN to continue as operator of IANA until further notice. Second one is NRO to enter into SLA with ICANN before June 30 next year. Do you have any comments for these two transition plans? Is it okay or are you sleeping? Nobody is sleeping in this room. This is very good. Okay. So let me assume this transition plan is accepted, so next is third principle, which says transparency, consistency and completeness in all arrangements. It's little bit ambiguous, but do you have any comments or views for this principle? Is it okay? Okay. So how about transition plan, the third principle? It says NRO to review current agreement with 43 ICANN before the end of December of this year and also NRO to enter into an AOC with ICANN before the end of June next year. I think we already identified what's the difference between SLA and AOC, right? So we should have both here. Okay. Also, I think one point, in addition to this proposal, I think in my understanding, another point was raised which is even though this proposal is from number perspective, we also need to consider how to cooperate other idea, like especially names, because we have name organization in this region, so that's the open point. Is it okay? I have one more question. Is there any additional principle which we need to consider? Is it okay? It covers everything? Okay. So let me -- >>Maemura Akinori: Thank you very much for the very Chrisk moderation of this session and I think I'm really happy to have this discussion and as Masato did in the last part of the moderation, some points are clarified as the current thought of our community. I would like to encourage you -- I am now concluding this session, but I would like to encourage you to continue the discussion throughout this week and further on the mailing list. Maybe you have a lot of even clear 44 point on this issue of the IANA stewardship transition, because it is really complicated, with a lot of documents and implication with the other organizations, blah, blah, blah, then please never hesitate to come up to Paul and Craig, myself, Masato, some other people who you think have the knowledge on this issue and myself and I believe that any staff from the APNIC Secretariat is quite willing to answer your question. This is here, today, at APNIC region of this discussion. As you know, the request for proposal was just published and we are the very first RIR to have the opportunity to meet and discuss this issue and we will have at least until December time of the discussion where the other RIR have their own discussion to proceed some thoughts on their own, then APNIC need to keep track of that APNIC community need to keep track of that to reflect such achievement from the other RIR to our own consideration. So we will go on the discussion on the mailing list for the develop this proposal further and adding some more detail to complete the APNIC's own final proposal to submit to the NRO. Then the other thing is, yes, Chris Disspain, you know, it is very important to have an eye for the other community like names and parameters from the protocol 45 parameters. Some of you might know that IETF has started their own business, their own process with their quite normalised standardized process to begin with the BoF, establishing the working group, to develop the Internet draft and then make it as RFC. They are already on the way to develop their proposals, then that is worth reading, any of you for the reference. Masato is right. This is our job as the APNIC community to have our own say to this issue. Then please do participate in this discussion throughout this week and continue on the online. >>Masato Yamanishi: I think this draft proposal will be discussed in other RIRs also in this autumn. The next one is meeting in October, ARIN. Will somebody attend to ARIN meeting? I also will. Then next one is LACNIC one. >>Paul Wilson: Certainly some APNIC staff will attend the ARIN meeting. We haven't discussed that APNIC would take this proposal and formally present it. I assume that we are being watched by at least some folks in the other RIR communities and they're taking note of that, but whether or not this proposal fits into the way that the other RIRs will deal with this issue is a question for them. If invited, I think any of us would certainly 46 be prepared to stand up and talk to this proposal at the meeting, but this hasn't been a discussion or a decision about that yet. >>Maemura Akinori: Then that's already the time to conclude. Thank you very much for joining the discussion and please give the big round for the moderator, Masato Yamanishi and all of you, thank you. APPLAUSE