SPEAKER: Gert: Good morning everybody. You can hear me. This is now smoothly going into the Address Policy Working Group. /SEUPBGS we have so mean nice 20 year of RIPE celebration this is week I couldn't get all the time slots I have been hoping for. So I still have 45 stole 45 minutes from the RIR reports, so this is why Paul had to rush things a bit.

We actually have enough time in Address Policy to discuss everything that's on our plates. We might cut some of the discussions a bit short and defer them to the mailing list, but that's the way we work anyway, make the discussions on the mailing list.

So, to introduce me to those that have not been to an Address Policy meeting before. I am Gert Doring, I am the Chair of the Address Policy Working Group and Sander Steffan is my co-chair. If there is anything you want to clarify, tell us, feel tree to approach. If you have any questions, feel free to jump up and down and go to the microphones. And now let's start with the meeting.

This is the overall agenda of what we are going to do today and tomorrow morning. We will have a presentation about current policy issues in all the regions, especially in our own region of course. A short problem statement about the current ASN 32-bit policy and possibly discussion about how to, or whether to do anything about it and if yes, what?

Then I will give a short overview of what's going on in our region regarding new policy proposals, and then we will discuss all open policy proposals in detail.

If we have time at the end of tomorrow's time slot, we will have an open policy hour, meaning that if you have anything that you want to discuss like I have noticed that there is this weird clause in one of the policy documents, is this intended or is this an oversight? Should we do anything about it? This is the time to speak up.

In a little bit more detail. This is what's going to happen in these 45 minutes now. Administrative stuff, current policy topics present by fill ease and the ASN 32-bit stuff by Daniel Karrenberg. The second time slot today right after the to havey break will give the overview of the new policy proposals. Discuss the PI and special case related policies and start with the end of IPv4 related policy proposals.

And tomorrow will see these proposals. All this is in the green sheet that you have in your meeting pack. So if I am a bit fast here, you have it in writing so if you want to see at what time something is taking place, this is exactly as printed.

Now, agenda bashing.

If there is something in the way that's incompatible to other Working Group or if something is missing or whatever, please feel free to speak up now. Otherwise we will just do it as proposed.

Okay, I see Nigel jumping to the phone.

AUDIENCE SPEAKER: Nigel Titley, RIPE NCC. I have just noticed /THATD discussion of 200808 is tomorrow. Whereas it's actually going to be, there is going to be a presentation by Axel on 2008 /08 in the NCC it wases Working Group today. So we are a bit back to front.

SPEAKER: Thanks very much for pointing that out indeed. We are not going to discuss 2008 /08 in the Address Policy Working Group because at the Dubai meeting, we figured out that there could be unintended consequences of having certificates and no clear defined revocation policy. So it was decided that it would be more useful to discuss in NCC services how to generally proceed with the certificates and if we have a consensus on that, then come back to Address Policy and discuss this.

Thanks again for spotting this. I think we can repeat the announcement at the end of today and that will sort of sort out things.

Okay. I see nobody else coming up.

The minutes of last meeting have been sent to the list. I have not received any comments about imprecise things or omissions. So, if there is nothing else, I will just declare them final. A big thanks to the minute takers because it was really a huge amount of work and very detailed work.
(Applause)
And also thanks to the scribes for today. The RIPE NCC staff has sort of been volunteered to help with this. It's a huge amount of work and they do a great job. So thanks again.

So, that's from me. Now, we have some 25 minutes for Phyllis (F I L I Z)

SPEAKER: Good morning everybody. Filiz from RIPE NCC, policy development manager. I will just quickly go through the current policy topics.

Formally I was given enough time but we again having time constraints, so I will be speaking quite fast. So I apologise upfront about that.

To start with, I have an administrative announcement to make. We have a change in the crew actually and now I think grid, who some you are familiar with, she is a transfer from our loved registration services, I kind of stole her from that department and if she can wave, she is here, and that's her photo. You can ask any policy questions to me and to her. We will be here until the end of the week.

So, the overview of the presentation is basically, most of you know is. We are going to start with the RIPE policy update and policy development update which means I will talk about the accepted proposals and old ones as well as the ongoing issues just to give you an overview before we start discussing them in detail in this Address Policy Working Group session.

/THR-G a section about other regions looking at policy suggestions, what's happening in the other parts of the world, and I am quite /TKPWROR /K-L in mind and this is why I kind of try to follow (categorical) topic by topic team, but this is my way of understanding things. It is a selection and it is not to show you each and every proposal that is in old fora all over, but more like where I see resemblance or similarity or relating issues.

So now, starting with, we had two withdrawn proposals recently. One of them is IPv6 ULA central. The proposal decided not to pursue this within the RIPE PDP fora, but give it a rest for a while probably.

The other one we had was ASPLAIN format for the registration of 4 byte ASNs or 32 sit ASN numbers. We use 32-bit within our region here, as you may hear 4 bytes from our regions. But it's the same thing.

The reason the proposal was withdrawn was because there was an RFC IETF took action and they published this 53 /96 in December 2008. Then this made the proposal basically redundant or mute, if you would like to call T but obviously, having the RFC published, we had to act on it because it was changing the format of how reregister these AS numbers, so we went and done that. We ran a project company wide, where RIPE database is updated. Now the ASNs can be registered there in -- in ASPLAIN format. So 2-bit ASPLAIN format which was important for them especially.

Then policy /TKOEPLTS and FAGs and web pages are updated too. So at the moment. We are SA dot format free.

Other car /KAOEUF stuff are from the accepted proposals. We had three, and the first one is (archive) probably a lot of -- most of you are very familiar with that now, it has been there for a while. (2007-01). I am talking about -- Gert is confusing me now. My slides are correct. 2007-01. I am talk /PW-GT direct Internet resource assignments to end users where we require now contractual relationship proof of an end user with the RIPE NCC or with a sponsoring LIR prior to they can be assigned end user assignments.

Now, it is the first phase. You might remember this became a big scale project again with the RIPE NCC upon acceptance and the first phase is complete, it's done, and it is in effect. And I am not going to go into the details here about this because there will be a separate presentation today in the NCC ^ it wases Working Group by my colleague Andrea, who was the project manager actually. So, please go and see that presentation for have we done about this implementation, implementation and what the next steps will be.

Enabling methods for reallocation of IPv4 resources, AKA transfer proposal in RIPE. It has been accepted in the summer 2008 and just before the end of 2008 and beginning of the year, 2009, January, we have implemented this as well so this is a policy in effect actually.

Now, the other one, some you probably will be really happy about this. 2006-01 provider independent IPv6 assignments for end users. So as of today, I am happy to announce now that some my colleagues are preparing their mail to be sent out to the mailing list saying that yes, we have implemented and as of today we are ready to receive your requests. So, this is just the news of today. And thanks to our registration services September to act very quickly about this implementation.

(Department (in now the discussion phase, we have a lot of proposals, that's why the agenda for the Address Policy Working Group is all so packed. And I listed them all here.

Use of final /8. I am not going to get into details. It speaks for itself. How are we going to use that last /8 we are going to get from IANA in the near future.

Ensuring efficient use of historical IPv4 resources. Talking about oh maybe legacy space should be involved in where we are to allocate more space to an organisation, the 880 percent should apply to that old kind of space that they are holding.

Certification, Nigel has just made an announcement.

Global policy for the allocation of IPv4 blocks to regional Internet registries: This is a new one and further in my slides I will give more details about this.

Allocating /assigning resources to the RIPE NCC. This is a proposal where the proposal is putting in a mechanism so that the RIPE NCC can be included in the policy world so receive some resources for the operations and the services that RIPE NCC is providing. Otherwise we have been excluding the software for that.

We have three more in discussion phase. One out fairly. Coming from Daniel /KR-PB bearing, Randy Bush and Nigel Titley. What happened here, Daniel will give a detailed presentation about this again here. But it is about, you might remember those who were in Dubai, there was this concern and idea of, or envision of what happens if a very big request comes in the very, towards the end of the IPv4 pool and then most of the space is gone in one go, are we concerned about this? If we are, what can we do about that? So this is the proposal focusing on that issue. And coming up with some proposed arguments and solutions.

IPv4 allocation and assignments to facilitate IPv6 deployment: This is another proposal which is relating to the last /8 that the RIPE NCC will receive from IANA, and how to use it. And the argument in this one is to use it towards the deployment of IPv6 as an incentive and give pieces from this block for those people who will use it for dual stack translators.

Multiple IPv6 /32 allocations for LIRs: Some LIRs seem to need, or argued to need more than one IPv6 allocation to be able to operate, and this proposal is for that.

In the real phase review phase we have two PI assignment size. It's 2006, it is talking about setting a minimum assignment size for PI assignments that the RIPE NCC will make to end users in IPv4 world.

Anycasting assignments for TLDs and tier 0 /1 ENUM. We already had a policy for Anycasting TLDs. And with this proposal it's proposed to go beyond and cover ENUMs as well and also increase the amount of address space that's going to be assigned and details will follow because we have the presenter, proposer among us, he will make a presentation.

Now, I am doing all right with time, right?

Worldwide look by topic: So what's happening in the rest of the world? What are the other folks talking about?

Again, disclaimer. This is my selection of proposals and topics. It's not the whole lot. RIR, PDPs, all of them, they are public out there and they have their own regional issues but some of them relate. Some of them are common, or I see some resemblance between solutions or sometimes intentions, okay? So that is the categorisation.

IPv4 after life: They didn't name T this is my title, and I see two proposals that are relating to how are we going to be -- what's going to be the future like when the IANA pool depletes? So these two proposals were relating to that future time? And ARIN discussed one IPv4 version recovery fund which related to their transfer proposal and they abandoned that, but what they discussed there was about giving some financial incentives for returns to be possible, and ARIN was sitting in the middle of it so those people who would like to return some space and those people who would need, they would kind of come together around ARIN. But, yeah, that is not in their PDP any more. They have discussed this and closed the case, last week actually they had their meeting.

And then the global policy. , the one I just mentioned a couple of slides before. This is a new one. Now, as of just a clarification of definition, what is a global policy? Those policies relating, or guiding RIRs and IANA how to receive blocks from IANA as far as RIRs goes is are defined in global policies. So, we have three of them. Basically how we get space, IPv6 from IANA, how we get is an blocks from IANA and how we get IPv4 blocks. As you know IPv4 blocks is for are in blocks of /8s but that will only be possible until those /8s are there. And this new one is talking about what's going to happen after they're depleted. There will be again a detailed presentation but the main idea is there might be some returned space at that time and what the RIRs can do, collect that returned space within their region, return it back to IANA so that there will be a new pool generated through that way by that mechanism and then once there is a pool, sufficient enough pool, that address space will be allocated back to RIRs by IANA.

One little note here it took an interesting twist here because ARIN, following their RM PDP, they changed the text of the proposal slightly so they thought that this could receive consensus in their region. So what happened then, they have four proposals in four RIR fora which are different than ARINs. And the main difference is ARIN is talking about legacy space should be mandatory to be returned for RIRs. While the other four versions are talking about all the space. They don't make a distinction in the return space, type of the return space. But yeah, Axel will go through this later on.

Now, prudence proposals:
There are a lot of them. So these are the proposals where people start thinking of okay, how do we want to use this last /8 or last /9, last /10, whatever we have, but it will be the last space. ARIN adopted a dedicated IPv4 blocks to facilitate IPv6 deployment as a policy now. So what are they going to do? They will reserve /10 from the last /8 or another block? But a /10 will be reserved only for those dual stack translators and there will be made assignments of minimum /28s or max. Numb /24 for those people.

APNIC atopped the use of final /8, which is exactly -- well not exactly but primarily the same or very similar to ours, and Philip Sinnott is going to present it here so I am not going to get into the details.

LACNIC also adopted one. From the last /8 /-RBGTS they will reserve a /12 and they will use it for new entrants. /22s for new ISPs and /24s for critical infrastructure.

AfriNIC is also discussing a similar thing. They call it IPv4 soft landing policy. So the names vary. If you want to go through and check you can use these references. They are talking about giving one allocation or allocating one block per LIR. Based on the fact, or the criteria that they have an IPv6 adoption plan and they are also going to change the allocation period to eight months if this is accepted. And they will reserve /16 for unforeseen circumstances.

APNIC adopted the legacy, including the legacy space in the 80 percent usage criteria for further allocations.

LACNIC is discussing recovering resources, basically returns, and reducing the minimum allocation size to a /22. So that's how they, what they are focusing on.

ARIN has also discussed last week a proposal called "Depleted IPv4 reserves" and now I understand it is abandoned, but what they were discussing was from the last -- when they reach the last /9 in their own pool, they would start allocating a single /20 within a six-month period. But this discussion is now closed because they dropped the proposal after their meeting.

Now, running out fairly: I used the title from Daniel Karrenberg's proposal that is in place in RIPE PDP. But APNIC also discussed in their meeting, last meeting in February, two proposals where they were looking at shall we gradually decrease the maximum allocation size and maybe reduce the allocation period as well? And they dropped those proposals. They couldn't reach consensus on those two, so they are not any discussion points but they have discussed them.

And now in RIPE, what we will be discussing through the run-out fairly proposal, mainly should we gradually decrease the allocation and assignment periods?

Transfers:
This has been a long one and ongoing for a while, for most of the policy fora. And you have seen reports from RIR members here, and I listed all these but this is for your reference. There had been changes because there was a proposal, then it was changed with another name and then there was another proposal which was an addition of that previous proposal, don't get confused. What is going to happen basically, ARIN is discussing and there is one in place in their PDP at the moment, I will show the details in -- I made a matrix to make it more clear or simpler to see the facts. And APNIC has reached their last call in their transfer proposal and as of 1 May, and now they are Working Group chairs are expected to make a decision. But what they have discussed as well, apart from their main transfer proposal, they have discussed two ideas newly introduced new ideas, justifying receiving IPv4 address space and reapplication limits over the transfers. Because those two things are not part of their transfer proposal that has reached consensus at the moment.

And this is the matrix, if you would like to have a look where the main differences are. The first criteria -- and these are the points that are, that received most of the attention, that's why I made a matrix out of them. Prior RIR approval, so justification need exists in all three regions. Ours was accepted anyway. ARIN and LACNIC also have that. APNIC doesn't have it but working on two other proposals like I said and they will be discussed in August soon.

And the other main thing, for example, type of address space. In RIPE it is only applying LIR allocations. While in other regions PI and PA are part of the transfer policy that they are going to deploy, according to those proposals they have in hand at the moment.

And one other prominent thing is that APNIC has passed inter RIR transfer parameter within their transfer proposal while all other regions are now only focusing on within the region transfers.

I am getting to the end very quickly.
IPv6: There are two things that are being discussed. One of them is community networks and not profit networks. We saw that in ARIN and currently in AfriNIC, they are still discussing. IPv6 multiple discrete networks, which is very similar to the proposal that we are going to discuss today. Multiple /32 allocations for LIRs. They are looking at, yeah, okay, some LIRs may need more than one prefix for IPv6 address space.

And LACNIC has been concentrating on maybe changing their allocation criteria, because they are talking deaggregation now, because they feel that as some larger LIRs, and ISPs who receive largest IPv6 block may want to chop it into two, three, whatever and they couldn't do it because policy is set at the moment requiring to, requiring them to announce it as a single block which kind of relates to the one we have here again from another angle, a different way of you know, looking at the similar problems. And they are also talking about should we change the new allocation criteria? Because maybe, at this moment, having IPv4 space should be enough to receive IPv6 space.

Is ans: Main topic is 2010. About like seven months from now, there will be some change and I am not going to get into the detail. Daniel will be focusing some part of it for our region and that is a topic for other two regions as well.

These are my references. And if you don't believe me what I said here, you can go there or we have the RIR colleagues as you know all through the week. So you can stop them and ask them. And one last slide. I am really proud of myself that I am in time. So I can now you know, say my last minute on this last slide.

We were actual at the last RIPE meet that go we should take on cosmetic surgery project over the policy documents. So don't make the policy, just make them readable we heard from you and what we have done is, what we have done about that: We started with the RIPE policy development process document and this was now in hands of Rob ^ locks all, I believe we will hear from him soon about that. And what we also went on doing, we presented a project plan to the Address Policy Working Group chairs because we are going to work with them throughout this project, and they have approved our plan. Simply the plan is: First start with the easiest one, short condensed ones and those ones which don't get change very figurely. These are IPv6, ISP, IXP, ^ is an and IPv6 root server policy documents.

And then move on with quite tricky ones: IPv4 and IPv6. Area they tricky? They are long and they get updated because they receive attention from all those proposals that we are receiving. And this process can take one-and-a-half years. We will do our best trying to do them in parallel sessions but it may be quite hard while we are having also policy developments affecting those core documents, original documents.

The main thing I can tell is that transparency is the key here. So what we are going to do: We are going to publish the updated draft document where we improve the language and the structure, consistency and the flow so no policy changes. You will review it for a month, same as we do with the policy proposals, and then Address Policy Working Group chairs will be asked if they see consensus from you guys, and then if they tell us yeah, go ahead, only after this we will make the publishing realised. Okay?

So, that's my presentation.

(Applause)

CHAIR: Thank you very much Filiz for giving this overview. And letting me hurry you up.

Now we have Daniel Karrenberg presenting observations on the 32-bit ASs and how it works out and how the policy might cause issues. We are running quite close to the coffee break, so I apologise to Daniel for putting him into this uncomfortable spot. I might take a few minutes of your coffee break and if we see that there is lots of desire to discuss this in depth, we will just move it to the beginning of the next time slot. So there will not be too much going into the coffee.

SPEAKER: My name is Daniel Karrenberg, I am the chief scientist at the RIPE NCC and in this case I am only the messenger. This presentation was done actually by quite a number of people in the RIPE NCC in registration services, the science group, and Filiz also helped with it and if you want to hear some more stories about how you combine different PowerPoint files into one presentation, see me in the coffee break. I would also like to thank Susanne agrey of the ^ comes department in the RIPE NCC because she actually burned some midnight oil last night trying to smooth out the different form as into one presentation.

But anyway, the slides are mine, so if there is any issues with them, blame me.

What is this about? This is about 16 end 3 /# bit number /SA*PBS. /THAOER some statistics about the first quarter of this /KWRAOEFRPLT we basically assigned a little more than 500 ASNs and out of those (ASNs) almost 80 percent were requested 16 bit from the start. You may remember that the policy now is that if you don't say you want a 16 bit ASN, you get a 32-bit ASN by default but actually around 80 percent of the people who wanted some said from the start, no we want a 16-bit one.

Of the rest, 10 percent of the total realised that once they got the 32, that that wasn't really what they wanted, so they went and swapped it.

Another 10 percent actually took the 32-bit and 38 are still sort of in the process.

Now, why were things exchanged? Well, actually 40 percent said that their hardware cannot deal with it. Hardware or software and it will not be able to deal with it because it's outdated and cannot be updated.

21 percent of the people who wanted 16-bit said, at the moment we don't have the right version of our operating system or router software.

There were also /OPL other reasons and I'll leave that for you to read if you want to read the presentation, it's uploaded. There are some issues. All this is backward compatible thanks to the design of Geoff Huston and others in the IETF. But there are some issues if you have, if you are not 32-bit, or if you talk 16-bit ASN peers and multiple of them and want to do traffic engineers /*BG nearing, apparently there are some issues and then there is also some issues which my colleagues said the merits of these considerations might be challenged. And definitely we tried to provide some guidance in these cases but this is besides the main point here.

Our current policy statement is sort of forth RIPE NCC is: That as I said, as of beginning of this year, assignments will be 32-bit only unless you request specifically something else, but even more string /EPBL from the 1 January next year, which is lest than twelve months ahead, we will address using undifferentiated pool. What that means, a really nice policy term, but unfortunately our policy, whilst we haven't set a policy on how we want to assign after January 1, and what we propose to do and it doesn't require policy change, that's just a procedural change, or not change, you know, it's a procedural matter, is we will just continue the current way after the 1 January 2010, unless we hear differently from you, the RIPE community. So that will mean that you know /TPURBGS specifically request a 16-bit, we will give you a 16-bit.

However, we might not have it and that's the point.

So here is about undifferentiated pools. On the left you see the situation until the end of this year, we maintain two pools of ASN numbers. One is the ASN 16. The other is the ASN /P 2 and I will not going into the finer points of language here. I am just trying to explain the basic principle.

As of the 1 January 2010. This will be one pool. There will just be different coloured things in it but it will be one pool. That doesn't make a difference for the things I just said. We can just you know pick a yellow one or a blue one, depending on -- by default we'll pick a blue one but if you say you want yellow, you'll get yellow. For the re/PHREPB I recollect it will mean a difference. This year we maintain two pools and the IANA recognises that we have two pools and if we run out of the yellow ones, they will give us more yellow ones. As of 2010, the IANA will work with an undifferentiated pool just like we do, and they will say it's one pool and once we run out of the yellow colour and go /ABG to them and say we want more, and they might have, it's likely that they will have some yellow ones, they will say you haven't run down your pool and your pool is still full and if you say it's blue ones, they say it's an undifferentiated pool, you haven't run it down so you don't get any more. So that point we can't give you any yellow ones because we don't have them. So this slide actually says this in policy language.

So the risk here is that the RIPE NCC will not qualify for new 16-bit ASN blocks due to the old user trade of the 32-bit only blocks. (Rate) is this clear? Thank you.

So, next: Statistics:

This is Geoff Huston sufficient on port radio on projections on when we are going to run out on 16-bit ASNs. This is only 16-bit ASNs and he has a variety of looking into the crystal ball which seems to be exponential and it says, this will be depleted in around the 2012, start of 2012. So three years from now. Well a little bit less than three years from now. He has a green variety of the crystal ball that says it will be much later, sort of somewhere in 2013. Now, before I stand up here with a chief scientist's hat on and tell you about the future, I said okay, this is Geoff's work and I respect him very much. But let's check.

So, the science group in the NCC did a little bit of work and he checked and he has a little bit different methodology, because he takes into account the stuff that Leslie was telling us this morning that they actually reclaiming a lot of ASN 16. And this work actually takes this into account and it comes out at mid-2013 as the run-out date. So that's -- we admit -- that's four years from now.

I don't think we need to go into a debate which numbers are better but it's certainly sort of -- we can see that whatever you do in terms of real sort of scientific work on it, or rigorous work on T it's going to be more than three years before we run out and that's my point. So, where are we so far?

The current policy was drafted around operational incentive. That was a very nice euphemism for saying hi let's push people to get ready and a much earlier run out date, earlier than three years from now definitely.

Fact number 1 is that we see that operationly our members don't seem to be ready, because you know, 80 percent of them want ASN 16 from the start and like 40 percent of those say our equipment is not likely to be ever ready. We have to take this at face value. But, it may be they are not ready, it may be /THUR just lazy, I don't know, I can't know.

Fact number 2 is: There is much more 16-bit left than we actually previously expected when these policies were made.

So the question is: Do we need to sync the policy with the current facts? How can could we sync -- what are the alternatives before us? And I really try to put this black and white and very quickly because I anticipated I would be before the coffee break and you all have a caffeine craving right now.

I see, and this is definitely my personal work. I see three alternatives: One is do nothing. Two is just extend the global policy by twelve months and three is: Just to change the thing totally and say let's run out of ASN 16 and not do the operational incentive.

I'll go through these three and give you the pros and cons of them.

The do nothing thing the pro is obviously it's easy, we don't need to do anything. Filiz doesn't get sleepless nights and all that stuff.

The other pro is that there is a large incentive for members to get ready for ASN 32 because it's quite clear from 2010, you won't get them, or at least if we do the thing that we proposed earlier, it will be sometime in 2010 that you won't get them at the point when IANA doesn't give us any more because we have this stock of 32 there that prevents us from getting any more.

The cons are: Angry members. Well Axel doesn't like that. The board doesn't like that either. And I kind of don't like it because I have to stand up here and give you these kind of presentations.

But, more to the point: If there is only some truth to the stuff we are hearing, there will be operational issues and that's really something we don't want.

Also, there is a slightly more political thing, if you will, because how it would look like to people who are not involved in this and don't note history of the proposal and the wrong assumptions, or the a/S-PLGSs that didn't quite come out that went into it, it would look like that the RIRs or the RIPE NCC in this case would hold back a large amount of 16-bit ASN, three to four years worth, while not give it out by a decision of the policy process, and it would be seen as a artificial. You know, area they holding this back while it's still there? People have problems with it. And even worse, it could be seen as a barrier for new entrants because yeah, all you in the room probably have enough ASN to go around but the people what want the start the ISP business and become autonomous in routing terms couldn't get them, so it would be like, it would very much look like a cartel trying to prevent new entrants. So that's also something we need to have in the back of our mind.

Second alternative: Extend the global policy by 12 months.
Basically say it's not 2010 when the I ever differentiated pool will start but it's going to be 2011. The pros: It addresses all the cons in the previous slide for about a year. There is no substantial change in the policy. You are just change one date. The discussion about is there something principally changing, ^ /TKARBGS /TKARBGS? You just say hey, it's another year, we have enough of them, we see the problems, let's do that.

The cons is:
It needs a policy action by all RIRs because this thing is a global policy and way the global policies is all RIRs have to agree on this, all the policy processes of RIRs have to agree on this. And obviously there is going to be less incentive to get ready for ASN 32s and we may end up here again and I may end up here in this spot again in another twelve months.

Third alternative is basically say let's run out of ASN 16s. Let's just do the same thing or similar thing that we expect for IPv4 and mind you, we expect now that we run out of ASN 16s after we run out of IPv4. So that addresses all issues, but it's a more complex global policy change. We may not converge before the end of the year. And that's a very big worry. And obviously it's the least incentive to get ready for ASN 32.

So the other regions, Filiz already told you what's going on.

So these alternatives are before us and that's my last slide.


CHAIR: Thanks very much Daniel for bringing up the problem.

(Applause)

CHAIR: And I actually propose to postpone the discussion until after coffee. So people, please be here right on time at eleven o'clock, because we have lots of things to do and this is an important matter. Eleven o'clock back here.

(Coffee break)