Https://2020.apricot.net/program/schedule/#/day/9/apnic- policy-sig-2. DISCLAIMER: 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 and Lloyd Michaux apologises for any inconvenience, but accepts no liability for any event or action resulting from the transcripts. ********** >>Sumon Ahmed Sabir: Welcome back, we'll be starting our second session and we're starting with a presentation from Mr Geoff Huston. He'll be talking about the End of Days. >>Geoff Huston: You know these policy SIG meetings get more and more people every time, don't they? Welcome, all ten of you, it's good to see you. My name's Geoff Huston I work with APNIC, I actually do measurement and analysis inside labs. What I've been asked to do is do a run-down of the broader picture of v4 addresses inside APNIC as a registry. It seemed to me like it really is the case of End of Days but not the Schwarzenegger version, it's actually the registry version. This is the IPv4 allocation picture sitting right inside 1 the APNIC registry. On January 27, here is the total picture of everything that is under APNIC's stewardship, ministration, whatever. So APNIC looks after 53.1 /8s or 890 million /32s. You can see on the numbers there that most of these have been assigned, so if you look in the daily stats file, you get sort of 883 million of them marked as "They're somewhere else, we don't hold them." On that day 2.8 million, 2.9 really, are marked as being "That's what we've got left." Interestingly now, the larger number, 4.4 million simply has a single word denotation, it's called "reserved". So publically, they just look like they're reserved. I should note at this point I've only used public data. I have no idea what happens inside the registry, I don't work there, I work in Canberra, so I'm using the same data that anyone else could use and anyone else could see. I'm not relying on any particular magic incantations to give you deeper reason, it's all just public data. So let's have a look at that available pool. Here is the available pool every day since January 1, 2011, which, as you might recall, was 2 just prior to the IANA handing out its last /8s. What you actually see is -- look on your laptop because this is so detailed -- you actually see us run down from 40 million addresses down to 20 million, we've then got three /8s, it jumps up to 7 million. We then start allocating again, drop down into -- sorry, 17 million, drop down just below 60 million, get the final allocation, right, and then run out basically because we get swamped and by April of that year we're down to 16 million addresses. So that was a really quick drain, as you see, from where we were at the start of the year, the final allocation, to the point where the last /8 policy was activated. Boom. We trundled on doing the last /8 policy. It looks kind of linear, possibly a bit accelerating, but for those folk who are long-term attendees, and you've been around since 2014, you will remember we actually swept up what we call the various pool, the really old legacy blocks, we handed them all back to the IANA and the IANA did redistributions of those legacy blocks twice a year for some years. So the slight uptick twice a year, and they got smaller and smaller as the years went on, was the point where we 3 got reallocations -- sorry, returned legacy addresses coming back. The policy to redistribute those was different to the last /8. So when we got it, it sort of disappeared more quickly than the normal run-of-the-mill 124 (unclear) different policy, different consumption model. Let's get rid of the inputs. So this is the same graph, but I'm only looking at out the door, in other words consumption. I'm not looking at the refresh, I'm simply going this is the rate that APNIC was getting rid of addresses. That, sort of since 2011, there's kind of three, or four really if you count the first panic, there's panic, there's sort of model 1, model 2, model 3. Somewhere between mid-2014 and mid-2016 was an entirely different consumption model which was actually a lot, lot higher than the one we've had since mid-2016 and the one earlier. I'm actually not sure, I don't think the policy changed, but I suspect the number of folk lining up was substantially different for those 24 months. It is certainly clear in the figures here that there was a different consumption model. Projections. All of these projections have 4 precisely the same underlying theory. Tomorrow's a lot like today. So if you understand today, you can project tomorrow. But in actual fact, today is not always a good judgment, and I've actually used three different windows: three months, one year, three years. And it's not obvious here, but it's more obvious there, that this is a little bit unusual. Since 1 January 2018 there's actually been some variance in the way stuff has gone out the door. Rate 1, rate 2, rate 3. There's three very, very different rates of consumption. Oddly enough, if you take a 90-day model you end up with projection 1 because the most recent three months is the slowest consumption rate. If that were to continue, those 2.8 whatever million addresses that we talked about, take my word for it, back there, 2.884 million addresses, will actually last at that rate until 23 February 2023. But if I take a one-year model, the one-year model actually encompasses that steeper part into the average. That pulls it back. So the 400-day model is actually a few months earlier, 9 October two years time. If I take a long-term model, three 5 years, I get to the 30 October 2021. So it's kind of -- you can pick any date you like out of all of that, because it's not clear why those phases. So there's some uncertainty as to exactly when this is going to happen. On the other hand, there could be folk out there who are going, "Oh my God, we better get in our application for our bit of the last /8 right now, we get snowed under and it all disappears next week." This is merely a projection based on previous behaviour, it's hard to tell whether panic ever eventuates and what it might mean. So that's the available pool. But as we pointed out before, there's a second pool. We mark them reserved. There's actually a lot of addresses there. That many. 4.4 million. This is the same period since 1 January 2011 looking at the size of that pool. Interestingly, it was small and then about the time of exhaustion it rose from a little under a million to 6 million addresses. I have no idea why. Almost immediately about a million went out the door as something else, they got marked as something other than reserved and things were stable. There are a couple of events which are sort of big 6 changes, but on the whole the most recent trend, oddly enough, is that the reserve pool is growing in size and has been growing since the start of January 2017. Then I looked at the date in the daily snapshot files when each prefix was first marked reserved. So what we can say is that more than half of that reserved pool has been reserved since the dawn of time of APNIC. Since the first time we actually started publishing openly the reserve pool -- we existed before then but we never actually openly said, "This is the list of reserved addresses" -- so I'm using public data, this date nine years ago is the dawn of time for me and more than half of those addresses have been reserved for that long. I don't know why, but in October 2015 a million addresses were removed from the reserve pool, almost in one transaction. I can't tell why easily, but there have been a couple of step functions. The age function says that of that 4.4 million, a tiny amount has actually only been reserved for a year. If I look at two years, it's only half a million addresses, all of the rest of the addresses have been reserved continuously for much longer than two years. 7 So reserved almost seems to be a permanent state, not a temporary state. But I'm not responsible inside, I can't answer to that, the registry folk will have to say that. But this data says "reserved", there's an awful lot of long-term reserved and I can't tell you why. I did something different. I looked at the reservations in terms of the number of prefixes every day and looked at the size of that and then looked at the aggregate of new addresses that got reserved and addresses that got marked as "unreserved". Because it's not just you mark it "reserved" and it stays there. Every day in the registry -- or every working day, because it's really obvious in the stats that no-one works on Saturday and Sunday -- a number of addresses get marked as "reserved" and pretty typically addresses get removed. So above that horizontal line is the volume of the number of prefixes that got marked and the number of prefixes that got unmarked. So there is this continual activity of unmarking reserved blocks, but the net result is that the number of blocks keeps on increasing. It's up to currently 450 blocks. 8 That's not talking about size, that's just the number of blocks. So we can plot that together starting at January 2014 and take that as zero day. The number of reserved entries just keeps on growing. The amount of number of entries that get taken out, unreserved, grew at a lower rate, huge amount got unreserved in terms of number. 400. Big clean-up day October 15, 400 blocks got taken out of reserved. Well done, working very hard. For a while the number in equaled the number out but since then there's been more in than out. The bottom line is the difference between the red and the green. So what you're actually finding is since about, I don't know, late 2016, more prefixes are being reserved than unreserved. The pool just keeps on growing. This is the same thing just looking at addresses, not prefixes. So you see the pool size grows, huge unreserved clean-up, huge marking of reserved, bit of a clean-up and off we go again. And again, this horizontal line, if it's above the line those are addresses that got marked as reserved, if it's below the line on that day those addresses got marked as unreserved, they got taken 9 out of the reserve pool. Here's the same data just in address volume. So we started 2014. A lot of addresses got marked as reserved in terms of addresses late 2014. Largely keeping pace with each other, that net change is a lot slower, but overall, more addresses are entering reserved state than leaving it since 2017. What's going on? I don't work in registry and I'm not using private data, this is just public data. As far as I can see from the data that gets published, if I discount the long-term reserved folk, 2.2 million addresses, and just look at the bit that's more recent, the average period that any prefix is reserved is actual 26 months. If I, instead of doing prefix-weighted I actually look at address-weighted average, if we reserve an address, that address will probably stay reserved for 40 months -- which is quite a long period if the story is quarantine. I do not know the story, but that's what the stats say. So what I see from the data, a really small number of those large old legacy blocks are being removed from the reserve pool and there's more movement in the small blocks that enter reserved. 10 So if you enter reserved, you're going to stay there for an average of about two years. But the big overhang, 3.6 million addresses are just permanently sitting in the old pool and quite frankly, if you're going to make an impact on v4, the big impact is that 3.6 million. Exactly who they are, why they are, they've been reserved since data shows reservation. So I can't tell you, but certainly that's where the biggest pool is. Advertising reserved prefixes. Don't do that. We mark 1,501 prefix blocks as reserved, 34 of those blocks contain advertised prefixes. Don't do this. They're not your addresses. Stop it. 14,336 addresses are sitting in the BGP table as of late January. The rest, that number there, is what we see as unadvertised. There's a certain amount of, I don't know, uncertainty out there, some folk think they have a right to use it evidently because they are. This is the percentage of the reserved pool and looking at their age profile in BGP. So the first observation, that's 100 per cent of the reserved pool, more than half of the reserved addresses have never been seen in BGP for the last 25 years. When I say, "never been seen", I'm using route views as 11 the BGP record since they started doing it in '97 I believe. '95. A while ago. So 57 per cent of addresses route views has no record of ever seeing them. This is the age profile of the rest of reserved, 90 per cent of the reserved addresses haven't been seen for the past two years in the advertised, in BGP. So almost all of these addresses are old and haven't been used forever. There's some age profiles of individual days, that's the cumulative result. That's reserved. But we said we had all these assigned addresses. 883 million. But I only see 768 million in the routing table. Same kind of view since January 2015. Daily view of the number of assigned addresses visible in BGP every single day. Fair enough. Obviously if it's not advertised it's unadvertised. This is the other side of this. We assigned them, can't see them in BGP. It's kind of interesting, it goes down, goes up, comes down, goes really down, goes up, goes down, goes up. There's a certain amount of movement around these addresses from being advertised to not being advertised. The current total as of preparing this at the end of January was 114 million blah, blah, blah, a lot. 12 114 million addresses can't be seen in BGP. In percentage terms, 13 per cent. It's actually quite a lot. 13 per cent of the assigned pool is currently invisible. It's been around that number since 2015. That 13 per cent line, it came down a little bit to around 12 per cent, goes back up, but in percentage terms it's 1 in 6, 1 in 7, around there. What about age? Again, we take every dump in route views and we assemble the last time these unadvertised addresses were last addressed. The cumulative age profile. 68 per cent of them have been seen since basically 21 years ago, right, at some point. 32 per cent, I've never seen them. So we assigned them, they're allocated, never been advertised as far as I can tell. So 32 per cent of these addresses are invisible, that 100 per cent refers to what I can see. So of the ones that I can see, then the age profile tends to be that these unadvertised addresses are relatively old. The 50 per cent point is more than five years, 40 per cent of those addresses have not been seen for 10 years. If I go to 20 years, 80 per cent of these addresses haven't been advertised for 20 years. So a lot of this 13 unadvertised pool is actually relatively old. Half of it more than five years old. Why does this differ? The registry date. This is not when I last saw it in BGP, this is the date that APNIC reckoned it left the door. Interestingly, there is a huge peak of unadvertised addresses nine years ago. Remember when we got rid of seven /8s between January and April of 2011? Not all of them ever got advertised. A bunch of those addresses that left the door in that, you know, panic of 2011, I can't see in the routing table anymore. That's the reason why there's this massive jump. Those ones are, if you will, pre exhaustion, those ones are post exhaustion. If we had policies that say post exhaustion, when we allocate you should use them, by and large that appears to be the case, that there's almost nothing that has been allocated in the last two years that is not advertised. Used and advertised are a bit different, I'm not talking about being used but I can see them. So in the last two years, everything that's left the APNIC door marked as allocated is basically visible in BGP. Beyond two years, it starts to climb a bit. 14 I can combine those two graphs, I'm not sure what it means. I should do a little bit more work on this, because in some ways you allocate an address, it's advertised, and then it becomes dormant. So the allocation date and the date it becomes dormant differ in time. And that difference in time is actually the difference between those two curves between the last advertised age and the registry age. But the same observation, 50 per cent of the unadvertised addresses are older than eight years, 30 per cent are older than 22 years. Where are they? The geo-databases still work because they're assigned addresses, they're not nowhere; they are somewhere. The last known location in terms of country and the number of addresses that are assigned -- sorry, in that economy, use the right word, in that economy are indeed in that table. You can read as well as I can, hopefully, is that all visible? Good, fine. Nothing more to say. That's a lot of addresses. 4.4 million reserved, in rough terms 115 million unadvertised. If you release those 4.4 and you take the long-term consumption trend out of APNIC, you'd actually get another further three years at the current 15 consumption rate in the current last /8 policy regime. So at the rate we give them out, those 4.4 million addresses would last a further three years. Change the policy, change the rate. The 115 million is kind of interesting because as far as APNIC's concerned they're somewhere else, they're not in the registry. And one line of thought is, that APNIC doesn't need to do anything, the market will. Because in theory, in theory at the right price folk will sell. Economics. Will they? What's the right price? This is a condensation of market data from a number of the brokers. The key one I actually think is the one on the top left that points to a stable price since around late 2018 that oscillates between $20 and $22 per address. So it's steady, it's not rising. So if you weren't prepared to sell in 2018 because you thought the price was too low, nothing's changed between then and today. The price hasn't moved. So if price is going to flush, the market is not telling them to sell because the market's not changing the unit price. So as far as I can see, you can divide this up. There are at least 30 million of those addresses which are as old as APNIC, we inherited them. 16 They're buried in legacy, and quite frankly, the current market price does not provide incentive for whoever they might be to emerge, demonstrate that they're theirs and sell them. Whatever's been done with those addresses, not being advertised, never seen them, a lot of it. So I don't know, but that's the data. Obviously this raises some questions, or make it doesn't, maybe it's all clear, I'd be happy to try and answer them. Thank you. >>George Michaelson: George Michaelson, APNIC. I am the registry product manager, and you are talking about the behaviour of the systems that are the core registry function, the maintenance of the things that we call the pools, the pools of address that we have authority over from which we make delegations. So this actually is squarely and firmly in my area of activity. >>Geoff Huston: Your bailiwick, if I could use the word. >>George Michaelson: I don't want to use that word. >>Geoff Huston: I love that word. >>George Michaelson: You said, "I don't look inside the machine". You said, "I, Geoff, I only go with publically visible" -- >>Geoff Huston: All this comes from published BGP data 17 and published daily stats data. >>George Michaelson: I am the machine, I would like to talk to you about some mechanistic behaviours of the machine. The machine has a very simple model of what can be given out and if we flip the switch for the ranges that lie in the pool space that is denoted 103 /8, the machine, as it currently stands, does not understand the distinction between "has previously been used and is now available", and "has never been used", and we will automatically switch to a mode where anything that is marked available in the pool from 103 is given out. It just works. >>Geoff Huston: So what you're saying is, you do not maintain a last seen in routing date, I calculated that and that's my input in this presentation, yes. >>George Michaelson: We have no policy-driven driver that has taken us to understanding the decision when do we flip that switch. >>Geoff Huston: Which is why I'm presenting this because quite frankly this is a policy issue about what the community wants to do about the End of Days. >>George Michaelson: But, as a result of other work that of necessity must be done, and is in my road map for completion by Q2, 2020, the ability to flip that switch and convert to a mode of operation where we 18 consciously and deliberately re-use previously routed 103 will be done. There is a small body of work that will be done that makes the decision significantly easier to apply. So when this room and this process determines yes, we're going to do this, the mechanistic behind-the-door machine is heading to being ready mid-2020. That's all I wanted to say. We're not hoarding it, we're making the machine able to do it. >>Geoff Huston: No-one ever said anything about hoarding. At least I didn't. >>George Michaelson: I'm not going to ask for a recall of the transcript. >>Geoff Huston: I'm not using the "H" verb, and this is really not about behaviours, it's actually about the data, and the one piece of data that APNIC has not integrated into its thinking and presentations has actually been about the relationship between the routing system and our allocation system. >>George Michaelson: Yeah. >>Geoff Huston: This is, if you will, the bit that's actually here where I talk about the age of the components of these pools. >>George Michaelson: It's a small thing and it isn't something that should have any consequence for what 19 we say here. But there is for now, for the lifetime of having remaining fragments of what you used to call the bottom of the barrel, things that have never been seen, they have a delicious quality compared to things that have been seen. And I don't quite know what we call this anymore, but essentially it is they're not tainted. There's no belief. >>Geoff Huston: The really old ones are more unknown than the ones that were seen, say, 20 years ago, 10 years ago, and the ones we saw last month we probably think we know who they are. >>George Michaelson: So the thing here is that by continuing in a process where we use the front of the ring buffer analogy and we give out clean things to new entrants, they get a piece of address space that in general sense hasn't had a prior history. If we start opening the door of giving them out the back of the ring buffer, everybody gets an address that in some sense has a prior history, and some people tend to say, "Oh, unexpected things are happening in routing, I don't like this address block." I can't fix that, you can't fix that, none of us have a time machine. There's a hypothetical future state where all addresses have a prior 20 history. We can't actually say clean addresses and tainted addresses, the concept won't exist. But during this narrowing window, we are giving people what you could moralistically call slightly cleaner addresses, they're new. But that is only an observation, it is not a policy act or even an operational practice. It's just an observation. >>Sumon Ahmed Sabir: Thank you, George. We're running out of time, we'd love to have more discussion on it, probably this presentation also leads to more thinking and research what's happening to the allocated space not present in the routing table. Thank you, Geoff, and thank you very much for your presentation. APPLAUSE >>Sumon Ahmed Sabir: Now we'd like to move to actual policy discussion. I'll hand it over to Bertrand. >>Bertrand Cherrier: Jordi, start with the modification of transfer policy, prop-130 version 2. >>Jordi Palet: This is the second version of policy proposal that was, if I recall correctly, informally presented a couple of meetings ago and then we did -- or in the previous meeting and I got some inputs and I have taken those inputs in a new version. So the problem here is that we have transfer 21 policies for v4, v6 and ASN, and in different regions we have different ways to do those transfers, either as transfers or in cases like mergers and acquisitions, so in the current text in this region for the mergers and acquisitions it is not clear, or at least from my perspective it is not perfectly clear if it's contemplating all the cases or only within the region or also outside or if a company only sells part of it and they are using part of the resources if this is allowed or not, etc. So that's basically what I am trying to solve with this policy proposal. There is different support in different regions. For example, mergers and acquisitions, if I recall correctly in RIPE and AFRINIC, right now they are not policies, they are internal procedures because they considered this a business thing, not a policy. But in the other regions it's policies, right, so we are half and half more or less. Because basically in the existing manual in this region, policy manual in the region, we have one section for v4, one section for v6 and one section for ASN. What I did is basically look at the existing text and update it exactly the same way 22 for each of those resources. In this case, for IPv4, what you have in the screen, the smaller text, the one on the left, is the existing text and the other one is the text I am proposing, and I am highlighting with red colour the key changes. So the actual text for IPv4 we have: "Mergers & acquisitions. APNIC will process and record the transfer of IPv4 resources as the result of merger or acquisition." And I am proposing to add relocations, because if we are talking about companies that may move from one region to another, which is a perfectly valid case, I think it made clear if we add that, relocation as well. So the proposed change is: "APNIC will process and record the transfer of IPv4 resources as the result of a partial or complete merger, acquisition, reorganisation or relocation and supporting ... both ...intra-RIR and inter-RIR." This was the text, the second paragraph I have here, this is the text that was amended as a result of inputs. I tend to recall that it was legal counsel from APNIC that suggested that we should clarify it. So it's: 23 "In the case of inter-RIR, the counterpart RIR need to have a reciprocal policy/procedure that allows it." I said "policy/procedure" because, as I just mentioned, in some regions it's not a policy, it's a procedure. So we need to take into consideration both situations. Exactly the same change for IPv6, I don't think I need to read it, it's exactly the same, no difference, and exactly for ASNs. So what is the advantages of the proposal? Fulfilling the objective I am trying to reach. Disadvantage. This was part of the discussion as well. It could be considered that this can create further disaggregation, especially in the case of IPv6. However, my perception is that the number of inter-RIR cases that will happen will be really, really small, so I don't think that will be a high impact, and we know, policy say or suggest that you should announce as a single aggregate but at the end -- in IPv4 it's terrible, sometimes you have 1,000 disaggregate -- pieces of a big prefix, but in IPv6 probably it is 2, 3 average. I don't really think this is going to be a big impact. That's it. References to similar policies that 24 we are discussing in other regions as well, and so on. Maybe if I can go back, I am going to keep one of the slides as the text is the same, I keep just one, whatever, so we can follow the discussion based on that text. Inputs, comments? >>Bertrand Cherrier: You're going to comment or just taking pictures? >>Mike Burns: Mike Burns from IP Trading. Will the loosening of the standards to allow partial mergers, acquisitions, relocations impact the waiting periods? In other words, various registries have various waiting periods after which you receive a transfer before you can resell it, or an allocation. And in ARIN we've seen ways around this by somebody who has to wait to sell their addresses will instead do a merger or acquisition, and those addresses, as a result of that process, do not then have a waiting period before they can be resold. I think the community should consider whether the implementation of this policy will provide some workaround for waiting periods that the communities have placed in the regions. Do you know how it impacts the other regions? >>Jordi Palet: Yeah, I remember understand your point. 25 However, in the policy text, both the actual and what I am proposing, we are leaving the staff the freedom to look for the recommendation as they wish and also to check those documents which in the case of inter-RIR, which the other counterpart of RIR. I think it will be difficult to escape from that control if you are trying to cheat the system, right? >>Mike Burns: I don't know, there are big differences in the way registries treat these mergers and acquisitions. For example, in RIPE, you can't do one of these merger and acquisition transfers without government papers from relevant agencies documenting the divestiture or acquisition, whereas in the ARIN community and in LACNIC you can divest just a product line or a network or a region and there are no jurisdictional documents, it's just a business case and ARIN will review that and accept that without requiring, you know, anything from any government. So you know, people are always looking for a way to get around things. We talked about the impact of the five-year waiting period on the 103 pool just recently. So people do look for ways to get around 26 waiting periods, and a merger and an acquisition that doesn't have a waiting period that starts at that process provides that workaround. It's just something to consider, because the waiting periods vary from region to region and if you can do this inter-regionally it provides another method to get around that waiting period. >>Jordi Palet: Thank you. >>Bertrand Cherrier: Any further comments or remarks? >>Sumon Ahmed Sabir: I think Secretariat staff have some comments on some technical issues. George, do you want to read out? >>George Odagi: A few comments here. So from services perspective we might have difficulties in verifying certain mergers, acquisitions and re-organisations, or relocation from out of region due to unfamiliarity with languages and legal systems. The NRO comparative policy matrix indicates APNIC members outside of the region must have network presence in the Asia-Pacific. Additionally, some RIRs have an out-of-region policy which restricts where they can use their resources. Members may face difficulties updating their domain objects if there has been a partial IPv6 transfer or a larger block has been de- aggregated. 27 Technical comments. Our current systems are not configured to handle inter-RIR v6 reverse DNS and this will need to be developed and we cannot predict when the other RIRs will support v6 reverse DNS fragments coming into the systems. Legal comments. This will affect how we verify M&A documents and will possibly require cross-RIR co-ordination. That's it. >>Jordi Palet: I recall I responded in the list to those inputs. I think most of them are operational and we are giving, by not having explicit text, the Secretariat, the way to decide by themselves how they do, how they co-ordinate with other registries, I agree with the possible impact in the reverse delegation. I think at some point during the meeting or yesterday I heard already George commenting about that, so yeah, we are aware. And I don't think we will see so many cases as will create a real impact. And of course, if for example we reach consensus on this proposal and APNIC implements it, it may happen that some parts of the proposal like doing transfers for mergers and acquisitions with another registry cannot be done until the other registry is ready as well. We understand that. 28 That's the case for any policy involving different regions, right. >>Bertrand Cherrier: We had comments as well on the mailing list from the Japan APAN policy forum mainly opposing this proposal. >>Jordi Palet: I think I responded to that as well in the list. I don't remember my email, unfortunately not being able to use my computer here I cannot show it now but it's possible to, yes. >>Bertrand Cherrier: No more comments or remarks? So now we'll go for the consensus call. After discussion we split the prop-130 in three parts. One for the IPv4, one for the ASN and one for the IPv6 because most of the opposition is for the IPv6 part. CONFER is open. >>Jordi Palet: The one on the screen is showing ASN. Just to make sure the people know. >>Bertrand Cherrier: We start with the ASN only. So if you strongly support this proposal, just for the ASN part, please raise your hand. Thank you. If you support this proposal, please raise your hand. If you are neutral to this proposal, raise your hand. If you oppose this proposal, please raise your 29 hand. Thank you. If you strongly oppose this proposal, please raise your hand and express yourself. Thank you. So sorry to say, but for the ASN we didn't reach a consensus. So can we move to the IPv4 part. CONFER on the screen, please. Now we're on the part for IPv4 only. We'll wait a few seconds for people to express themselves on CONFER. So if you strongly support this proposal, please raise your hand. If you support this proposal, please raise your hand. If you are neutral to this proposal, please raise your hand. If you oppose this proposal, please raise your hand. If you strongly oppose this proposal, please raise your hand and express yourself. Thank you. It didn't reach consensus either. So for the IPv6 part, if you strongly support this proposal, please raise your hand. If you support this proposal, raise your hand. If you are neutral to this proposal, please raise your hand. 30 If you oppose this proposal, please raise your hand. If you strongly oppose this proposal, raise your hand. Thank you. So this proposal definitely didn't reach consensus. >>Jordi Palet: As usual, please those that are opposing or strongly opposing, it will be good to raise their voice in the mailing list so we can see if it makes sense to update the proposal or withdraw it or whatever. Thank you. >>Bertrand Cherrier: Thank you, Jordi. >>Sumon Ahmed Sabir: I think this proposal is for -- this is the second meeting we're discussing, and it's on the mailing list for quite a long time and in the mailing list the primary opposition is opposing most part of it, so I think we can ask for another consensus from the meeting that should we abandon this proposal. Maybe we don't need this or the community feels -- or maybe community don't understand that, need more understanding on that, so we can wait for it for sometime for further discussion. >>Jordi Palet: I think that will be the ideal because the problem is that we only get one comment two days 31 before the meeting basically, or two comments and I think what I can try to do is immediately after the meeting try to foster some discussion and depending on that, decide. >>Sumon Ahmed Sabir: Sunny, do you want to make any comment? >>Sunny Chendi: Exactly, that's what I just wanted a clarification, whether we're going to put this proposal on the mailing list. But you are calling for a consensus to abandon the proposal here in the room? >>Sumon Ahmed Sabir: That is something I was thinking, whether we can do that. >>Sunny Chendi: You can only do it if the author wishes not to withdraw proposal and keep continue the discussions with the community. But yeah, if you can ... >>Sumon Ahmed Sabir: Jordi? >>Jordi Palet: I think we should try. We've got today inputs from Mike, we had inputs in the last two days, maybe we can give a try. Okay? So we can talk about this in the next few weeks if necessary. >>Bertrand Cherrier: We'll keep it to the mailing list because you want to. And I would propose that if we can't still reach consensus at the next APNIC 32 meeting in Bangladesh we will just drop the proposal. You okay with that? >>Jordi Palet: Yeah. >>Bertrand Cherrier: Prop-130 is going back to the mailing list. Thank you. >>Ching-Heng Ku: So we move to the next proposal, prop-133, clarification on sub-assignments. Jordi, please make the presentation. >>Jordi Palet: Okay, this proposal or a previous one, better say, has been in discussion I think for the last two or three meetings. It's a topic that has been discussed in all the other RIRs, and the reason for that is all the IPv6 policies come from a joint original policy developed, if I recall correctly, by ARIN, APNIC and RIPE, because the other registries didn't exist at that time. My understanding is that as in other changes that we have been doing in the IPv6 policy recently we duplicated the text in such a way that if something was not clear or broken, we were doing the same mistake everywhere, right? The first thing I need to make sure everybody understands because in the previous discussions we got there was some misunderstanding, is that this is not relevant to allocations, it's relevant only to 33 assignments either to end-users or assignments that in the policy manual we use for specific parts of the LIR infrastructure. So again, we are not changing with this policy, if it reach consensus, anything related to the big allocation that the LIR will get for their subscribers, for their customers. The original, let's say, goal of this policy or of this part of the text of this policy was that if you get an assignment, it is for you. If you are an enterprise, if you are a university, it's only for you. The idea is you can use for whatever usage within your own network, within your own organisation you want to do, but not to sub-assign to third parties. I think that's clear. But the problem is that the text, the actual text has a "must" together with "documented purposes". The result of that is that if I am, for example, a university, I document my request to APNIC for an assignment saying I am going to use this assignment for the equipment of my network, for my own servers, and after a few years you start deploying wireless for your visitors or your guests, this is not matching anymore the original documented purpose. So you will be violating the policy. 34 You have two ways to resolve that. You come back to APNIC and you do a new documentation and APNIC accept that, or we recognise that this was, the way it was written but not the original intent and we change that. So this is what I am trying to do. So the idea is not to change at any point that now you can give to third parties. No, it's to make clear that the original intent, that's why I say "clarification", maybe this confuse people but it's how I read in Spanish, my native language, it was not, "I give this for you only for your machine that you documented in the original document", it's for anything within your infrastructure, okay, not for third parties, not for sub-assigning to third parties. I mention this because there was some discussion about the language in the mailing list and I think it's important to clarify this usage of the "clarification" wording. What happens is that while we have been using mainly IPv4, nobody realised about this because most of the time you get addresses but to your visitors or your guests you use NAT, so you don't violate the policy even if you are using addresses indirectly for purposes that 35 were not initially documented. But in IPv6 we don't have NAT, we use always global addresses, so in IPv6 we will be violating the policy at any time if we documented only a very restrictive part of our own network. I already mentioned examples, I am not going to repeat it. An enterprise or a university is starting to use the addresses for new things that were not originally documented. So that's it. The objective of the policy change is to make sure that we read the text, understanding that the assignment is just for your own infrastructure, for your own network, or for visitors in your network but within your network, not for other third parties. This has been already amended in all the other RIRs, I think it's important to mention that, the same as I mention at the beginning that all the IPv6 policies come from the original policy text. So how I am proposing to resolve that? Again, on your left you have the original text and the original text say: "Assigned address space is address space that is delegated to an LIR, or end-user, for specific use within the internet infrastructure they operate. 36 Assignments must only be made for specific, documented purposes and may not be sub-assigned." So again, "must" and "documented". If you forgot to mention something, you will be violating the policy. If now you do something different, right? So the change which even is making the text shorter, there was a comment on version 1 from the staff that I addressed with this small change, is: "Assigned address space is address space that is delegated to an LIR, or end-user, for exclusive use within the infrastructure they operate." That's it. So we don't change the behaviour, we just facilitate that anyone that documented one usage but now is extending the usage, but it's still within his own network, is not formally violating the policy. Advantages. Resolving the problem, basically. I don't see any possible disadvantage, I don't see any impact on resource holders, and that's it, and I am going to, again, keep in the screen, if there is an input or comment, the text that we have. Thank you. >>Ching-Heng Ku: Thanks, Jordi. Any comments or questions from audience, welcome to the mic. 37 >>Brajesh Jain: Brajesh Jain. I feel that the existing language covers in detail. This proposed language appears to be very restrictive and very sharp. Existing language says assignment must only be made for specific documented purpose. So it gives some leeway and it will be very difficult to establish -- how do you define "internet infrastructure they operate"? So the present language allows, "for specific documented purpose" that leeway is allowed so that somebody can explain that "the infrastructure which I operate and maintain how I do" and it says "must" only there, so I think we should not change it. Thank you. >>Jordi Palet: If you look at the previous version that we discussed in the previous meeting, it had some inputs that you actually provided, you were, if I recall correctly, supporting that proposal. I don't think with this text which is much simpler we are breaking those. I think it's, and according also to the assessment by the staff, if I understood correctly, for them this is much clear, shorter and it don't facilitate anyone to break the original intended rules. On the other way around, it facilitates that if somebody forgot to document something but it's within the infrastructure, they 38 can do it. >>Brajesh Jain: In such a case, what is the issue with the existing language? If staff -- so what we are saying is if staff should exercise those rights, this will be problematic for the staff? I have nothing more to add, thank you. >>Sunny Chendi: Sunny Chendi from APNIC. The existing text doesn't have any issues with the Secretariat staff. >>Simon Sohel Baroi: Simon from Fiber@Home again. Jordi, if you think of a big network, if I can name Reliance Jio, is it possible to like, if they change the network often and they have regional network and they then change it all of a sudden, and missed out some documentation, is there any problem with the present text? We are saying no, right? >>Jordi Palet: But remember, this is not for an allocation, they don't have an allocation. They have an allocation, not an assignment. >>Simon Sohel Baroi: Assignment. So at present I think what you have on the left and the right covers, the left one covers everything, so I don't need to -- I don't think that it needs to be changed. Thank you. >>Jordi Palet: Again, let me repeat it. If you documented, when you requested your assignment, that 39 you are going to connect only your routers and now you want to connect visitors, you are outside the policy. Yes, because it was not documented. >>Bertrand Cherrier: I have a comment. English is not my native language as well. >>Jordi Palet: Neither mine. >>Bertrand Cherrier: None of us. The way I understand the policy, the actual policy, is the way it's written, saying that I ask for IP addresses, I get assigned and I do what I want with them within the documentation I provided to the APNIC. It's up to me to foresee what I'm going to do with the IP addresses. The part I like in this policy is "and may not be sub-assigned", which is the part that you removed for your policy proposal. But I understand it very easily and it's pretty clear, you can do what you want provided that it's written in the document. If you intend to modify the way you use the assigned addresses, then you have to modify the document that was used to get the assignment. >>Jordi Palet: Okay. >>Bertrand Cherrier: So by modifying this policy you're modifying this core thing that you could just do whatever you want with it and not report it. So 40 I just remove my co-chair hat and as a community member from the Pacific region I oppose this proposal. >>Jordi Palet: Okay. Regarding the removal of the "may not be sub-allocated", in version 1 we have that text, the Secretariat told us or told me that it's not necessary because I already put "for exclusive use". So it's a duplication, okay? Now regarding the documentation, do you think it makes sense if 20 years ago you got an assignment, there was no wireless at that time or it was not common, that now you need to change your documentation? >>Bertrand Cherrier: Wireless has got nothing to do with it. >>Jordi Palet: It's one example that you are doing a different usage. >>Bertrand Cherrier: You've got like, I don't know, got /24 for your servers, a /22 for your daily operation and office and everything, 20 years ago everyone was plugged in. Now everyone is wireless. You still operate the IP addresses within what was planned initially. >>Jordi Palet: It depends on how you wrote the document, because maybe in that document your language was -- 41 >>Bertrand Cherrier: You say that it was only plugged? >>Jordi Palet: No. In that document your language, maybe it was like "for all my devices", now it's "also my guest devices". >>Bertrand Cherrier: Just like when you have a flat that you rent and you invite people in it, it's not sub-renting, even if you make them pay to come to your place. >>Jordi Palet: Exactly. And we are making it clear, it's not sub-renting, it's not a sub-allocation, precisely. >>Ching-Heng Ku: Next comment from Brajesh. >>Brajesh Jain: Brajesh Jain again. I would like to add that this nature of network is constantly changing. What we thought that this is our network, suddenly with the software defined network, SDN networks with some part of my machine going to the cloud, I may not have router at all actually, it could be called I don't know what name, it could be an appliance, it could be a switch. So to be able to, and this change will be disturbing all that. So we should have a freedom and the flexibility. I continue my opinion that we should not change it. Thank you. >>Jordi Palet: I see it precisely the other way around. 42 Right now with the existing text we don't have this flexibility. What I am trying to do is to make sure that we have that flexibility. The important goal of this part of the policy was that you don't sub-allocate. I am trying to make sure that anything that is not sub-allocation is allowed. That's the flexibility precisely. >>Mike Burns: Mike Burns IP Trading. I support the proposal. I don't think it makes a lot of sense to track the usage of IP resources per their original intent. We see IP addresses that are being used for things that are wholly different from their original intent, including leasing them for purposes unrelated to their original acquisition or assignment. I think that in an era of no scarcity in IPv6 and pricing in IPv4, the conservation will happen naturally without regards to this documentation request. >>Sunny Chendi: Sunny Chendi from APNIC. Just a clarification on the point that was made, the change of text there. As I mentioned, as Secretariat we don't have any issues with the current policy text, but if someone is proposing to change the text then we do assess it and we provide our comments on the 43 proposed text. We can't go back to the author and say, "Don't propose it. We like it. We don't have any issues with it." So our assessment comments were on the proposed text but we don't have any issues with the current text. >>Ching-Heng Ku: Thanks. If there is no other comments, we will go to the consensus. We will prepare CONFER. So CONFER is ready. So if you strongly support this proposal, please raise your hand. If you support this proposal, please raise your hand. Okay, thanks. If you are neutral about this proposal, please raise your hand. Okay, thanks. If you oppose this proposal, please raise your hand. Okay, thanks. If you strongly oppose this proposal, please raise your hand. Okay, thanks. So based on the consensus so it did not reach the consensus for this proposal. Thanks, Jordi. >>Jordi Palet: Thank you. >>Sumon Ahmed Sabir: Thanks, Jordi. This proposal actually in the list for -- in the discussion for quite a few years, actually, I should say that and -- 44 >>Jordi Palet: Well, I changed it totally, it was much more complex. I tried to simplify it. >>Sumon Ahmed Sabir: We can see some support as well, but large proportion opposing it and the mailing list also we've got some opposition and the consensus, but it is up to you if you want to continue this further. >>Jordi Palet: It's a pity because the guys from India, sorry, I cannot spell correctly the names, I prefer not to make a mistake, the guys from India were supporting it in the previous version and now not, so I need to talk to them to find an agreement on how we do the text. >>Sumon Ahmed Sabir: Let's move to the next policy, the last one. We are running out of time. >>Jordi Palet: Yeah, thank you. >>Sumon Ahmed Sabir: Yeah, it's going back to mailing list, we see there's some support from the floor. >>Jordi Palet: Okay, same or similar situation to the previous proposal. I have got a previous version of this proposal which, to be honest, was too complex, I was trying to change in one shot the full PDP and the inputs I got were, I support this part but not the other. So now I am trying to restrict the change to a very, very minimum part, at least for 45 now the one that I consider more important. So part of it is, as you can see, we are using CONFER and in the future, instead of CONFER it can be a different electronic way to measure or to gauge consensus. So the point is also the chairs state clearly that they are also looking at the mailing list. But if you look at the formal text of the PDP, none of them is there, okay? I don't think that's right. If we don't have in the policy -- in the PDP text the way we do that, how we are following the PDP? We are not definitively, okay? So this is part of the change. There is another change which is making clear that we have a formal process to withdraw a proposal instead of asking the authors to keep editing it or not editing it if they have inputs from the community. So if authors are not proactive, it could expire, that's it, in six months or you keep editing it or it expires so nobody need to do anything else. And then basically the actual text is calling something which is general consensus, that yes, is defined in the SIG guidelines. But there is not any link formally between our PDP and the guidelines. So how come I know that the guidelines are part of 46 the PDP, even if in the slides for the co-chairs we have it every time, etc, etc? I think that's not right. The PDP is our rule and it should be very clear and have cross-references with other documents if they apply, and those need to be decided by the community. I was told that those guidelines were developed about two decades ago by the chairs, the SIG chairs. We had at that time six, now it's not the same situation, so we need to clarify that. So while I am trying to resolve those problems I am not going to explain how is the PDP in every region because it's quite different, there are some similarities but not that many, and the change I am proposing is only to the step 2 in our five steps PDP. Again, on the left you have the existing text and I have marked with red the major changes that I am proposing. I am talking about consensus determination because right now it talks about consensus on the OPM but we are actually looking at the mailing list, so it's not just in the OPM, that's the first big change. It's not a big change, we are already doing that, but it's not formally 47 part of the process. Then I am using the definition of consensus that we are using in all the RIRs which is the same from the IETF which is "rough consensus". We have a discussion the last few days in the list and at the end, Adam Gosling was telling me, "Look, general agreement means this". If you strongly oppose, it's not, and I said, "Okay, that's exactly the same as rough consensus." So it's just changing the name to be something that is standard not something that we define in another document not linked to PDP. And then: "Consensus is determined first considering the SIG mailing list, other electronic means" -- which includes CONFER -- "and the SIG session, and afterwards at the Member Meeting." So basically I am not changing what we are doing but I am making it clear in our PDP. "If there is no consensus on a proposal, the authors can decide to withdraw it. Otherwise, the proposal will be considered as expired by the next OPM, unless a new version is provided, restarting the discussions [in the mailing list]." That's it. I think that the advantage is that we will be really following the PDP if we accept 48 this because right now we are not following the PDP, sorry, but it's like that, and nobody can tell me otherwise. No disadvantage, no impact. References to similar changes that have been done in other registries, and I go back to the key slide which is the proposed text. There has been a discussion in the mailing list. Adam was also proposing some changes in the language but this has been too close to the meeting, we already did a second version on Monday following the staff analysis, so I was thinking if only one person in the list is providing this and I was asking, "Please, if someone else is supporting that say it now so we can change in a third version, otherwise I keep with this text which I think is acceptable." That's it, thank you. >>Sumon Ahmed Sabir: Thank you, Jordi. Just to clarify one thing that you are mentioning about PDP. We actually follow PDP, we also follow SIG guidelines. And I think if you follow the last ten years, every time we are telling that we do this, this, this, we are following mailing list, we incorporate CONFER, even we can move to any other electronic in future, 49 there's no doubt about it, I'm fully aligned with you. And definitely consensus is defined into our guidelines, so it's not only about following PDP, then if you go for that then actually we're conflicting with our guidelines. Information was provided during the last meeting, we -- a similar proposal was there with few additional thing and it was (unclear) that time. And it is absolutely true, this document origin is long ago and so far as I know, the Secretariat has taken initiative to actually rewrite the documents -- right, Sunny, can you update us on that, what the Secretariat is doing regarding PDP guidelines on the documents? >>Sunny Chendi: Thank you, chairs. This is Sunny from APNIC. You are right, it was discussed in the last meeting and the EC, our Executive Board members directed the Secretariat to review the documents, all the policy documents, so we will be doing that this year and most probably reporting in APNIC 50. I just want to, since I'm here, I just want to make a clarification on the -- yes, the PDPs are different in different regions and we have a different way of looking at here. The SIG 50 guidelines and the PDP go hand in hand because they're all developed by the community, agreed by all the individual SIG chairs and co-chairs, we have had many SIGs in the past and it was all agreed. Also the actual PDP document is very simple. It has four steps in there and it says by the headings we can see consensus process. But when you look at the consensus document, which is a lengthy one, it does say in there that the chairs will take consideration of the mailing list, consideration of CONFER and show of hands. If you want me to read it I can read it, but it's there, it's written. So you have to look at -- I agree we didn't link that to the document from the PDP but we can do that after the review is complete, if that's recommended, suggested, but currently everyone needs to, I think, go and look at what it is and what the consensus process is like in this region. Thank you. >>Jordi Palet: The problem, Sunny, is I understand that but I don't think it's so simple as taking the web page where we have the PDP and having a link to the guidelines because that will need the approval of the community. That's my point. We cannot just do that because we don't necessarily agree with the 51 guidelines which were developed by a different group of people, not the community but the SIG chairs 20 years ago. That's the point I am trying to make. >>Sunny Chendi: Well, those guidelines -- there's no guidelines, they are actually census process of this region and it was agreed by the community, we just didn't document that in the PDP documentation, we actually have a separate web page for that. What I meant we didn't link is, you know, when we refer to consensus we should link that to that page where it actually explains clearly what the consensus process is and what the chair's responsibilities is. I don't know if you need consensus for that from the community to link that document to that? >>Jordi Palet: No, what I am saying is I've tried to follow the story of the guidelines and I don't see in the history where the community agreed on those. That's my point. >>Bertrand Cherrier: Are you trying to change the PDP or the SIG guideline? >>Jordi Palet: What I am trying to say is that we don't need the guidelines. >>Bertrand Cherrier: Yes, we do. >>Jordi Palet: No. >>Bertrand Cherrier: It says Policy SIG, therefore we 52 have to follow the SIG guidelines. >>Jordi Palet: If we want the guidelines as they are right now or with changes, we should then review the guidelines as a community, that's my point. >>Sumon Ahmed Sabir: Yeah, definitely, that review is -- we'll definitely review after the Secretariat actually do the research, definitely we will do that. >>Warren Finch: Warren Finch from APNIC. Just a question to you, Sunny. If there's a conflict between those two documents, which is the overriding document? >>Sunny Chendi: There's no conflict actually. >>Warren Finch: I think there is. >>Jordi Palet: There is a conflict, in my point of view. >>Sunny Chendi: I don't know exactly, I'm looking for Sanjaya. But there's no conflict. But if there is conflict, I don't know what was the process in the past. The formal document will be ... >>Jordi Palet: The formal is the PDP, that's the thing. That's the thing. >>Sunny Chendi: Regarding the SIG guidelines, yes, the community can review them but I'd just like to say that that reviewed document should go through all the SIGs, existing SIGs. 53 >>Jordi Palet: Not necessarily because -- >>Sunny Chendi: Yes, the SIG guidelines are per all the SIGs. >>Jordi Palet: What I am trying to say is that maybe the community decide that it's not necessary to have the same guidelines for the policy that for the others because the other working groups, the other SIGs don't make policies. So not necessarily you need the same process. >>Sunny Chendi: Yeah, that's a valid point, yeah. >>Sumon Ahmed Sabir: Thank you very much. I think it's time for going for consensus again on the policy. Can you see the CONFER screen? Those who are participating remotely, please send your -- >>Jordi Palet: That's not the one. >>Sumon Ahmed Sabir: -- feedback to CONFER. >>Jordi Palet: Now, yeah. >>Sumon Ahmed Sabir: So, those who strongly support this proposal, please raise your hand. Thank you. If you support the proposal, please raise your hand. Thank you. If you're neutral, please raise your hand. Thank you. If you oppose the proposal, please put your 54 hand up. Thank you. If you strongly oppose the proposal, please raise your hand. Thank you. So looking at the room temperature, CONFER and mailing list, so we can say that the proposal didn't reach consensus. >>Jordi Palet: Can I make a proposal about this? >>Sumon Ahmed Sabir: Please. >>Jordi Palet: I think the ideal way to resolve this will be to create, I don't know if calling task force to have some thinking on this. People from the community that volunteer to participate and then provide inputs and then maybe draft a new policy proposal and meanwhile keep this one dormant or abandon it or whatever is necessary. That may be a way. >>Sunny Chendi: May I suggest, Jordi, that since the EC directed the Secretariat to review the documents, let us finish the review of the documents, we'll present the recommendations of the document and then the community can do whatever they want to do after that, if they want to put a proposal in. Is that a fair call? >>Jordi Palet: My point is that this is a community decision, not -- 55 >>Sunny Chendi: I'm asking you -- >>Jordi Palet: Otherwise, it's not a bottom-up approach, that's the thing. >>Sunny Chendi: Is that a fair call for this community because it was discussed last time and the EC said let's review it because it keeps coming up and we will do it. >>Jordi Palet: I am happy waiting for that review and then going into a task force or whatever is necessary, but not accepting the review as the final decision. >>Sumon Ahmed Sabir: Definitely, not at all, it will be reviewed by the Secretariat, then it will come to the Policy SIG and if the community agrees -- if community wants some modification/addition/deletion, after all that, actually, and community agrees, then we can make the changes. >>Jordi Palet: I am fine with that and we just need to know the timing for that review and how we can provide the inputs. >>Sumon Ahmed Sabir: Before going to that level, the first thing that we abandon the proposal here? >>Jordi Palet: In that situation if we have -- how much time do you think you will get that review? >>Sunny Chendi: By the next conference. 56 >>Jordi Palet: Meanwhile, I am happy to withdraw the proposal. >>Sumon Ahmed Sabir: Thank you very much. >>Jordi Palet: Thank you. >>Sumon Ahmed Sabir: The proposal is withdrawn by the author. That ends the Policy SIG session APNIC 49. Thank you very much for being here. Thanks for the participation. Let's go for lunch. Thank you. APPLAUSE 57