Transcript - Policy SIG Session 3 (Open Policy Meeting: Thursday 13:30 - 15:30)
While every effort is made to capture a live speaker's words, it is possible at times that the transcript contains some errors or mistranslations. APNIC apologizes for any inconvenience, but accepts no liability for any event or action resulting from the transcripts.
Andy Linton: Thank you all for coming back after lunch. I suspect we might get a few more people come in.
We finished off the session just before lunch with the slides that Masato had presented, which were there are some discrepancies between the SIG Policy guidelines document and the PDP document.
I have a few sort of slides, observations, you know, of things we have actually looked at and talked about among ourselves and with the Secretariat about bits and pieces we might look at fixing.
These again, I stress, are just suggestions at this stage, these are not proposals that we're going to formally make a decision about. This again is for information and then hopefully, we can agree or we can move on with this, as we look perhaps at some changes at the next meeting in China.
Just some background on this. It sort of fits in a little bit with what Adam has said about the editorial policy.
The current process has been in place for 10 years. We haven't had any changes since then and we have some concepts and terms that aren't in use and we have some new stuff that isn't covered and so on. Importantly, we don't have parallel discussion in other SIGs.
The PDP should be a high-level document, with exact procedures being in the SIG guidelines, where the Chairs and the community can actually easily change that without coming back to a very formal process. We should be able to include new expectations in the PDP. This isn't talking about any changes in the people concerned, the actors or the workflow or the timing in the PDP and there's a caveat there, saying except the requirement to obtain consensus in the member meeting, APNIC Member Meeting. I'll talk a little bit about that later.
One of the things we want to make sure in these documents is that the policies are developed by all stakeholders, that's what our process is and that's what our policy actually sets out. It's not just APNIC members. So it's for the whole community and I know that's sort of, you know, sometimes hard to think exactly what we mean by that, but it means that anyone can contribute to the process and help make the decisions.
The policy is developed in the Policy SIG. That includes the mailing list and in person and on line. So it's not just at this meeting, it's in the Policy SIG, on the mailing list and so on.
In our current text, there are places where we refer to "meetings". So it's important for our documents to actually reflect the fact that the thing is wider than that.
One of the other changes we think needs to be documented and covered here is that the PDP is used for all changes. So it's not just substantial changes, because you get into real difficulty with what do you mean by "substantial"? Is it very substantial or a bit, you know, hard.
So again, some definitions. APNIC policies should be followed by NIR and account holders. The current text is APNIC members and Secretariat. That's just some tidy up in there that we want to see done.
We want to see mention that the PDP Chairs or the Chairs are democratically elected members of the community. Currently it doesn't say anything about that at all in the document. They're responsible for those activities and deciding consensus and the idea that the community decides who they are needs to be in there.
Adam, I think these top three we were going to delete, weren't we? The Open Policy Meeting one.
Adam Gosling: Yes.
Andy Linton: This first paragraph here about Open Policy Meeting, ignore that. That was supposed to have been edited out, because we do want to keep talking about the OPM.
One of the things we want to tidy up in the proposal process is that proposals can be submitted to the Policy SIG Chairs at any time. There's nothing there that says that's clearly possible. You can go out of this meeting or you can do it now if you like, and propose something to the Chairs right now and it won't get discussed till later, but you can do that at any time and we want to make that clear. And encourage the idea that proposals should include clear problem statements and specific solutions. That locks in with the thing that Adam has talked about this morning, with the changes to the template. We don't want to spend time discussing vague problems and vague solutions.
It's up to the Chair to set the timeline for the submission of a formal proposal to the list and so on. We have that four weeks laid down of discussion on the mailing list, but, for example, our take on this is that at the next meeting, for the next meeting, instead of being the four-week deadline being published, we'll say the Chairs would like the proposals six weeks before the meeting, that gives us a few days or even a couple of weeks to work with authors, proposers, to make sure we have things right and that we then can get it up on the mailing list, so we can have four weeks discussion.
It has been difficult for the Chairs, both I think probably us and for previous Chairs, if you get a document at 5 to midnight and there's four weeks discussion period, there's no chance to say: is this really what you want to do? Is this really the thing, and so on.
Our main goal here is just to get the process so that it makes life for us a little bit easier and we don't think that that should cause problems for proposers.
We want the PDP to make reference to the Policy SIG guidelines document. We have things going this way, but not that way.
The Policy SIG document should be the one that actually has the fine detail of this is what's going on. These are the timings and so on.
Also, note that Chairs are responsible for determining consensus. Currently it's the Chair with help from the Co-chairs and we think really it should be -- it's not a one man show. It's the team of us. But, you know, there's probably -- there's still the final arbiter that if all comes to the bit, the Chair has to make the decision, but it's more inclusive in that.
We also have felt in the past that when you're sitting up here and there's an issue which has had vigorous discussion and so on, it's actually pretty hard for the two or three of us, depending on who's here, to look at each other and say, "Well, what do you think?" Okay. The spotlight is very much on you and sometimes we think it would be useful for us to say, "We'd like a few minutes to think about this."
So we want to formalize that and say -- we won't always do it, if it's clear, then we can just carry on, but the idea that we can sit down and say we want to have five minutes, ten minutes or even longer to discuss this. We want to get the decision right, rather than be in the glare of the spotlight, making a call right then.
This last one on here is probably one of the most important ones. The decision is made by the community. The decision isn't made by the APNIC members. So when we go to the AMM meeting, it's effectively or it appears to be like some sort of rubber stamp exercise. It's, yes, okay. But it's actually the members then in effect have a veto over the community. What we want to see happen is or what we're proposing, we think is that that is no longer required. We have a robust process here. We make the decision. We report it to the AMM and then it goes on to the last call process.
We want to change the name of the last piece of this to be "Last Call". That makes it different from the editorial comment period, which happens a little bit later and we think it would be good to reduce that to four weeks.
Dean asked about that this morning, and there's your answer, Dean: four weeks. Our observations on this is that if we were to have something that was being actively discussed four weeks after one of our meetings, then we clearly wouldn't be at consensus. I think it's as simple as that. If we were still going at it four weeks afterwards, we would not have consensus. Four weeks is plenty of time and I think, you know, eight weeks out, you could be at the position where you're going, what did we talk about? You know, you forget what the discussion was about anyway.
Then the step after we reach the end of the last call period, if we still have maintained consensus, then we pass this to the APNIC EC and they confirm that consensus. So they say the process has been followed properly, we have reached the decision properly and they confirm that and so on.
One of the other things we want in here is the notion documented that substantial objections can be sufficient to break consensus. We want to get that documented, because it's not clear in there. By "substantial objections", that doesn't necessarily mean all objections. It means objections that really have real meat to them. What this is there for is to say that we all, in good faith, went through a discussion, thought about it, said something, we want to be at the position where somebody can put their hand up and say, have you thought about what happens in this situation and everybody can go, "Oh, no, we didn't think about that." That's a real thing that breaks everything.
I am slightly out of step there. The last stage of this here is this Executive Council review and we ask the EC, the Chairs ask the EC to implement the policy and of course the EC retains the right to ask us to come back and think again, so that we have a safeguard there that says, "Perhaps you didn't think about this" or, you know, it's not "no", it's "think again". So it's a bit like the process many of us have in the parliaments, where the upper house can ask the lower house to think about this again and come back. So that's the idea.
Then the EC will work on an implementation timeframe and those are our sort of process steps in there.
Those are the things that we have, and that's the lot of them.
Those are the things that we think we would like to put in front of you those are the things that if we discuss these on the mailing list and between now and next time, that we would like to get into some sort of proposal. If the community wants to do something different, well, that's what the community should do and that's fine. So that's us putting those ideas in front of you.
I appreciate the real meat of what we're doing here now is the two proposals and we had some discussion on this topic before lunch, but are there any further comments on any of those?
Dean, you don't have to, but, you know ...
Dean Pemberton (InternetNZ): I'll leave most of this to the mailing list. I think that's a far better use of time.
One thing I just wanted to clarify was around step 4, if we could just have that back up on screen.
Andy Linton: This is about the last call part.
Dean Pemberton (InternetNZ): I just wanted to understand the difference between there being consensus and there being a last call and there being a significant objection and then the community deciding that they may want to remove the consensus and have another think, versus there being consensus and there being a significant opposition and then the Chair and the Co-chairs deciding that that was enough to come back on consensus.
It may not have changed anyone else's point of view except that one vocal person and, that sounded different to the example you were giving, where you said the community then may want to have another think. That's cool, but that's the community deciding that they're going to withdraw from consensus.
Andy Linton: Okay. I'm just trying to think this through, you know and you're pinning me there.
My interpretation here, and we probably want to try and make this clear --
Dean Pemberton (InternetNZ): Yes.
Andy Linton: My interpretation here would be if we have gone to last call and someone raises what appears to be a substantial objection -- and I would need to talk with the other Chairs about this. But my feeling on this would be we would be looking for agreement from other people in the community that that was a valid objection. So it wouldn't be just enough for someone to say, "Oh, I don't like that and here is why" and then that breaks consensus. I would have to be seeing other people saying, "No, you're wrong" or, "Yes, I agree".
There's no way we want to be in a position where someone has some sort of right of veto there.
Dean Pemberton (InternetNZ): That's what I'm looking at, yes.
Andy Linton: I think that's what you're driving at?
Dean Pemberton (InternetNZ): That's what I'm driving at, that we have come to the last call, someone comes forward and says, "No, that's it. I have had a think and I really hate this. And here is all the reasons and I believe these reasons are valid," and somehow that undoes a consensus of the rest of the --
Andy Linton: No. I think we would be looking for --
Dean Pemberton (InternetNZ): A material change in consensus, following someone's strong objection.
Andy Linton: Yes. I think the other thing, our consensus process is very clear that it talks about most people, you know, none of this is black and white, and that's why judging consensus can be quite a difficult thing, I think.
Dean Pemberton (InternetNZ): Yes.
Andy Linton: You know, it's not a case that a member says, "Well, I object very strongly to this," and everybody else says, "Well, you're wrong." That is still consensus, I think. Or even if most people say, "No, that isn't right." So we're not looking for a very vocal minority with strong opinions being able to stop the process.
Dean Pemberton (InternetNZ): Okay, cool.
Andy Linton: Adam.
Adam Gosling: The rules around what determines consensus are in the SIG guidelines.
Andy Linton: Adam is pointing out to me that what's in the PDP is very high level. In the SIG guidelines we have, we are not actually looking to change any of that, we are just saying there is a consensus process and this is just picking out the main topic headings about it and the important things. The guidelines are where we could negotiate the details of that.
Any other comments or questions? We can move on.
According to the clock that's down here, I have no seconds left, so that's just about right.
We have two policy proposals in front of us. I'm going to go back over here and deal with them from over here. We have prop-105 and prop-106 and I need to go back over here and look at the text to see what the exact titles are, or Sunny can put them up for me.
Our first one is "Distribution of returned IPv4 address blocks", and Tomohiro-san is going to come and talk to us about that. Then we'll have some discussion on it and then we have our prop-106, which is "Restricting excessive IPv4 address transfers under a final /8 block". Tomohiro, thank you.
Tomohiro Fujisaki: Thank you, Andy. I'm Tomohiro Fujisaki, Japan IPv4 address allocation discussion team. Here I speak about prop-105, distribution of returned IPv4 address.
In this policy, we propose to modify the prop-088, which we, the APNIC community, discussed a few years ago.
After final /8 policy is implemented, IPv4 address blocks received by APNIC are handled as being part of the final /8 pool. The resources are distributed according to the final /8 policy. Here this is in the prop-088 and we propose to modify this prop-088 to distribute the returned IPv4 address space to APNIC to APNIC account holders.
This shows the current IPv4 allocation policy. We are now using final /8 policy to allocate IPv4 address. In this policy, APNIC account holders can get maximum /22 and same policy applies for the distribution of the returned IPv4 address space to APNIC and reallocation to APNIC from IANA. This is prop-088.
However, we think that situation around that IPv4 address has changed recently. One reason is new global policy was ratified by ICANN board and will be implemented soon. This is a global policy for post-exhaustion IPv4 mechanisms by IANA.
This global policy defines a rule to re-allocate returned IPv4 address from IANA to the RIRs. Some RIRs, ARIN, RIPE and APNIC, already returned their historical IPv4 address space to IANA and, if my calculation is correct, APNIC will receive about /10 with this policy.
Also, APNIC has returned pool, thanks for APNIC Secretariat for providing me this information, and APNIC now has about /13 IPv4 address in the return pool.
So here we propose to modify prop-088 to distribute non-103 IPv4 address blocks to APNIC account holders. Here, 103 address block is the final /8 block. So non-103 IPv4 address is returned IPv4 address to APNIC and reallocations to APNIC from IANA.
This is how to distribute such address. The first point is who can apply for this address block. With our proposal, APNIC account holders who have already got one /22 from final /8 block and if they need more IPv4 address, they can apply for this address block.
The distribution policy is the second point, and we propose that the same policy as final /8 policy will be applied in terms of the criteria and the size of the distribution.
The third point is the schedule, and we propose that this policy will be effective after allocation of the returned IPv4 address block from IANA.
Here is a summary of our proposal. Currently, these all blocks are distributed with the final /8 policy. Here we propose to distribute the non-103/8 block to the APNIC account holders.
These are advantages and disadvantages. The advantage is this policy is able to utilize the returned IPv4 address space. The disadvantage would be adopting this policy will discourage IPv6 deployment, but based on our survey, I describe later, majority stated that this policy does not impact their IPv6 deployment.
This is the summary. We propose to modify prop-088 to distribute returned IPv4 address space. Here is the criteria we proposed.
The next few slides we show some information related to our proposal. The first one is the delegation status of 103/8 address block. Thank you again to APNIC Secretariat for providing this graph. As you can see, if the current trend continues, the final /8 block continues to allocate since 2030.
Next few slides show the survey result. Actually, we want to make sure that there is a need for this policy, so we conducted survey to APNIC members and JPNIC members. This is overview of our survey. The survey period is two weeks for each region. And for the survey in the APNIC region, the target is LIR and APNIC and APNIC community. In the JPNIC case, we conducted the survey LIR under JPNIC management. We got total 150 responses.
These are the questions we ask the members. We ask six points like this. For example, if this policy is available, you apply for the address or not; and the use of the IPv4 allocation; the impact for the IPv6 deployment plan and so on.
This is the summary of our survey, survey result. The first point shows that about 70 per cent replied they will apply if this process is available. The second point shows members who "will apply" had higher percentage of IPv6 allocation. And 86 per cent responded that they did not have any impact to their IPv6 deployment plans. About 70 per cent is in favour to revise current IPv4 distribution policy.
The last point is about 40 per cent think that even if they got /22 or less is useful, if they can get more IPv4 address.
This slide is the detail of this survey, so if you have interest, please refer to the below data.
This is the end of my presentation. Any comments or questions?
Andy Linton: Thank you for presenting those notes and the statistics. Are there any questions about this or any comments?
Izumi Okutani (JPNIC): I just want to add a little bit more of background information about what Fujisaki-san has presented.
There has been some discussions within our Japanese policy community about: what is APNIC going to do with all the returned address space? They're aware that people who still need address space can receive it through transfers, or the whole direction should be IPv6 deployment. But in reality, even if you want to deploy IPv6, people still continue to need IPv4, and if there is address space sitting in APNIC pool, or same for JPNIC, our community felt that this wouldn't be a barrier to v6 deployment. It's just a parallel, like transition phase, that if there is some additional address space available, then you should make it available to the community. So that's why Fujisaki-san is bringing this up.
From my understanding, what you mentioned was based on the expected pool that will be APNIC's pool, which, adding up IANA's reallocation and APNIC's return pool, it's going to be about 4.7 million address spaces. So if you divide that by, for example, the number of APNIC members, then I think that will be sufficient to distribute a /22 per member. That's the motivation behind Fujisaki-san's proposal. Just additional information.
Tomohiro Fujisaki: Thank you so much.
Andy Linton: Can I ask you, when you say that is approximately a /10 or thereabouts, we think, is that the number? That's what the slides have --
Izumi Okutani (JPNIC): Is that right?
Andy Linton: That the return pool should be about a /10.
Izumi Okutani (JPNIC): A /10 and a /13, right?
Andy Linton: Okay, it's 10-plus, yes.
Tomohiro Fujisaki: 10-plus, I think, yes.
Izumi Okutani (JPNIC): I think it's about 4.7 million, in terms of number of hosts. That's my understanding.
Andy Linton: Thank you.
Tomohiro Fujisaki: Plus means small.
Andy Linton: Yes.
Tomohiro Fujisaki: Minus, yes.
Andy Linton: Any other comments on this?
Dean Pemberton (InternetNZ): It is a hard problem. I'm internalizing a very complex situation.
For me, what it boils down to is how likely is this to be a problem that we're going to need to solve? A perfect slide to have on the screen, "roughly a /10". Is there any more information that you can give to how likely is it that we're going to need to deal with that /10 or are we going to put forward this policy and we're going to be squabbling over a /19?
Any information you or anyone else in the audience can give us to know when and how much, that would really help me to understand whether this was a policy we needed or whether this was a policy that we may not need quite now.
Andy Linton: Is there anyone who has that information? Anyone got the really good crystal ball here that they can tell us what the answer is?
Izumi Okutani (JPNIC): I think it would be better to have confirmation from APNIC Secretariat, but the calculation is based on the actual pool that has already been returned from each RIR to IANA and then divided by five. That's already been returned, so if the global policy will be implemented without any changes, then it's pretty sure that /10 will be allocated to APNIC. An additional /13, those are the numbers that APNIC Secretariat has given us on what's already been returned, so, yes, these are real numbers that we can probably think as a realistic size.
Andy Linton: My understanding is that there is a trigger mechanism in that global policy that says when that return happens. It's not just a question of the global policy being agreed. My understanding -- and again, I would like clarification for everybody here -- is that when one of the RIRs gets down to a /9, this gets triggered? I'm seeing nods here.
The question then is if you look at the graph that is in these slides, that's somewhere about 2020 in our case. What's the situation in the other RIRs?
Izumi Okutani (JPNIC): Our assumption is -- well, I think Tomohiro-san mentioned maybe somewhere around the middle of next year, when ARIN runs out.
Tomohiro Fujisaki: Maybe, yes.
Izumi Okutani (JPNIC): Somewhere next year, maybe, according to the projections, but it's hard to tell. It doesn't mean like 10 years from now. That's our assumption, I think.
Tomohiro Fujisaki: Actually, APNIC and RIPE has a final /8 policy, so maybe ARIN will ... a /9, I believe, yeah.
Andy Linton: Perhaps we could ask John. I don't know if you could comment on this, John Curran, of if you have any idea of when ARIN will hit the last /9, or again is your crystal ball as good as the rest of us?
John Curran (ARIN): There's a gentleman from this region who is very good at doing forecasting; his name is Geoff Huston. Some of you are aware of him. I don't see him in the room. His last curve for ARIN says that we hit 0 in the summer of 2014. We are currently at 2.68 or 2.69 /8s.
I can't tell you whether it's linear or not, or could you extrapolate, but that says probably by the end of the year, we're in our final /8, somewhere right around end of this year/early 2014.
So recognize -- and I say this every time I give a date that's not today -- this is based on a small number of discrete events. There's a handful of providers, no more than two or three dozen, who, if they come in, this will run out very quickly and if they don't, it will last a long time.
So you're literally trying to extrapolate a date which is affected by things as simple as a single engineer's vacation leave. So it's very hard to know, but I will tell you right now, on a linear extrapolation, end of the year.
Andy Linton: I think that's very useful information for us, given the caveats you have put on that. So it lets us think that we could need this policy or this could be something that we have to think about within 12 months, that sort of timeframe.
Dean Pemberton (InternetNZ): Okay, so we're looking at about a /10 and those numbers are, you know, we know where those are going to come from and they have already been returned. We're looking at maybe caveat, caveat, caveat, by, you know, end of the year, maybe end of next year.
I support the idea of people being able to get another go at this for network blocks of about that size. In terms of the policy proposal and how it would actually be implemented, I would like to look at that in a little bit more detail, because even if we said that that /10 would allow everyone to get another go from that /10, it doesn't tell us what happens next time. Next time maybe there's another /10. Awesome. Well, then we could allow people to have a go out of that. What happens when a /16 turns up? Or are there minimum sizes that would be handed back?
Given that I support the intent of the proposal now, let's start talking about how the wording would need to change and what would actually happen.
Is this another bite of every block that comes back? Is this APNIC, you know, establishes another range and then when they get to be so big, we can allow another bite? Let's start talking about specifics, so we know that we're agreeing to.
Masato Yamanishi: It's also a point which I want to make clear, I think reallocation from IANA may become multiple times. So if in second case, how you want to handle that additional space?
Tomohiro Fujisaki: Actually, at this point, at this time, I only assume that the only one time application to final /8 ...
Masato Yamanishi: I think we have two choice. Additional return should be handled in same pool, so it means members can get second /22, but even though IANA returns third time or fourth time, there are no additional space.
Another choice is once IANA returns some space, member can get third /22 or fourth /22, like that. I'm talking about just possibility, not my preference.
Tomohiro Fujisaki: I think we are not sure how much space will return from IANA. This time we will have the /10, but next time how much space APNIC can receive, we are not sure. I personally think it's difficult to allow the multiple times allocation, as you mention.
So if IANA give APNIC more space, so it's possible to discuss again and to allow more time allocation.
Masato Yamanishi: I think Dean's comment, is based on different option, right?
Dean Pemberton (InternetNZ): Yeah, I would rather not go to all this trouble to put forward or endorse a policy which was for a one-off event and we were unsure about whether this was going to fit for next time and all that. If we're going to go to the trouble to sort this out -- and it does sound like it's an important problem; 70 per cent of people want the stuff -- then let's actually work it out.
So let's say, all right, if a block from IANA comes back and it's larger than this, then we set up another pool and people get another bite at it. If it's smaller than this, then we keep them and they go into a growing pool until they get to this and then people get a bite out of it.
Then we don't need to come back and discuss every time IANA decides to give us some addresses, with the caveat that I don't think that's actually going to be all that often. But let's actually get the policy right the first time, rather than discussing this every time it looks likely.
Andy Linton: So is there some arithmetic that we can do here that says the number of members times a /22 equals?
Dean Pemberton (InternetNZ): Yeah, can someone do that? I haven't got a calculator on me and I'm bad at maths.
Andy Linton: Can someone from the Secretariat just give us a raw number here of how many members? Izumi is asking.
Izumi Okutani (JPNIC): I suppose we don't have to fix a specific number, as long as we just define that /22 times the number of APNIC members at the time of the redistribution.
Masato Yamanishi: Actually, it's not APNIC member, it should be APNIC account holder.
Izumi Okutani (JPNIC): Yes, right, I agree. I think it's better rather than just defining a fixed number, based on the number of account holders at this stage. That's my personal suggestion.
My suggestion for revision would be when the amount of IP address is sufficient to accommodate a /22 for each of the APNIC members, then we will do the redistribution.
George Michaelson: As a point of information, for purposes of this behaviour, if you are including non-members and members as participants in the process, it's 4,000, which is to 2 to the /12 -- so a /22 minus the /12 takes you to a /10.
Andy Linton: Could you just clarify that for me? Sorry, my old duffer ears didn't catch that. Are you saying a /10?
George Michaelson: Yes, because 2 to the power of 12 is 4,000. So you subtract the 12 from the 22 and the difference is 10.
Andy Linton: Yes. Effectively, what we're saying -- and that number of members would increase over time.
George Michaelson: As of June 3,593, increasing approximately at linear rates monthly constant.
Andy Linton: That block would actually get -- the required block would over time probably grow a little bit, because you would need more if we had more members.
George Michaelson: If you want to satisfy the algorithm that you are designing here to distribute equitably amongst holders of current address, all address you receive, on the basis you want to give them a 22, yes, you would need an increasing amount to match the increasing members.
But with the number we have now, which is 3,500, rising to 4,000 in the time that we are talking about, that is the size that you would need. Obviously when you arrive at that time, if you have a larger number of members, you will need more to achieve a 22.
Dean Pemberton (InternetNZ): Given that the 22 is a variable as well, we should cite it in terms of minimum allocation size.
Andy Linton: Yes. We probably want to make that quite clear what we're talking about here is that we would then need to go back, if we do this once, until we have another /10, we won't be able to do it again.
Dean Pemberton (InternetNZ): That would be my feeling. If we get a /10 from IANA, then I don't have any material objections to putting that in a pot and letting people have another bite at it like the final /8 policy, but then you would not do anything else until you had another /10.
Andy Linton: We're talking about a /10 or equivalent. It doesn't have to be contiguous.
Dean Pemberton (InternetNZ): It probably wouldn't be, yes.
Andy Linton: Is there anybody else here who has any questions or thoughts or anything on this? If that was indeed the way we would deal with this policy, you know, the policy says we get that a little bit more explicit that says includes that algorithm that we have talked about. It's a fairly loose algorithm. Does anybody have any other comments on this?
Mike Jager (Synack): It seems to me that if you do it this way, based on a /22 for every account holder at the time that the space comes in, you are going to do this exactly once. Because the next time around there are going to be more members and presumably the space that comes back is going to be smaller. I'm not sure that this is going to -- it sounds like, you know, on the face of it, it sounds good, but I can't see that it's going to work long term.
Andy Linton: I think you're right. Although we could end up with a different minimum allocation size, in which case it would be a /24 times ...
Kenny Huang (APNIC EC): I just, because that's the second time -- I proposed a similar idea, I just want to understand, is there any difference if we put additional pool back to the central pool, for example, in the final /8 pool? Probably we can set up, for example, a security margin for extended allocation for some people who have urgent need, but set a margin. So probably come out with the same result, instead of we probably doing the same exercise next time for a new allocation we need to do it again. We can put it in the central pool and set a security margin for extended allocation. That's what I think. Thank you.
Masato Yamanishi: There is a comment from Aftab Siddiqui, as remote participant. He said: "I agree with Mike. You can't just fix the formula once. The members are growing rapidly in our region and this doesn't make any sense. This requires intensive mailing list discussion to come up with a solution; can't be resolved here." That's his comment.
Andy Linton: Do people get that comment? That's from Aftab Saddiqui, who is based in Pakistan.
What we're saying here is that there is agreement in concept for this idea. I think, you know, people aren't averse to the idea of doing a re-issue. I think the mechanism needs some more work.
Masato Yamanishi: We mean making new policy for returned address space. So separating from last /8. Is that okay?
Tomohiro Fujisaki: Yeah, it may be okay, but, yeah, actually, I hear some points, but I'm sure another good policy can develop or not, yeah.
Andy Linton: What I'm a little concerned here is that I think we're relatively small numbers of people. Look around and there's relatively small numbers here, there's quite a lot of people here from the various Secretariats and staff, so we're not quite at the point where I think I can go more formally and ask for hands and things like this.
I'm hearing no objections to the idea of re-allocating numbers here. I think the thing we're discussing and we're actually trying to come up with a formula to do it or some other way to deal with this. We haven't quite -- do you think that's fair? Would you agree?
Tomohiro Fujisaki: Yes. It's okay.
Andy Linton: The question is what do we do? How do we proceed?
George Michaelson: A minor correction. My esteemed research director and chief scientist has pointed out the membership growth rate is strictly not linear. We do have an increasing rate of new membership. The trend is that more people are coming into the system and they are coming in more rapidly over time.
Andy Linton: Have we any idea of where we will be in a year or two years? Again, is that hard to determine?
George Michaelson: If you want the historical trend, in 2010 the monthly rate was 29 new members a month; in 2011 it was 36 new members a month; in 2012 it was 54 new members a month.
So that would appear to suggest that we are looking at more than 54 a month by the end of 2013 and that trend would probably continue.
Tomohiro Fujisaki: One question, George: do such members get the IPv4 address?
George Michaelson: Yes, these are effectively members joining to get their portion of final /8 policy address.
Tomohiro Fujisaki: Thank you.
Andy Linton: Is the implication then that if we were to say a /22 for each member, with some sort of growth rate that, from this pool, we may not be able to achieve that if everyone takes it up?
George Michaelson: It's all about the timing. Because the current membership is 3,500 and at the current rate of 54 a month, that's 600-odd in the year, so we would be at the 4,000 mark by the end of the year, so the arithmetic works, at the current rate of growth, for end of year. But if things are accelerating through the year, it might be marginal, on the 22. Of course if you make the allocation per member to be a 23 or a 24, then all of this changes.
The policy has mutable aspects. You were talking about a 22. This is the number that fits at this particular model. But if circumstances are different, you're going to have to think again.
Andy Linton: Okay.
Dmitry Burkov (RIPE NCC): Just some observation, because even six or seven years ago, we discuss and I predicted that we will get growing number per month for years. Nobody believed because all people think about is that we will have a consolidation of businesses. But now we have got more than 1,000 growth per year and it continues progressional.
For me it's more interesting, because maybe it's possible that not all will request last /22 and we can get in result of this growth, and growing demand, that it will be not enough of space from -- it's a reality. We seem to should recognize this is a fact and understand that we can be in conditions that not all can be satisfied. It's a possible working model. It should be estimated too.
Andy Linton: Let me ask, given those factors, and given the other bits of discussion that we have had, how many people here want to see this proceed as it has been presented, as it is now? So this proposal.
Dean Pemberton (InternetNZ): As --
Andy Linton: We haven't actually made any substantive change here.
Dean Pemberton (InternetNZ): Okay.
Andy Linton: As it is now, how many people are in support of that?
Dean Pemberton (InternetNZ): Sorry, as per the last written proposal that went to the mailing list?
Andy Linton: Yes.
Dean Pemberton (InternetNZ): Okay.
Andy Linton: Can I see hands? For support, who supports this proposal as it went to the mailing list?
I'm not seeing anybody going yes, yes, yes. We have talked about an algorithm to try and calculate this and try and work out how much address space there would be. Is that something that people would like to see this proposal go ahead with if we do some work on that algorithm and work out a fair allocation to people at the time when this /10 or /10 plus becomes available? Would people like to do some more work on this? No?
Yes. 1, 2 -- a number. Please don't be shy, because it's really hard for us -- yes.
Okay, I have a feeling.
People who really want to see this just got rid of completely, is anybody opposed to doing some more work on this? Is anybody opposed to saying "no" to this, with that extra work? I think what we're -- Tomohiro, are you getting that feeling?
Tomohiro Fujisaki: Yes, yes.
Andy Linton: I think the feeling is, yes, but with a little bit more work and let's work at the algorithm, let's do some arithmetic and let's work it out's. I suspect the algorithm really needs to be -- it's such and such at the time of it becoming available. So if we have 7,000 members at the time this becomes available, then it's going to be a 24 each and not a 22 or that sort of thing.
Mike Jager (Synack): I think the process of trying to lock those numbers into place is going to be quite a time consuming one. I didn't raise my hand in favour of continuing it, but I'm equally not opposed to it. I just can't see that this is going to happen in a timely manner. The numbers are changing so rapidly that I think trying to fix certain numbers isn't going to work. I think it's going to have to be, if you want to do it, it's going to have to be the number of members divided by the number of 24s or something, but then -- I'm just not sure that we're going to agree on anything in a timely fashion and then the address space sits there anyway, the same as if we do nothing, so it is a complicated situation.
Tomohiro Fujisaki: Exactly, yes.
Masato Yamanishi: George, I have a question. I think the discussion is also related with the growing rate of number of account holders. Who is the appropriate person to ask about the latest number?
George Michaelson: The official latest number, I think that is probably vests with Hostmaster. I think the information is usually part of the report that is given by Hostmaster. Is that something you want delivered to the meeting now or is that information you want to have access to for later?
Andy Linton: I think it's unrealistic for us to rush off and get that. I think your number of 3,500, 4,000 --
George Michaelson: Is this for the purposes of modelling the behaviour, so you can go away and think about it? My colleague has information. This is George.
George Kuo (APNIC): I can share the membership statistics. In 2010 we have 405; 2011, 479; 2012, 719; in 2013, so far, we have 136. This is the growing trend from 2010 and the total number of open members up to date is 3,640.
Masato Yamanishi: Can you send that number to the mailing list, so everybody can discuss based on the same number?
George Kuo (APNIC): Yes, certainly.
Andy Linton: I think the answer here is this is something we need to take to the mailing list to discuss a little bit more the actual mechanism for deciding what the number should be.
The principle of it, I think people are in agreement with, but I think the actual -- because what this needs to be is fair -- if we say a 22 and there's not a 22 for everybody, then that's not fair.
Tomohiro Fujisaki: It's okay. Thank you.
Andy Linton: I think that's where we'll go with this. I think that's the best solution.
Tomohiro Fujisaki: Yes, thank you so much.
Andy Linton: Thanks for bringing this issue up, because it's a useful one for us to highlight and try and come up with a solution to.
Now we have our second proposal today. Shin, will you come and tell us what this is all about, please? Thank you.
Shin Shirahata: Good afternoon, everyone. This is Shin Shirahata from Clara Online.
Today we are going to talk about the new policy proposal. We have changed the title of the proposal from previous version, proposal title is "Clarifying operational practices in the APNIC region for transfers under the final /8 delegation".
Here is an introduction. We think operational guideline is needed for IPv4 address transfer from last /8 block. Because possible loophole to the policy was pointed out for the people who tried to obtain multiple /2 from the final /8 block.
Here is the current problem. We would like to explain about the loophole in the last /8 policy. The current APNIC IPv4 address management policy clearly states that each new or existing APNIC account holder is only eligible to request and receive a delegation totalling maximum /22 worth of address space from the APNIC IPv4 address pool.
But based on our observation of the APNIC transfer history records, some LIRs seem to collect IPv4 address blocks under the final /8 range by using multiple accounts and trying to transfer these blocks to a single account.
This is the situation in other RIRs. At this moment, there is no similar policy at other RIRs.
This is our proposal. We propose to add the following text in APNIC guidelines document about IPv4 address transfers under the final /8 blocks:
"For transfers of address blocks approved the final /8 policy, APNIC/NIR will confirm if it matches with the spirit of the final /8 policy.
When APNIC/NIR confirm requested transfers do not match with the spirit of the final /8 policy, it cannot guarantee to approve such transfers."
This change would allow APNIC/NIRs referring to the guideline document when they find the case of the misuse.
This is our idea. We think this one of the solutions. We are open to suggestion to correct such activities.
Here is advantages and disadvantages. Advantages are it will allow APNIC Secretariat to take adequate action when they clearly find the case of misuse against the spirit of the final /8 policy. And it would not have a strong restriction as in the policy.
Disadvantages is there may be some opinions about the need to address the problem at this stage.
Here is implementation. In APNIC, needs to justify transfer of IPv4 address blocks under the final /8 block. For effect on NIRs, NIRs need to adopt this policy.
To summarize, we propose the described operational guidelines for the APNIC Secretariat for IPv4 address transfer on last /8 block. That's all. Thank you.
Andy Linton: Thanks, Shin. That's a good, clear set of description of the question and the problem. So thank you for that.
Are there any comments from the floor?
Kenny Huang (APNIC EC): Because I didn't see you propose any timeframe to prohibit this kind of transfer. In spirit, I think several people probably will oppose your idea, your approach, but I think it's lack of some detail framework to describe how it's going to be implemented in detail.
Randy Whitney (Verizon): I'm opposed to this. It's putting on -- basically it's trying to make APNIC care about my business plan. If I need to transfer for business reasons, I shouldn't have to justify that.
Andy Linton: Yes. Shin, I got the impression that Kenny's comment, you were going to answer it. Did you want to? You were thinking about it, I could see. The lack of detail. Yes?
Masato Yamanishi: You want to answer Kenny's question?
Tomohiro Fujisaki: I am the co-author of this proposal. Actually, several people opposed to implement as a policy to prohibit such transfer. So we revise and currently we propose to -- yeah, state in the guideline which can differ for APNIC Secretariat to judge it's okay or not. So, yeah. I believe that people opposed to create the policy for this, I believe.
Andy Linton: Okay. Thank you for that. I would would like to ask from the Hostmasters, so can I ask you, George Kuo, can you comment on this? I'll give you the question first.
If you were given this as the phrase, can you go back a couple of slides, the one about the "spirit". You know, so the extra word in here. Is this something the -- how would the Hostmasters deal with that? Or is it possible? Have you any comments on that? Can you interpret that? I think it's important. There's no point us trying to pass policy if it's not implementable.
George Kuo (APNIC): Perhaps Anna could better answer. We have Anna here, the Hostmaster --
Andy Linton: I'm sorry, I'm picking you out because I could see your face.
George Kuo (APNIC): That's all right.
Anna Mulingbayan (APNIC): From the Hostmaster's perspective, in terms of evaluation, I think it would be good to have a particular timeframe and also the criteria that we need to follow in terms of accepting or rejecting transfer requests.
Andy Linton: Thank you.
Tomoya Yoshida (Internet Multifeed): I have a basic question, is this policy for the guideline just for the final /8? I mean, as Fujisaki-san proposed the previous presentation, so we may have the additional /22 or /24 address block, so I think we would better to apply not only the final /8, but additional IPv4 address space.
Andy Linton: If this was worded as "any further allocations" or --
Tomoya Yoshida (Internet Multifeed): For the additional allocation.
Andy Linton: Any additional, yeah.
Masato Yamanishi: Shin, how about your thought about additional or reallocation, would apply this rule to?
Shin Shirahata: I think additional allocation should be treated the same as a last /8 allocation.
Andy Linton: Treated in the same way?
Shin Shirahata: Yes. I think here for the spirit of the last -- how can I say. For the spirit of final /8 policy, we can refer to the prop-062 and I think here is the spirit of the final /8 policy. I think to ensure that new and existing LIRs can receive a minimum amount of IPv4 address space is the spirit of /8 policy, I think.
Craig Ng (APNIC): I'm just responding to your question, Andy, about the difficulty in implementing this spirit. The term is vague and it makes it very difficult, I think, for our Hostmaster to do their job.
The concept that might be used in other, like, domain names, for example, is that they prohibit related entities from holding -- you might be talking that related companies cannot own more than a /22 from the last /8, that might make it easier to apply, but I think spirit is just too ambiguous for us to implement.
Masato Yamanishi: I got related comment through chat from Guangliang, he's the manager of APNIC Hostmaster, and he also said it's quite difficult to implement this in practical way.
Craig Ng (APNIC): Just a follow-up. Even if you do talk about related entities within a corporate group, it is very difficult for APNIC to actually investigate, because you can have companies that are 100 per cent owned, 20 per cent owned, 30 per cent owned, so that can be very easy -- that creates a loophole in itself. Just thought I'll contribute that part.
Andy Linton: Thank you for that. That's useful, I think.
There was also some discussion on the mailing list, which talked about the size of this problem and this was deemed to be -- so far, this hasn't been seen as a big problem, but I appreciate there is an issue. There may be localised issues on this, where it's happening in some areas and some markets and it's not happening in others, so there may be some differences there.
Mike Jager (Synack): One of the problems that I think this doesn't solve is someone has registered a new legal entity in their economy somewhere and they take that entity to APNIC and they say, "Look, I can justify a /22, give me a /22." Assuming that that has been appropriately justified or they have provided some documentation to prove that a 22 is justified, if you prevent the 22 from being transferred, I don't think that actually solves the problem, because a 22 is still allocated, it was allocated according to the policy at the time, so it was supposedly correctly justified. The 22 is still out there. It will just be allocated to a different entity from the one that's actually using it.
So assuming that you could track that, I'm not sure that you could even revoke a space, because if it was allocated based on a legitimate "justification", you're going to have a hard time, I think, revoking that allocation.
To simplify it, I guess, if you disallow the transfer, the transfer will happen just not on paper. If the allocation was justified initially, if the transfer hasn't happened on paper, but has happened in the routing table, how are you then going to revoke it? I don't think this policy is actually going to achieve what it's trying to achieve.
It may well ensure that the resource is not transferred in APNIC's view of the world, but I think it's still going to happen. This, I think, is a lot of the transfer policy rehashed all over again, just with a slightly smaller chunk of the address space.
Andy Linton: Okay. Thank you for that.
Dean Pemberton (InternetNZ): Yeah, I would like to just come out in support of what Mike said. This talks about putting something in place that would restrict the transfer of IP addresses. I'm sure Craig would agree with me, that there's nothing we can do to restrict M&A activity, so there's nothing we can do to stop companies from acquiring or merging with other companies. So all that's going to happen here is that if someone wants to do this, they're still going to start up a legal entity. They're still going to apply for address space. The Hostmaster will apply the needs based policy that we have, that IP address space will get allocated and up until that stage, there is nothing that APNIC can do about it, nor is there anything suggested in this policy for us to do about it.
If one of the entities then decides to merge or acquire those other entities, the address space will move. The address space will be transferred under a single point of control. Whether that's reflected in the APNIC database or not, is actually a moot point. The actor has already achieved what they wanted to achieve.
So I don't know that this policy by talking about transfers will actually achieve what your stated problem is.
Masato Yamanishi: I got two additional comments through chat. First one is from Aftab. It says: APNIC Hostmasters morally ethical binds all new members not to transfer resource within 12 months before assigning resource from last /8. He think leave it as is, so he's opposing.
Also, another comment is quite short. Makito says he agrees with Mike's comment.
Andy Linton: Okay. I'm seeing a number of people who are saying -- I think effectively -- I mean, the summary here for me or the thing I'm seeing is that people are saying they don't think this will work or it will be difficult to implement, Craig, I think is your comment from a legal perspective and a process perspective. The actual phrasing "spirit of" and so on.
Is there a willingness for people to explore a way to do something here which will work or do people think it's not a problem anyway? Let's ask those two questions.
Do people think that this isn't a problem and we should just ignore it? Some people think it's not a problem and we should just ignore it.
Who thinks this is a problem and we need to do something about it?
I presume you think it's a problem, because you brought it, Shin. Who thinks it's a problem and we should do something about this?
The question then is there's a number of people who say this isn't a problem, we don't need to do anything about it. There's some people think it's a problem and we should do something about it. Is there a middle ground here? Is there a problem and can we do something about this?
Mike Jager (Synack): I think it could be a problem. I think we may be able to do something about it. But it would be very difficult to do so.
Masato Yamanishi: There's two people saying it's not a problem on chat.
Andy Linton: I'm seeing that from a number of people.
When these sort of transfers happen, what do we do about recording them? What is the process at APNIC for recording those?
Adam is prompting me here that there is a log of these transfers on the FTP server, so there is a public record of this stuff happening, from and to, who transferred what to who.
I'm not seeing great enthusiasm from the room to make this happen, I think. I don't see enough people here -- do people want me to go into more detail than that? Are you going to make a comment, Dean?
There is a bit of a split here. Let's go to ask for the formal consensus on this, just to see where we are.
Those people who are in favour of this proposal, can I see who you are, so that we can get an idea of how many support this proposal, as it is.
Those people who support this proposal, can you please show me your hands.
I would hope the authors support it. Thank you, Tomohiro.
Anybody else? Those people who are opposed to this.
I think that says there's no consensus here on this and I think that's our -- yes.
Do people want us to continue with this? Do we want to discuss this some more and think about whether there is a better mechanism to implement this? Do you want us to take this back to the mailing list?
Who would like to see this taken back to the mailing list for further discussion?
I'm not seeing -- who would like to see this just ...
Yes. Okay. I think we're not going to reach consensus on this, Shin. Thank you for bringing this to our attention.
Shin Shirahata: Thank you.
Andy Linton: It may well be that in six months time, we'll all go, "Oh, we should have done" -- but let's keep a watching brief on this. There is a question here. But let's see if the problem becomes larger or whatever.
At this stage, I don't see consensus on it. So thank you.
Shin Shirahata: Thank you for your time.
Andy Linton: Thank you.
Andy Linton: That brings us to the end and at a very nice time, I think.
There were a couple of announcements that I had this morning to remind people that the AMM is tomorrow morning. There's still a process where people can cast their votes at the member meeting for the executive EC and you can register for that at the reception desk tomorrow morning from 8 o'clock onwards. I think that's the main one that I have to get out there.
There was a paper here and it's gone away. But I remind you about that. Check up on that. There's an APRICOT social tonight, the Closing Social. This is the ticket, you just need to bring your badge. So there's no special ticket for that.
I'm just looking for prompts here. I'm getting the thumbs up. Okay.
Thank you all for coming. Thank you to our proposers and our presenters, informational presenters who have given us something to think about and talk about and discuss.
From this part of the thing, we'll see you all in six months time.
AMM tomorrow morning and we'll be bringing back our report to the AMM and carry on. So thank you.
I think we need to clear this room, because they're going to open up the partition -- no? Okay, they're not connecting them. That's okay.
So you can stay there.