1 https://conference.apnic.net/39/program#sessions/policysig(3) ************ >>Masato Yamanishi: I would like to start the session within one minute, so please find your seat. Okay, so I would like to start the third Policy SIG session. In this session we have four items: the first one is we are asking consensus about prop-114; the second one is the APNIC informal presentation from Guangliang; the third one is prop-112; and the fourth one is the inter-RIR transfer policy in RIPE region. I think, Skeeve, you have something to ask to the community, so I can give you only five minutes. >>Skeeve Stevens (eintellego): I don't need five minutes. We just wanted to make a request. One of the key issues with prop-113 was a misunderstanding with regards to demonstrated need. Just as we are resubmitting a clarification on prop-114, we ask the room if it's okay to quickly just put that one line in, saying that we are not removing the demonstrated need. In an effort to save six months of time for waiting to change one line of text, it was just putting that back to clarify that, and if that is the only change to 2 the text, which has already been sent to the list, if that was acceptable to Dean and others for reconsideration. >>Masato Yamanishi: What Skeeve is asking -- Dean, go ahead. >>Dean Pemberton (InternetNZ): It is my understanding that when we asked for final consensus on this proposal and that final consensus was not achieved -- is that my understanding? >>Masato Yamanishi: Say again? >>Dean Pemberton (InternetNZ): We asked for a show of consensus on the proposal as it was at the end of the discussion, and that that consensus was held -- and that the decision at that point in time was to return the proposal to the mailing list. Is that an accurate representation? >>Masato Yamanishi: Yes, it is clearly mentioned that prop-113 is pushed back to the mailing list. >>Dean Pemberton (InternetNZ): Okay. Then we would support that and we would strongly oppose any bending of the PDP around that. Consensus was asked, it was given and we have a clear way forward. Thank you. >>Tomohiro Fujisaki: I just want to say the same thing. I fully support Dean's opinion. >>Masato Yamanishi: I think we already agree it is pushed 3 back to the mailing list and also there is no support for Skeeve's suggestion, so I will not ask consensus again about prop-113. Then let's go to prop-114. >>Aftab Siddiqui: This is the revised text. It says: "An organization is eligible for an ASN assignment if they are currently multihomed or have previously allocated provider independent address space by APNIC and intend to multihome in the future." >>Masato Yamanishi: Then this text will be implemented in the policy, not in the guideline. >>Aftab Siddiqui: Yes, it is part of the policy. >>Masato Yamanishi: Is there any comment about the text? >>Dean Pemberton (InternetNZ): As worded, I support the proposal. >>Tomohiro Fujisaki: Just a clarification question. If I intend to multihome, is it possible to validate by the Hostmaster? >>Aftab Siddiqui: I would like to ask a counter-question. How do they do it right now? >>Guangliang Pan (APNIC): I think this is a good question, but I believe if they intend to mention that in the request, that it is the intention to do multihoming in the future, and based on the APNIC policy environment, we should trust the member to tell us what they say in 4 the resource request. So if they say that they intend to do it in the future, we believe them. >>Tomoya Yoshida (NTT): I have a comment about the intention. Is it okay for the APNIC Hostmaster to review, for example, the one year later, so the number of the ASN using this policy? >>Guangliang Pan (APNIC): I think this policy cannot tell exactly how long. Skeeve? >>Skeeve Stevens (eintellego): In the post I just did to the mailing list, we are happy to have this reviewed annually for any impact on the ASN pool. I didn't think it was appropriate to actually put that into the policy. I didn't think timeframes went into policies themselves. I mean, the key reason, just to address the other "intend to multihome", it is very difficult to police this. It is difficult to police people being multihomed, not multihomed and then multihomed again, in this elastic world at the moment. We tried to keep that a little bit vague, on purpose, because of timeframes and flexibility and you start to encroach a little bit about telling people how and when they should multihome and things like that. We are happy to do that. Honestly, I don't believe that this would have any impact on the ASN pool at the moment, mainly for the fact that anyone who actually in their eyes needs AS 5 numbers, they can get around it, and in numerous ways that have been discussed on the mailing list, getting a tunnel to HE for a week, and they are still multihomed and they satisfy it. There are so many ways around it that it didn't really make any difference for that sort of thing anyway. >>Mike Jager (Synack): I am just looking at the wording of this and I want to be clear that I don't fundamentally oppose changing the eligibility for ASN assignments. The current text in section 5 reads: "An organization is eligible for an ASN assignment if it is (a) multihomed and (b) has a single clearly defined routing policy that is different from its provider's routing policies. An organization will also be eligible if it can demonstrate that it will meet the above criteria upon receiving an ASN or within a reasonably short time thereafter." To me, that reads pretty similarly to what's up there. In fact, that seems to be more restrictive than what is there today. The existing policy has no requirement to have PI address space allocated by APNIC, whereas that does. >>Skeeve Stevens: No, the key part in the part you mentioned was the "multihoming and", is what we are addressing. 6 >>Mike Jager (Synack): You want to remove the "has a single clearly defined routing policy that is different from its provider's routing policies"? >>Skeeve Stevens: Well, there has already been a discussion on the mailing list about you can even be single homed and have a unique routing policy from your single upstream, if you want. So that is a kind of variable aspect, where here the previously allocated space, they want it to -- the problem is we couldn't really say you are currently multihomed or not currently multihomed. That kind of didn't make sense. In discussion with a couple of people, it kind of made sense to say that you should at least have provider independent space allocated to be able to be justifying getting an AS number, because why would you be asking for AS numbers most of the time -- surely there are use cases -- if you didn't have any address space? >>Mike Jager (Synack): Aren't you basically trying to say, if you are currently multihomed or plan to be multihomed in the future? >>Skeeve Stevens (eintellego): Yes. >>Mike Jager (Synack): Isn't that basically what the existing policy says? >>Skeeve Stevens (eintellego): No. >>Mike Jager (Synack): I struggle to understand that. 7 >>Skeeve Stevens (eintellego): The existing policy says you have to have a unique defined routing protocol or are implementing one in the short future, a future which is also an indefinable term. >>Mike Jager (Synack): If you are multihomed, then by definition you have a different policy from your provider's policies. >>Skeeve Stevens (eintellego): Yes. >>Mike Jager (Synack): Okay. I sort of understand it. >>George Odagi (APNIC): David Woodgate would like to ask: "Is multihomed which is not generally visible because of routing policies considered acceptable?" >>Aftab Siddiqui: Sorry, can you come again? >>George Odagi (APNIC): "Is multihomed which is not generally visible because of routing policies considered acceptable?" >>Aftab Siddiqui: If it is multihomed, but you cannot see it? >>Adam Gosling (APNIC): Yes, if it is private. >>Aftab Siddiqui: If he can clarify the statement. >>George Odagi (APNIC): He is clarifying. >>Masato Yamanishi: Before his clarification, let me make one more point. I think we have a discussion about the second or further AS request. How did you adopt this version? 8 >>Skeeve Stevens (eintellego): At the moment it is evaluated under the same situation. If you are going for a subsequent AS number from APNIC, you already have to justify the reason you need that to APNIC. You have to convince them that you are having a different policy and so forth. If I was going to go and put an isolated network in a different location, while I could use the same thing and use GREE tunnels or other things, that is also telling people how to run their networks. If I want to do that -- if you pass that point of convincing APNIC, which is in the policy, then I guess it applies the same way, whether you are multihomed or not, where you are not really discussing changing the subsequent policy at all. We are really talking about the evaluation of an ASN. Whether that's first or second or tenth, I don't know if that's relevant, as long as it applies for each location. So that's up to APNIC really. >>George Odagi (APNIC): David says: "If a set of companies talk to each other but don't advertise the routes on to the general Internet or do so individually without the path being visible?" >>Skeeve Stevens (eintellego): Yes, that's valid multihoming. >>Mike Jager (Synack): I think, perhaps to expand further 9 on what I said previously, maybe if you could provide an example of an organization under which the current policy would not be eligible for an ASN whereas under what you have proposed up here they would be. >>Aftab Siddiqui: Can you give the examples from the mailing list? We have a couple of examples on the mailing list. Skeeve is getting it, to answer your question. >>Skeeve Stevens (eintellego): That will take time to search. There were a number of examples cited on the mailing list. I don't really have time to go searching for those right now. >>Mike Jager (Synack): That was for a previous version of the text. This is quite different from what was being discussed on the mailing list. >>Skeeve Stevens (eintellego): No. >>Aftab Siddiqui: No, the unique routing policy you are discussing about is the same, it does not make any difference. >>Skeeve Stevens (eintellego): The only change from this policy and the previous version is that we had "while you are currently multihomed or", just a list of guidelines. What we did was remove that set of guidelines because people didn't want to give the Secretariat the flexibility to choose and we brought 10 that back into being a little bit more clarified in policy, where you have got a PI address space and you intend to multihome. So it doesn't really change the use case, it has just really broadened it a bit to encompass potential use cases. Since you're here, you intend to multihome and you can get an AS number. >>Mike Jager (Synack): What I still don't understand is how this version of the text is materially different from the existing policy. This text removes the requirement to have a separate routing policy and so on, but by multihoming you do that; all you are basically doing is removing the explicit, "you must have a separately defined routing policy". >>Skeeve Stevens (eintellego): No, the first part says you must be multihomed. >>Mike Jager (Synack): And after that first section it says "or you can show that you intend to in the future or in the near future" or whatever. >>Skeeve Stevens: I think the "near future" thing was relating to the routing policy thing. >>Mike Jager (Synack): That's not how I read it. >>Masato Yamanishi: Are there any other comments? If not, I would like to ask consensus about this revised text of prop-114. From this morning, we have five options: strongly 11 support, support, neutral, oppose and strongly oppose. At first I would like to ask your opinion by showing by hand. Actually, you can express your opinion on CONFER, but let me ask, showing by hand at first. If you strongly support this revised text, please raise your hand now. Okay. If you support this revised text, please raise your hand now. Okay. If you are neutral for this proposal, please raise your hand. Okay. If you are opposed to this proposal, please raise your hand. Okay. If you are strongly opposed to this revised text, please raise your hand now. That's very interesting result because there is no "oppose" and "strongly oppose" in here, but actually on CONFER, more than half the people is opposed or strongly opposed. Also, I saw many neutral people in this meeting. Can I ask the reason why you're neutral for this proposal right now? 12 >>Aftab Siddiqui: I would like to answer Mike. If you are referring to the eligibility for ASN assignment, that's fine. It says "is multihomed and has a single clearly defined routing policy". >>Mike Jager (Synack): Yes. I am saying they are inextricable. If you are multihomed, you have a separate routing policy. >>Masato Yamanishi: Wait, wait. I have already asked for consensus. >>Mike Jager (Synack): But as to why I'm neutral, I don't think this policy changes anything. I can't support it, I can't oppose it. I don't think it changes what we have today. >>Masato Yamanishi: You think it's still the same as the current proposal? >>Mike Jager (Synack): I'm saying that I can't see how the wording on version 3 is materially different from the policy that exists today. >>Masato Yamanishi: Got it. From this result, I think we can say it leads to consensus. So the next question I would like to ask, whether we will continue discussion of this one or not. Adam, can you set another question? I am afraid it is coming slow. Anyway, let me ask by show of your hands. 13 If you strongly support to continue this discussion about prop-114, please raise your hand now. Strongly support continue this discussion, yes. If you support continue this discussion, please raise your hand. Okay. If you are neutral to continue this discussion, place raise your hand. Okay. Then if you are opposed to continue this discussion, please raise your hand. Okay. If you strongly oppose to continue this discussion, place raise your hand now. Okay. That's also very unique because there is no opposed in here but still somebody on CONFER. Anyway, let's continue the discussion about the proposal. Let me push back the proposal to the mailing list. Thank you very much for proposing this one, Skeeve and Aftab. >>Aftab Siddiqui: I just want to add something, that those who are opposing or being neutral, can you just respond to the mailing list and suggest what's wrong, so that I can make the changes? Thank you. 14 APPLAUSE >>Masato Yamanishi: The next one is an informal presentation from Guangliang about APNIC IPv6 pool and delegation practice. >>Guangliang Pan: Hello, everyone. I think we had a lot of discussion on the IPv4 and AS numbers issue, now we switch to IPv6. I just want to give you a bit of background, APNIC IPv6 pool and delegation practice and hope this can help with the policy discussion. First, let's review the APNIC IPv6 delegation history. In 1999, on 1 July, IANA made its first IPv6 allocation to NIRs. Its first to APNIC was 2001:0200::/23. This is the first /23 given to the NIR, given to APNIC. On 13 August 1999, APNIC made its first IPv6 allocation, it's a /35 to WIDE project in Japan. At the time we made /35 allocation, not /32. Then, minimum allocation size was /35 at the beginning, which is now trying to make IPv6 allocation in 1999. Then in January 2002, changed the minimum allocation size to /32 to the members. IANA is making /22 block to the RIRs from 1999 to 2006. How APNIC made allocations during that time: APNIC is making /35 at the beginning and then later changed 15 to /32 to members, and we all reserve up to a /29. The allocation is based on sequence, just from the top to the bottom, so we don't do sparse allocation at that time. On 3 October 2006, IANA allocated a /12 to each of the RIRs. 2400:0000::/12 was allocated to APNIC. APNIC immediately implement the sparse allocation, and the last /32 made in the sequence allocation was on 10 October 2006. Then, after that, we started making sparse allocation from the new pool that was 2400:/0000::/12, that was the pool for APNIC to make sparse allocations. Let's look at what -- I probably label this sequence allocation pools that was allocated to APNIC from IANA before 2006. We received five /23s from IANA. Each of the /23s can make up to 64 allocations, because we reserve up to a /29 for each of the allocations. /29 to /23 is a 6-bit and total to the power of 6 is 64. So each of them, they can maximum make 64 allocations. Some of them we have large allocations, large, like /29 or /26 even. So in some of the pools, the allocation is not 64. We also make some reservation for special purpose inside those pools. That's why the number is not 64 for each of the pools as well. 16 Also one interesting thing is the last /23 from IANA was part of the 2400 /12. So it was allocated in January 2006, so it was before IANA made that delegation to APNIC in October 2006. Now let's look at the sparse allocation pool. When we received the /12 from IANA, we split it into two /13s statistically. The first /13, we used it to make small, medium and large allocations. You can see now there were nearly up to 4,000 allocations in that pool. This means that each of the allocations into the first /13 pool, they can go up to /25 at this stage. The target was set was /28, so if we say /28, maximum growth to /28 for the first /13 pool, we can make up to 32,000 allocations. The second pool, the second /13, we set maximum growth up to /20, and that was -- it can make 128 allocations. So far, we haven't reached to 16 allocations in that pool, so each of the allocations from the second /13 pool can go up to /17 at this stage. Also, we have some additional pools from IANA before we received the /12 in 2006. It is due to some of the large organizations, their IPv6 requirement is larger than a /23, because the IANA allocation block is based on a /23, but some of the very large telcos, like Telstra, need more than that. So IANA will make direct 17 allocation pool to APNIC and APNIC will allocate half of them and reserve 1 bit for those pools. This is some ranges actually outside the /12. We also have a few range inside the /12 which IANA gave to APNIC later on. That is special large allocations to some large members. We also have some ranges reserved for special purpose, like critical infrastructure, Internet Exchange Points, portable assignments, some experimental purposes, and we also have one /32 for documentation, like you can use it for your documents, and we have one /32 for IXP assignments before 2017. Therefore, it is quite interesting that actually it is from RIPE NCC's pool. At the time, IANA was very close and then we shared one of the range for IPv6 IXP. At the beginning, people discussed if IXP should have like some special range or something, so we just share one of the pools. Actually, RIPE NCC is happy to leave that for APNIC and still continue to use that /32. But later on, APNIC actually move out and reserve our own /29 for IXP assignments. That's the basic background information about APNIC's IPv6 pool and practice, and I hope that can help the policy proposal discussion. >>Masato Yamanishi: Thank you. Are there any comments or 18 questions? Can you go back to the second slide. The prop-112 which we will discuss as the next item is trying to resolve this space. >>Guangliang Pan: Yes, the proposal is actually trying to address this range. >>Masato Yamanishi: Let's go to the next item -- APPLAUSE Thank you, Guangliang. Let's go to the next item, which is prop-112, proposing on-demand expansion of IPv6 address allocation size in legacy IPv6 space. The presenter is Tomohiro. >>Tomohiro Fujisaki: Good afternoon, everybody. My name is Tomohiro Fujisaki. First of all, thank you so much to Guangliang to present very, very useful information for my proposal. As the Chair said, my proposal is related to the legacy IPv6 address space that was allocated before 2006. One moment. This is much better than power outage! >>Adam Gosling (APNIC): Excuse me, Chair. May I say something while we wait? Some people may wonder what happened to the single policy document that I've been going on about and presenting every time we meet. I just wanted to let you 19 know that I have done it and I prepared it all to implement today, so everything is dated 5 March. Then there has been a lot of people talking about the specifics of the policy documents as they are at the moment, and I thought if I implement the new single policy document, I may have missed some links. Rather than confuse everyone to do that on the day when everyone needs to get at the documents, it might be better for me to leave it. Just to let you know that it is done and it will be implemented very soon. That's all. We have the presentation now. >>Masato Yamanishi: Adam, when can you present that version? >>Adam Gosling (APNIC): It is ready now. It is loaded onto the website. It is actually also on the FTP site. >>Masato Yamanishi: Okay, let's do that within this month. >>Adam Gosling (APNIC): This week, yes. >>Masato Yamanishi: Let's go ahead. >>Tomohiro Fujisaki: Again, my name is Tomohiro Fujisaki. Today I propose on-demand expansion of IPv6 address allocation size in legacy IPv6 space. >>Masato Yamanishi: Can somebody switch the camera to the screen? It is still showing you. >>Tomohiro Fujisaki: Wow! 20 >>Masato Yamanishi: Do we have anything else? It is a very good chance to discuss about the session schedule. I saw some claim about the schedule in this meeting, actually first session was in parallel with Lightning Talks, and I also don't like that, but as it happened -- originally we planned to use only two sessions, which were the second and third sessions, on Thursday. But after receiving proposals, we found two sessions is not enough, so we added the first session. So that's solely why it was done in parallel with the Lightning Talks. So from the next meeting, I will make sure the same thing will not happen. Thank you. That point, I will make sure. But if you have any suggestion or comment about the session schedule, please send it to the Policy SIG Mailing List or please say it to me directly. Okay, now it's back. We can start. >>Tomohiro Fujisaki: Okay. This is the problem statement of my proposal. As Guangliang kindly presented, IPv6 allocation is something like this. The IPv6 minimum allocation size to LIRs is defined as /32 in their IPv6 policy document. In October 2006, sparse allocation mechanism has been implemented to manage APNIC IPv6 address pool. Before 2006, /29 was reserved for all /32 allocations by sequential allocation method made from those old /32 21 blocks. I think these reserved blocks might be kept unused in the future. So this figure shows here some of the problem statement. Actually, the address blocks /32 allocated up to /29 reserved in these blocks. I propose to modify the eligibility for organizations in the legacy IPv6 address block to extend their IPv6 address space up to /29 by request basis. This is the situation in other RIRs. In RIPE NCC, they already have this kind of policy, and the LIRs in RIPE NCC can get up to /29. This is the status of the allocated blocks. I calculated this data from the allocation data of APNIC. As you can see, our address blocks -- the first address blocks are allocated /32 and all other blocks are currently reserved. All the same as here for the legacy blocks. These are the RIPE NCC blocks and, as you can see, in the RIPE blocks, some LIRs already extend their address blocks to /29 and so on, so they reserve the blocks, and they resolve blocks smaller than the APNIC ones. This is the current situation. This is the proposed policy solution. Define legacy IPv6 address blocks, something like these, and add following text in the policy document: 22 "For existing IPv6 address space holders LIRs that hold one or more IPv6 allocations in the legacy IPv6 address blocks are able to request steps of each of these allocations up to a /29 ..." This is the proposed text. These are the advantages and disadvantages of this proposal. The advantage is just we can use up their reserved IPv6 address blocks. The disadvantage is I think some people may argue this will lead to inefficient utilization of IPv6 address space, but to get to a larger address block it means more maintenance cost, so I do not think it will happen. This is the impact on the resource holders. If this policy was implemented, all NIRs have to implement this policy. Here, this is the policy discussion on the mailing list, and I really appreciate the many feedback on the mailing list. I think three points are the main discussion points on the mailing list. The first point is this doesn't appear to support needs-based allocation, and all this feedback, I think that such space as these are causing each LIRs, and the question of things is the space needs additional maintenance, so it is not -- this is my opinion for that first point. 23 The second point is about the nibble boundaries. Later I explain what is nibble boundary, and the benefit of the nibble boundary, but here I think the nibble boundary operation might be ideal, but nibble boundary allocation might not. I heard on the mailing list someone said that they do not care about the nibble boundary so much. The third point is Owen is against this proposal. He proposed another alternative solution, giving another /8 and wait to use the legacy block. For this point, I think LIRs in the legacy space have used the IPv6 so long time, so it might be difficult to remember the address, and also nibble boundary allocation space might be too huge for this purpose. Next I explain about the nibble boundary. A nibble boundary means subdividing address space based on the address numbering. For the IPv6 address, each number represents 4 bits, so here the nibble boundary means that IPv6 addressing can be done on the 4-bit boundaries, so in this case, the nibble boundary is there between each number. The other advantage of nibble boundary, maybe I think these two points -- please correct me if you have additional advantages -- one point is -- the main 24 point is the operational ease, and one point is the prefix filtering. If we use the nibble boundaries, we can specify the prefix length between each number, so it is very understandable and easy to understand. This is similar to the classful IPv4 address operation, such as the class A, class B or class C. One more point is the reverse delegation. If we use the non-nibble boundary case and we have to delegate multiple blocks to the LIRs, for example, in this case /31, we have to delegate two blocks for each LIR. This is the disadvantage of the nibble boundaries. I think that allocation may be too huge. It shows this here. The first line shows the current subsequent allocation scheme, if LIRs with /32 request another IPv6 address block, they can get one more /32, so they get /31, but the nibble boundary gets /32 LIR will get /28 and then the next is /24, so it is too huge for each LIR. About the advantages, these are almost the same as the current IPv4 operation, so it is higher to use a nibble boundary operation, so we now operate in the IPv4 without the nibble boundary. The summary of my proposal: I propose to modify the eligibility for organizations in the legacy IPv6 address blocks to extend their IPv6 address blocks space up to 25 a /29. Thank you. >>Masato Yamanishi: Thank you, Tomohiro. It is also a good presentation about what is nibble boundary, even though it is not part of your proposal. Is there any comments or questions for this proposal? >>Aftab Siddiqui (Cybernet): Can you just suggest what you have changed from the last time to this version? >>Tomohiro Fujisaki: The last time, I proposed not only for the legacy blocks but also for the -- sorry, sparse allocation blocks to extend all users up to /29. This time only for the legacy IPv6 space, because that space is reserved for the LIRs in that block. >>Aftab Siddiqui (Cybernet): You are suggesting the policy remains the same for the new entrants and for those who got the legacy block /32, and APNIC reserved a /29 for them, they will get the remaining address block? >>Tomohiro Fujisaki: Yes. >>Aftab Siddiqui (Cybernet): On request? >>Tomohiro Fujisaki: Yes. >>Aftab Siddiqui (Cybernet): How is that different from the current policy that is in place? Because you can get that much v6 which is reserved on request from APNIC. >>Tomohiro Fujisaki: Yes, actually, current policy says to 26 get more address space -- to clarify the eligibility criteria, to clear the criteria, so ISP have to demonstrate the usage to obtain a new address. >>Dean Pemberton (InternetNZ): I can hear where Aftab is going with this and I think we agree. So the way that this is different to the current policy is that the applicant does not need to show justified need, does he? >>Tomohiro Fujisaki: Yes, exactly. That point is yes. But for that -- >>Dean Pemberton: You make it very hard for me. >>Tomohiro Fujisaki: I want to hear the community opinion, not the current my proposed policy, but we need to tackle to use this block or not. Actually, I think we take no action, these blocks maybe keep unused in the future. Just I want to know all of you opinion for this point. >>Aftab Siddiqui (Cybernet): Don't remove the demonstrated need. I have been grilled a moment ago. The thing is, it is still possible to get v6 space from that block which you are mentioning right now by showing the requirement. I got my v6 block in 2007. I did everything with that /32 and if I need more, I can get back to the APNIC and I will get it from the remaining space they allocated for me at that time. So it doesn't change anything. Because if I get more v6, 27 SG Asia will change the annual fees for that as well. So it is also linked to that. If I have a requirement, I will get it, I will use it. I may have to renumber to some extent, but that is okay, that is the requirement available right now. I think there is no need to further change what are the criteria mentioned today. Thank you. >>Tomohiro Fujisaki: Thank you. >>Dean Pemberton (InternetNZ): Yes, I completely agree with Aftab. I think I can see your concern that you want these blocks to be used. I think the blocks will be used, and I think they will be used by people that come and request additional space. So when those organizations request additional space, that space will be allocated and it will be used. I think that is completely in line with our current policies around demonstrated need, so I don't think we need to change the current policy. I think, if we did change it along these lines, to remove demonstrated need for this, that it would set a precedent for other policies for us to remove demonstrated need and it may have certain implications for transfers. So I think the space will get used. I mean, you have given this proposal a couple of times, so I can see 28 that you feel passionate about the space not being wasted, and I would like to assure you that I can see that this space will be used by those people but it will be used when they need it and when they can make a justification for it. So that's my feedback. Thank you. >>Tomohiro Fujisaki: Thank you. >>Ajai Kumar (IRINN): It is my personal view that whatever the resource we are giving or delegating to any entity, any organization, these are the public resource, so we should not change the criteria for demonstration-based requirement. If any organization need it, justify it, take it. So we don't support it. >>Tomohiro Fujisaki: But in that sense, these blocks are reserved for the existing LIRs, not the public resource, but they are reserved blocks for each LIR, so I propose this solution. I know the solution is not good, in your opinion, yes. >>Ajai Kumar (IRINN): Whatever the IP addresses are there, these are the public resource. Whatever the legacy IP address are there are the current IP address pool which we are delegating. So I understand that some blocks are legacy, but these are the public resources, in my view. >>Tomohiro Fujisaki: Yes. I want to say the IP address 29 block is public resource. I fully agree. But these blocks are reserved for each LIR. This is current operation also, so just I want to say that. >>Masato Yamanishi: Is there any other comment or question? If not, let's go to asking consensus. I think you want to ask the problem statement itself first? >>Tomohiro Fujisaki: If possible, yes, please. >>Masato Yamanishi: Tomohiro wants to make sure whether the community thinks this problem statement is -- how I can say -- accepted from the community or not, the first item. So can you ask that question on CONFER? The first question is not for the proposal itself. The question is about whether we will leave these three /23s -- >>Tomohiro Fujisaki: One more, but yes, legacy address blocks, we should conduct any action, have action or not. >>Masato Yamanishi: In this question, "support" means, yes, we need to do something for these space. Okay, go ahead, Aftab. >>Aftab Siddiqui (Cybernet): I beg to disagree on this question. I spent 30 minutes in the morning to check if there is a problem statement or not, and that's how it should be done, rather than asking after the policy if 30 the problem is right or not. If the problem wasn't right, it should have been done on the mailing list, not here. I'm sorry. Thank you. >>Masato Yamanishi: But this morning, I also asked whether we will continue discussion or not in that prop-115. I think you are talking about that one; right? >>Aftab Siddiqui (Cybernet): I am discussing about the abuse reporting on the Whois database, which I did in the morning. That was too early in the morning. That's why you don't remember. >>Masato Yamanishi: Okay. I got your point, but what you are against asking in here, I missed that point. >>Aftab Siddiqui (Cybernet): Sorry? You are saying something? I just want to understand. Let me repeat what I just said. I'm just saying that to check with the community if the problem statement is right or not, we present whatever we think is the problem, not the policy. When the policy has been submitted in the mailing list and has been presented in the SIG, it means the problem was there. >>Masato Yamanishi: I got your point. Okay, I got the point. Let me ask -- let me change a little bit. First, I would like to ask the proposal itself as we did it usually. Is that okay? You have changed the question. The first question is the 31 consensus about the proposal itself. Then if it fails, then ask about the problem statement itself. The question about the proposal itself: if you strongly support prop-112, please raise your hand now. Okay. If you support prop-112, please raise your hand now. Okay. If you are neutral for this proposal, please raise your hand now. Okay. I got it. If you are opposed to this proposal, please raise your hand now. Okay. If you strongly opposed to this proposal, please raise your hand now. Okay. I think we cannot say it leads to consensus, so let me ask the second question about the problem statement of this proposal. In this question, "support" means the problem statement is valid or worth to discuss in Policy SIG and "opposed" means it's not worth discussing here. If you strongly support continuing the discussion of this problem statement, please raise your hand now. Okay. 32 If you support for continue this discussion, please raise your hand now. Okay. If you are neutral for continue this discussion, please raise your hand now. Okay. If you are opposed to continue this discussion, please raise your hand now. Okay. If you are strongly opposed to continue this discussion, please raise your hand. Okay. I saw some opposed and strongly opposed. Can I ask the reasons why you guys think it isn't worth to discuss in the Policy SIG? >>Dean Pemberton (InternetNZ): Every time I've seen this come up, even though I can sympathize with the need to feel that these addresses will be allocated, every time I've seen this come up, it goes right to the heart of needs-based allocation, so every time this has come up, it says that we need to put aside needs-based and we need to quickly allocate these out. You know, if that's happened every time, and I can't support that, then I don't think it needs to be continually brought up. Please, tell me a version of 33 this that doesn't do away with needs-based allocation, and maybe. But I wouldn't be opposing it if this was just the first time, but it isn't the first time. >>Bertrand Cherrier (Microsoft): I completely agree with Dean and would like to add that, to me, it's a waste of time. >>Tomohiro Fujisaki: Actually, maybe people don't need this policy, so it's okay not to have this policy. >>Masato Yamanishi: This is the third meeting which we are discussing this topic, even though in previous meetings we discussed a different proposal, but actually we are discussing the same topic, but still we didn't reach consensus. >>Gaurab Upadhaya (Limelight Networks): With all due respect to Tomohiro-san, I think this bring up some good discussion and we got some views, but at this point I think keeping it on the table, I don't think we will ever get consensus. I don't think it really solves an operational or an urgent issue. I would suggest to abandon it. I support that position. We have discussed this. The Secretariat knows about it, the community knows about it. If this becomes a problem again, we can bring it up again. Otherwise, keeping the policy on the agenda because it didn't get consensus, I don't think that's a good idea. 34 >>Masato Yamanishi: That's what I'm trying to say. Regarding this proposal, I abandon this one, but still -- it is true that this space is needed in future, so if you will find a good solution, please proposal it again. >>Tomohiro Fujisaki: Okay. >>Masato Yamanishi: Thank you very much for proposing this one, Tomohiro. APPLAUSE >>Tomohiro Fujisaki: Thank you so much for giving me many feedback to me for this proposal. Thank you very much. >>Masato Yamanishi: The last item is the inter-RIR transfer policy in RIPE region. Actually, it has an implication, so APNIC region and also ARIN region, because right now we have inter-RIR transfer between APNIC and ARIN region requires needs-based, because ARIN policy is requesting so. But it seems that the proposal in RIPE region is different from needs-based. First, Andrea will explain the current situation in RIPE region, then discuss about that later. >>Andrea Cima: Good afternoon, everyone. My name is Andrea Cima. I'm part of the RIPE NCC. As Masato just mentioned, I'll give you a little bit of history and I will give you an update of the current status of the inter-RIR transfer policy proposal in the RIPE region. 35 The aim of the policy proposal is to create a framework which allows organizations in the RIPE region to transfer resources to or from organizations which are in another RIR region. Now, there have been a number of versions of this policy proposal so far, but each later version tried to fix something of the previous versions. We had three versions. The first one was published in May 2014. This is already almost a year ago, quite some time has passed, and it was presented in RIPE 68. What was the content of this first version? It introduced a general framework for inter-RIR transfers. Why do I say "general framework"? Because if this policy proposal reaches consensus, it will allow inter-RIR transfers for all the Internet number resources that are covered by intra-RIR transfers. Just summarizing what does this mean, if tomorrow the RIPE NCC will get a transfer policy in its region that allows you to transfer AS numbers, the inter-RIR transfer policy would cover this in AS numbers as well. One important point of this first version was, as well, that it gave the mandate to the RIPE NCC to fulfill any requirement that the sending RIR had. Now, this first version was discussed on our mailing list, there were 19 postings from 10 people about it. 36 There was quite some support. There were a few requests for some wording improvements. First of all, the policy was referring to LIRs, not to resource holders, which means that holders of provider-independent resources would not be able to fit under this policy. Then there was a suggestion to remove references to legacy Internet number resources because legacy Internet number resources are referred to in a separate policy document. Some of the feedback received was taken into consideration. The author published a second version of the policy proposal. As you can see, this was in October 2014, so it took quite some time to get to the second version. But the main reason also is that not only the changes had to be implemented, but also the RIPE NCC did an impact analysis of the policy proposal. By impact analysis, I mean a staff assessment, to explain RIPE NCC's understanding of the policy and to outline the impact of the policy proposal. The author replaced the term "LIR" with "resource holder", allowing also providing independent resources to be part of the policy and removed the reference to "legacy resources" from the main IPv4 allocation and assignment document, as legacy resources are handled in a separate legacy policy. 37 The impact analysis of the RIPE NCC included the RIPE NCC understanding of the policy, mainly that the proposed policy would apply to IPv4 PA allocations, IPv4 PI assignments and legacy resources and the fact that resources transferred to the RIPE region cannot be retransferred to another organization within 24 months, because that is what the current transfer policy in the RIPE region says. We went a step further than what we would usually and we contacted the other RIR Secretariats and asked them, "This is the policy proposal. Do you see any issues with it? Do you see compatibility issues with your policy when it comes to inter-RIR transfers?" Both RIRs that have an inter-RIR transfer policy in place, meaning ARIN and APNIC, confirmed that their policy requires a needs base in order to do inter-RIR transfers. If we go a little bit more into details, ARIN staff noticed that the policy proposal did not include explicitly a need justification and therefore, they deemed the policy proposal not compatible with their policy. When it comes to the APNIC Secretariat, we received a confirmation that also according to them, the needs base was implicit but it was not explicit therefore they could not take a position on this and that 38 a consultation from the community would be set in place during the APNIC Meeting. This is what Adam did during the last meeting in Brisbane. Now, after this publishing of the policy proposal and the impact analysis, there was some more discussion on our mailing list and at the RIPE meeting, there were 31 postings on the mailing list. Most of the focus on the mailing list was about how can we achieve compatibility with the needs-based principles of the other RIRs? So the author worked on a third version, which was published now in January. We published at the same time the impact analysis of the RIPE NCC, again the updated version of it, and the current policy text tried to address the compatibility with ARIN and APNIC's policies. The author introduced needs justification from RIRs that require the receiving region to have needs-based policies. In practice, what does this mean? If an organization in the RIPE region would like to transfer resources from either ARIN or the APNIC region, the recipient must plan to use at least 50 per cent of the transferred resources within five years. They will have to submit a plan to the RIPE NCC. The RIPE NCC will have to evaluate this plan. 39 We did a new impact analysis. In the latest version of the impact analysis, the RIPE NCC's understanding, I think the most important part is the second one, that we clarified that the party that receives the address space in our region must have at least one active networking element located in the RIPE NCC service region. We checked the compatibility again with the other two RIRs' staff involved, and both RIRs confirmed that the proposed policy is compatible with the inter-RIR transfer policies, as the needs-based justification was explicitly stated. APNIC, however, added that it would hold a public consultation at APNIC 39, where we are now, in order to check with the community if there were any remaining areas of concern with regards to this policy. What is the current status? I start with the last point. The address policy Working Group Chairs in the RIPE region declared rough consensus for the policy proposal and the policy proposal will enter last call on 5 March, so in a day or two. At that point, there are four weeks left. In these four weeks, if there is no strong opposition, the policy proposal will reach consensus and will become policy. Overall, we have about 60 postings on our mailing 40 list plus the participation in the RIPE meetings. There was only support in our region, no opposition. That is quite interesting as well, there are currently two policy proposals in our region for allowing IPv6 and ASN transfers within the region and if all three policy proposals reach consensus, then also AS numbers and IPv6 would become part of the inter-RIR transfer policy. So this is the status of the policy proposal. Are there any questions? >>Masato Yamanishi: Thank you, Andrea. Before going to the discussion, I would also like to ask about the current understanding of this RIPE proposal in the ARIN region. Einar, can you explain that? >>Einar Bohlin (ARIN): We started working hard on this, this week, to look at the text and determine whether the RIPE proposal is compatible with the ARIN policy. So far, I'm hearing back from the office that it is, it does appear to be compatible, so that when this goes through the path that Andrea described and it gets adopted and implemented, it does appear that ARIN will be able to do transfers with the RIPE region. >>Andrea Cima: Thank you. >>Masato Yamanishi: Thank you. Sanjaya. >>Sanjaya (APNIC): If I understand this correctly, then 41 RIPE's likely approved proposal is as long as the sending region requires needs-based then you would apply need-based but if the sending region does not require needs-based then you won't apply needs-based. Is that correct? >>Andrea Cima: That is correct. >>Sanjaya (APNIC): As we all know in this community, APNIC's outgoing plans for other RIRs, we do not specify that it has to be needs-based, it is actually simply saying if it is going out from APNIC to another RIR, then we will follow whatever the other RIR has, the policy that they have. My question now is actually to the ARIN community, the representative here, if someone could come up. I know this has been asked before and I just want to be on record here in the APNIC Meeting. The question is: if the transfer within APNIC and RIPE, from APNIC to RIPE, is not needs-based, would that affect the transfer from ARIN to APNIC which now is working fine, because we apply needs-based? So that's the question I would like to ask ARIN. >>Einar Bohlin (ARIN): ARIN has a policy for inter-RIR transfers with other RIRs, with one other RIR. We have a compatible policy with APNIC, we can do transfers back and forth. If we get a compatible policy with RIPE, we 42 can do transfers back and forth. ARIN does not have policy regarding the relationship between RIPE and APNIC. So we don't have -- there is no policy text in our policy manual regarding that relationship. There could be in the future but there is no such thing at this time. >>Masato Yamanishi: Andrea, can you go back to slide 10? I think this one is talking about transfer from APNIC or ARIN to RIPE region; right? >>Andrea Cima: Yes. What I wanted to mention with this slide is that the intention of the third version was to fix the fact that the justification of need was not explicitly stated, and this part is introducing the needs justification in an explicit manner, in that if the sending RIR requires the receiving region to have a needs-based policy then the recipient, the recipient in the RIPE region, must send an addressing plan, must justify its request to the RIPE NCC, as we would evaluate their addressing plan, and they must show that they will use 50 per cent of the transferred resources within five years. >>Masato Yamanishi: How about the transition from RIPE to APNIC? >>Andrea Cima: There would be no -- >>Adam Gosling (APNIC): It would be assessed on our 43 criteria. >>Paul Wilson (APNIC): I think it is worth explaining the current status of the interregional transfer policy and how we will implement it at APNIC with respect to new regions that come along and are potentially able to exchange with us. There are two things. I will explain an EC decision, which is one that I put to the EC some time ago, and I want to explain why they made -- why I believe they made that decision. I think it is something where I will give my understanding of events, but of course APNIC EC members might like to add to it. The current situation of APNIC and ARIN having compatible operating inter-RIR transfers underway is well understood, it is resulting in 10 or so transfers per month, mostly, all but one from ARIN to APNIC. I think we all know the long history behind the achievement of compatible inter-RIR transfer policies which allow to us do those transfers with APNIC and ARIN, and one of the requirements from ARIN that was expressed many times during ARIN policy development, and that appears to underlie the ARIN policy, is that transfer should not be made to another RIR that does not have a needs-based policy framework. Now, that's not really exhaustively defined, what 44 would be a needs-based policy framework, but judging from the potential interpretations that were discussed over a period of time, there seems to be a risk that if APNIC is able to transfer from APNIC to another RIR which does not have overall a consistent compatible needs-based transfer, then that also undermines the consistent needs-based status of the APNIC policy framework as a whole. So if we start interchanging address space with another RIR region which does not have a consistent framework then that actually brings our own framework under discussion or under doubt in terms of being consistently and entirely needs-based. This is an interpretation of ARIN policy, and I know that we have had advice from ARIN staff about their interpretation of ARIN policy, but given the APNIC region's dependence and current activity in terms of receipt of transfers from the ARIN policy, there appeared to be a risk until the RIPE policy was approved and in place that we could somehow potentially threaten the APNIC-ARIN relationship by enacting transfers with RIPE immediately that policy came into place, which would be the default. Under our current policy, as soon as RIPE's policy is approved and goes into place, we could potentially be making transfers. 45 My advice to the APNIC EC was that until we know exactly what the RIPE policy is and until we understand what the implications would be, then for us to immediately embark on interregional transfers with RIPE under the circumstances could potentially threaten the existing framework that we have and the existing operational transfers with ARIN. So what I proposed and what the EC did was to enact a moratorium on those transfers, so they would not immediately start when the RIPE policy is in place and would allow the APNIC EC to have time to consider that situation. The outcome of that long story is that when the RIPE policy goes into place, we will not be immediately answering transfer requests. We will need to go to the APNIC EC and have them consider and lift that moratorium. The moratorium was put in place some time last year, reported to the Brisbane meeting, and it was just in the last week reconsidered, and the EC has extended the moratorium again, until we know exactly what is happening with the RIPE policy. We hope that is clear enough. Providing we don't sort of feel there is a problem when the policy goes into place, it should not result in any extended delay in the potential transfers 46 between APNIC and RIPE NCC, but there will be some delay at least. I hope that is clear enough. I'm very happy to answer any more questions or have other EC members add to what I've said. Thanks. >>Masato Yamanishi: To summarize this proposal in the RIPE region, it will not stop transfers between APNIC and ARIN, since they are trying to add needs-based. However, APNIC doesn't have any requirement for recipient region, while ARIN has a requirement for that, which says that the recipient region should have needs-based. In future, the transfer policy in other regions may cause negative implications to APNIC. Is that a correct understanding? >>Paul Wilson (APNIC): Yes, I think that's right. I think we have three different policies in place here, which have not by any means got identical terms defined or identical interpretations. So what we are looking at is just the potential for a sort of incompatibility that has to be clear enough. It is no offence to the ARIN staff at all that we didn't feel that the ARIN feedback was enough to satisfy that, to avoid that risk entirely. It probably just needs, again, a reconsideration by the EC when the RIPE 47 policy is active and possibly also a discussion at the ARIN community about it because, again, the RIR staff are very determined in asserting that they do not make policy, and the policy authority is the community. While ARIN was comfortable, we didn't want to see a situation where suddenly there was a furore over some different interpretation of the policy, which again would have affected our existing operating transfers between ARIN and APNIC. >>Aaron Hughes (ARIN): Thank you for the consideration and care. The only other notable point is that this discussion was brought up in Baltimore at the last ARIN meeting. The rough community feedback was that this seemed to be perfectly acceptable and that there wasn't a lot of feedback, to be honest. So I don't expect to see a wild reaction from the community to try and stop anything, based on what was discussed in Baltimore. >>Masato Yamanishi: Thank you. Adam, do I ask anything to the community? Maybe not. >>Adam Gosling (APNIC): I just wanted to make sure that the community is aware of the latest update. It looks like the RIPE proposal will probably go ahead. >>Masato Yamanishi: It looks like it doesn't affect 48 anything in the APNIC region. >>Adam Gosling (APNIC): I guess it comes down -- the next move is in the hands of our EC. Presumably, this RIPE proposal will go ahead and reach consensus and be implemented by the Secretariat there. It seems that the ARIN Secretariat will be happy to do transfers with the RIPE NCC at that point. Our situation will be, we currently transfer back and forth to the ARIN community and our Executive Committee has put a moratorium on transfers to RIPE, but they will then review that at that point. So I guess the ball is in their court. I guess that will come down to what the EC thinks. From the position of the SIG, our other alternative would be to, if we wanted to secure transfers with the RIPE region, change our own policy to require needs-based recipients in the RIPE region. Then the structure of the transfer would be similar to the ARIN-RIPE transfer. I hope that makes sense. We could make all of this go away by changing our transfer policy to say when we transfer out of region, needs must be assessed. Or we could do nothing and see what the EC does next. >>Masato Yamanishi: Is there any other comment about -- especially handing out to the EC. 49 It seems not. Okay. We would like to proceed with this one as what Adam suggested. Thank you very much for presenting this one, Andrea. APPLAUSE >>Masato Yamanishi: This was the last topic in Policy SIG. I would like to thank everybody for proposing proposals and having good discussion and cooperating on time management. Thank you very much. See you in Jakarta at the next meeting. Thank you very much. APPLAUSE