Archives

These are unedited transcripts and may contain errors.

Address policy session on Wednesday, 18 April, 2012, 9 a.m. to 10:30 a.m.:

GERT DORING: Good morning, dear Working Group. So good morning again. This is address policy if you are interested in DNS you are in the wrong room. If you are still hung?over from yesterday evening, I am glad you are here, so I know how hard it is to be here at 9:00 in the morning after a nice social in the evening, so I did appreciate that.

I am Gert Doring, for those that happen to be here for the first time, I am your Working Group Chair, Sander Steffan is your co?chair. If there is anything you want to know about address policy details, etc., etc., feel free to approach either one of us at any time, ask questions and we are here to help.

So, what are we going to do today? This is the overall agenda of today and tomorrow's address policy time slot. Today, we have a couple of presentations sort of like to set the stage, bring everybody up to the same level of understanding and discussions about policy proposals currently in the policy development process system. And tomorrow, we have a couple of things that are not yet formal policy proposals but are very likely to become some, and I am not going into more detail.

So we usually start with some administrative details like thanking the scribe and I am now doing that. Thanks for folks from RIPE NCC for typing down everything we say here and providing great minutes here, at 9:00 in the morning, so thank you.

Then, the big thing in the morning is Emilio about policy talks, policy status worldwide and here, and then feedback from the RIPE NCC registration services, from Alex. And then we go into discussion of the currently open policy proposals, which are these, and if we have time, we will have some thoughts from the Working Group Chairs about what is consensus and how do we think that the policy development process works. That one might go to Thursday if the discussion takes longer than planned, or if you really use up the time. It's perfectly fine, we have time tomorrow to do that.

That is why the numbering with F and E is a bit weird, but originally planned to have it first, and then we shuffled.

That is for tomorrow.

A couple of things that have come up and need discussion, should be discussed and will maybe end up in formal policy proposals, the slides are on the web anyway so I am not going to read this all out to you.

So, is there anything you want to see there? Is there anything that needs to be moved around? OK. There isn't.

The minutes from last RIPE meeting in Vienna have been sent to the list. Thanks again to the NCC for providing a tremendous piece of work. I haven't received any feedback yet, so unless somebody speaks up now and says, oh this is not correct, I have been quoted wrong, I declare them final. So anything? OK. So, all the formal bits for today are done. Now, I welcome Emilio Madaio from the RIPE NCC. In case you don't know him, he is the good soul at the NCC who helps us keep track of the nitty?gritty of the process, reminds us when the Working Group chairs have to do something and so on.

EMILIO MADAIO: Thank you. Good morning, Working Group, I come from Italy and I work in the RIPE NCC as policy development officer. I give you the usually ?? the usual update on what goes on in the policy system of the other RIRs, what changed from RIPE 63 until today in our policy system, and some of the activities that keep me busy NCC.

Focusing on the common policy topics, what we have in common and in difference with the other RIR, I will focus on v4 depletion, v6 deployment and Internet resource transfers.

V4 depletion, this draft policy, 2012?4 is active in ARIN PDP, will be discussed next week at the ARIN meeting in Vancouver. It's a change of what we would call here the assignment periods, organisation will be able to request up to 12 months supply instead of the current three months supply of IPv4 address space if they are a member ?? have been member of the ARIN for more than one year and if ARIN hasn't ?? hasn't sit their last /8. In the AfriNIC region in December, AfriNIC board ratified the policy, the soft landing policy, what we will call in our community last /8 policy, it was the fourth version and a long discussion happened all AfriNIC meeting but at the last meeting they reached consensus and in December the Board ratified it.

In LACNIC, this first policy proposal did not reach consensus at the last LACNIC meeting, and basically, makes mandatory the usage of IPv4 address space handed out by LACNIC within the LACNIC region and after the public discussion, the policy Chairs decided to send it back to the mailing list so it's still active in the LACNIC PDP the other proposal, 2011?06 was accepted, reached consensus, was ratified by the LACNIC Board, basically now in the LACNIC pool there is a /12 reserve. As soon as lack lick won't be able to satisfy a request of IPv4 address space to an organisation, that pool will be used to make sure the organisation will receive a final prefix of between /24 and /22.

Moving on. IPv6 deployment. This three policy proposals were discussed at the last APNIC meeting and the first one reached consensus and is now in last call, the described the techniques for IPv6 allocation that the APNIC registration service implements. The other two proposals were sent back to the mailing list for further discussion. Proposal 101 is something that you might recall as the one we had in 2011?O2, that will be also described on my colleague Alex. It's about removing the multi?homing requirement for PI IPv6 space. The other one tried to define what an organisation has to do, what criteria has to follow in order to receive a large prefix of IPv6. Both are still under discussion in the APNIC mailing list.

In the LACNIC region, these two policy proposals were accepted and were ratified by the Board. They are quite similar now it's mandatory to request IPv6 address space if an organisation doesn't hold it already. When similar organisation is requesting IPv4 address space for the first time or for an additional allocation.

In the ARIN region, this draft policy is active in the PDP, will be discussed in the coming ARIN meeting in Vancouver and intends to simplify the criteria for subsequent IPv6 allocation.

And concluding, the common policy topics; Internet resource transfers, these two draft policies in the ARIN region will be discussed at the public meeting, the first one defiance the Inter?RIR transfer from and to the ARIN service region. The second one has to do with intra RIR transfer and basically extended the policy of the intra RIR transfer between RIRs not only to Internet resources like IPv4 but also autonomous system numbers and maybe it's worth specifying it has nothing to do with measuring acquisition type of transfer; just basically from one RIR to another. Worth mentioning for historical reason, proposal 95 in the APNIC community reached consensus and was ratified last year since the APNIC conference, APNIC 31. Just to let you know that the only RIR with an intra RIR transfer policy active is APNIC at the moment.

And what happened in the RIPE Community. Well, since RIPE 63, 2011?O2 was approved and ?? approved and started implementation around February. It's about removal of multi?homing requirements for IPv6 space. More details will be given in the following presentation. We were asked to keep track of how the assignments were going to increase or decrease after the approval of this policy.

2011?01 is the other proposal that was approved. It is the global policy proposal that reached consensus also in the other RIR communities. At the moment, it is under review of the ICANN Board and the outcome of this review is expected not later than the middle of May.

2011?04 and 05 are two policy proposals that you should know very well, active in the at last call. We won't have a presentation by the proposer on this proposal. However, these are the two policy proposal at the moment in the initial discussion phase of the RIPE PDP. The first one has a new version that was published at the beginning of the week, and it's under discussion in the Anti?Abuse Working Group mailing list, will be discussed on Thursday in the anti?abuse session at the RIPE 64. 2012?01 is instead the intra RIR address transfer policy proposal that was submitted some weeks ago and you will have a presentation from the author.

Now, briefly about the policy development office activity. I have a priority on describe ago bit in detail this, it is important for our policy framework. It started in RIPE 59, the NCC was tasked to review six policy documents and change them, only the textual level. It is at cosmetic intervention we do not even in change policies here and the four we published a new draft of the policy documents, the community, you, review it. If you are fine with that, we update the documents; otherwise more discussion goes on. And so far the status is that ex RIPE 463 became 496, the policy for autonomous system was updated. At the moment, the new draft we published is the one related to RIPE 302, policy for reverse delegation and the review period ended yesterday so there is no more time to give input. However, input is necessary to move on and you will hear from the address policy Working Group Chair on the next step. For more information, for the status of the cosmetic surgery project, for some background on the project itself, there is the link you should access to.

What is important to me to to say is something about the other four policy documents planned for this cosmetic surgery. Something that I said already at RIPE 63. These poll seep documents are extremely sensitive at the moment, apparently, and they will be very likely in the foreseeable future. That means that you, the community, are very interested in keeping an eye on this, maybe change it and update it, as I said before, the RIPE PDP has priority over the cosmetic surgery project. We want to know what is the document you want and how you want to change it at the real core level before touching it esthetically, before intervening with cosmetic surgery project. So it's possible when we will have completed the cosmetic surgery project on the policy for reverse delegation, in agreement with the address policy Working Group Chair, we will we consider the work and maybe redesign the plan and depending on what would be the situation also, the scope.

We are not going into the details of the impact analysis, maybe Alex will mention it later so how the NCC let you know what we understood of your policy proposal and what impact we foreseen coming if the policy proposal become a policy. I just want to spend some five seconds to acknowledge and thank the collaboration and reach out involved into, to all the other policy development officers in the other RIRs and all the other RIR staff that are helping us in ?? helping the NCC and me in keeping an eye on all this public policy development all over the Internet planning industry. One of the proof of this collaboration is available to you on the NRO website. This is a link on our current proposal web page related to the comparative policy matrix that we PDOs update regularly.

Concluding some references. This is the document that you all know, the RIPE PDP you all know and love. This is the other web page is one of the most clicked in the RIPE meeting when you can find all the proposals we are going to talk about. And these are the contacts. PDO [at] ripe [dot] net is the address you have to use when you have doubts, feedback, rants or you want to send me policy proposal and you have doubt on what is the relevant Working Group you should contact on that, who are the Working Group Chairs you have to deal with. PDO underscore RIPE underscore RIPE NCC is the Twitter account I use to update on what happens in our region and in the other region. And basically done, so if there are questions?

GERT DORING: Thanks for bringing us up all to speed on what is going on right now. I see one question.

WILIFRIED WOEBER: I am just wondering regarding the Inter?RIR transfer policies. Are you aware of any efforts to make them mutually compatible or symmetric? Because I would expect that it's going to be a funny situation to be able to transfer address space out of region A into region B, but, for example, not being able to transfer addresses from B to A. I mean, it's just curiosity because it strikes me as slightly weird to attack that problem from a very narrow point of view within one region only. That also applies to the discussion about our Inter?RIR transfer proposal.

EMILIO MADAIO: Well, I just want to ?? this is basically policy discussion and I am happy to receive the input and facilitate that. We will go through some of these aspects, I presume, today, or in general, but ??

GERT DORING: That is what I wanted to say in response, that we will sort of touch this in the transfer policy discussion later today. So, we will not directly answer it but we will touch it and I think it's a good point that we should pick up again in the discussion.

EMILIO MADAIO: As a PDO I have to say, thank you for your feedback and keep on giving feedback in the sense that it's important that we share opinions and ideas in order to make the right decision on policy, especially in this case when the coordination ?? between RIR is more needed than before.

GERT DORING: OK. Thank you, again. And now we have another brief presentation from Alex le Heux.

(Applause)

GERT DORING: Alex is the one who does most if not all of the impact analysis, figuring out what exactly the policy text we propose would then mean and who then is tasked to actually implement it inside the NCC so he really knows the effects on what we do, and will actually not speak about weird things we have been doing but about questions that came up recently and could only be answered by looking at lots of policy documents. Thank you, Alex.

ALEX LE HEUX: Good morning. I work for RIPE NCC registration services. There were two action points from the last RIPE meeting. We were asked to look at the need for an inbound transfer policy and we were asked to analyse why LIRs would want multiple routable IPv6 blocks. Both of these action points have been overtake answer little bit about events on the address policy mailing lists but we will get there.

So the inbound ?? need for inbound transfer policy, the RIPE NCC has done kind of transfers in the past between RIRs. There has been the ERX projects and the early registration transfer projects which transferred legacy assignments and allocations from the IANA database into the RIPE Whois database. This concerned only legacy space and was more administrative matter than actual transfers of address blocks between two parties because the address blocks moved from one Whois database to another but they didn't change holder address space holder. There has been an outbound transfer when AfriNIC was created, which was also mostly in administrative matter of moving the address space from the RIPE NCC Whois database into the AfriNIC database.

The transfers that are ?? have been under discussion now are transfers from one LIR to another in different regions, and our view is that this is a fundamentally different type of transfer, so we do see the need for guidance by policy in how to handle these transfers.

But by now, there is a policy proposal being discussed on the mailing lists, so this has been overtaken by reality.

Then, we were asked to look at why LIRs want multiple routable IPv6 blocks. And there is four main reasons that we have been able to find. LIRs want sometimes non?routed infrastructure, to number their network infrastructure, their routers, their look back interfaces, that kind of thing. And some LIRs run multiple non?contiguous networks, we have some very large countries in our region and ISPs might operate in different parts of those countries and those parts are not connected so they will be making multiple BGP announcements. Some organisations have an eye open to future divestments of selling off parts of their company and even though they will be building one network at the moment, they are building that in such a way that they can easily sell off parts of it, so to number these parts of the network they would want to have blocks that they can then transfer as parts of that network.

And then there are national governments, who have a few unique requirements as well.

Now, for non?routed infrastructure, since IPv6 PI for LIRs, that is problem has been solved in most cases because the amount of address space needed for the non?routed infrastructure is often not very large, so a PI assignments tends to work for that and of course not announcing a block is a unique routing requirement so that works pretty well.

And for non?contiguous networks there is currently not really a solution. Some ISPs set up multiple LIRs but they often don't think this is an ideal solution. At the moment, 2011?04 the expansion of the IPv6 initial allocation policy is in last call and if in most if not all cases this can be a solution because a /29 contains quite a ?? it contains eight /32s, and we haven't found any of these networks that actually have more than eight parts.

For future divestments, 2011?04 may be a solution as well although that would require splitting up the /29, and would make it difficult or impossible for these parts to then later expand their v6 allocation into a reservation because there won't be a reservation behind that /32 they will be using.

But it is ?? it solves the problem partly.

Our national governments, wave fairly unique situation because we see that, slowly, national governments want to set up national IPv6 networks that have all the national ministries and organisations in it, all the states organisations, up to or down to municipalities and even very small parts throughout the country so these tend to be fairly large requests. But very often in the Constitution or other legal documents in these countries the states, provinces, sometimes even municipalities sometimes have quite a lot of independence and these parts, provinces or states, they would want to have routable blocks because they might want to route them separately in the future. Because of their independence they could set up their own LIR and request their own address space should they want to. In our experience, the national ?? on the national level, the governments are quite aware of the need for aggregation and things like that, so they would like to prevent this and they would like to have one prefix that they can announce.

Although in many cases because of legal issues, the central government cannot force these states or municipalities to follow this lead. Address policy doesn't take this into account at all so we treat these the same as any other LIR so there is a little bit of a disagreement between how we treat ?? how we treat these governments and these requests, and how they would like to set up their network in their own political situation.

Then we were asked to present statistics on what would happen after the multi?homing requirement was removed from IPv6 PI. The big arrow is when we implemented the proposal. There were a number of organisations waiting to ?? for the implementation to request the address space which is the little spike there but after that it seems to be business as usual. So no sudden explosion in the number of requests there.

Finally, I was asked to clarify our position on whether listing an allocation on the listing service, which would even in it's unused, would be a reason for deregistering and reclaiming that allocation. The answer to that is no, we don't think so, so; and the long answer is long. There is a number of relevant documents that have something to say about this. Some of them policy documents, some of them procedural documents. There is the listing service terms and conditions. There is the standard service agreement that every LIR has signed, there is of course the IPv4 address policy, and the closure and deregistration documents.

The terms and conditions for the listing service, they refer to the address policy, so that is a simple one. The standard service agreements refers to the RIPE NCC ?? the RIPE address policies and RIPE NCC procedural documents. Then, as we go to the address policy, there is Section 5.0, the guidelines for allocations, which mentions nothing about reclaiming empty allocations or unused allocations or anything like that. In the assignment section, there is a phrase which says that an assignment is only valid as long as the original criteria remain valid. However, assignments are not allocations.

Then, there is the closure and deregistration documents, RIPE NCC procedural document which has some very clear language about that applies to allocations as well. When the original criteria are no longer valid for the original purpose, the allocation becomes invalid and the RIPE NCC is authorised to deregister and reclaim the resources.

We now go back to the address policy. There is a section about transfers there. And that section allows an LIR to transfer an allocation to another LIR. It has one important requirement, though, that there are no assignments in this allocation, which, by definition, means that is unused.

So in summary, two documents that say something important about this, there is the closure document which seems to authorise the RIPE NCC to reclaim unused allocation but IPv4 address policy which permits the transfer provided the allocation is empty and listing an allocation on the listing service basically declares the intent to transfer.

So even though we may be authorised to deregister and reclaim the allocation, that would seem to go against the address policy so we don't see the fact that an allocation is listed at the listing service as reason to reclaim it at all.

And that brings me to the end. Are there any questions?

GERT DORING: OK. Thank you. That was quite important as a basis for the transfer discussion.

(Applause)

GERT DORING: And now it's me up here again for short recap on 2011?04 and 05. This was sort of a standard slide I always have there before we enter any discussions about policy proposals and this is actually I think one of the most important things to be said here is the discussions ?? whatever. I could see it all the time just fine. The discussions here in the room are important to clarify things to quickly get feedback, but in the end, the decisions are made on the mailing list, so you don't have to come to a RIPE meeting to influence policy; you just have to read and write to the address policy mailing list. Everything on the mailing list is out in the open, everything on the mailing list is archived, so if somebody comes up with doubts about self regulation and whatever in three years' time from now, we can very clearly document how we came to a decision and this, in particular, is why it's so important to have everything on the mailing list.

As I said, in here, this is very useful to get quick feedback in which direction something should evolve or whether the resistance is so high that it's no use to actually investing more time into a rough idea.

This session is webcast, so people are listening from home. That means that if you want to contribute; please speak into the microphone and speak your name and if you want to and if it's relevant your affiliation, but that is into the requirement but the name is important to attribute who said what. There is an RIC channel to type in feedback, which can be helpful at times.

So, discussion of open policy proposals. These two are the ones I am going to cover because they are basically in the last call phase and I don't expect a real discussion on them because all that has happened before on the last meeting and on the mailing list. So I am just summarising them and if there are questions, briefing answer them. The policy proposals are here, but I have not asked them to come up on stage because it's not really necessary, but they will answer questions.

So, 2011?04, the actual policy text is longer and is on the web, of course, but I have extracted the two most relevant bits from it. What it does, that it gives an LIR that asks for PA allocation the option to ask for more than a 32 by just asking for, so if you say I could use a 31, then you ask for it; you don't have to provide detail number plans on anything. It's really the way IPv6 is envisioned. There is lots of addresses and you get them by asking for them. The original background of the proposal was enabling of 6 RD transition technology but based on the feedback we got at the last meeting, all mentioning of specific technologies was kicked out, so this is really, if you need addresses, ask for it, get them.

As a ?? it means that if you have a 32 allocation, and feel sort of like tight in there for whatever reason, you can just come up to the NCC and say, I want a couple of extra bits, since they have reserved at least a /29 for everybody anyway, they will now give it to you as soon as this is implemented so this is in last call, which means that the Working Group Chairs thought that we have enough support to go ahead. The last call phase will end in 2nd of May and if nothing surprising comes up, then it will be implemented as policy.

So, any questions on that?

AUDIENCE SPEAKER: ARIN Hughes from 6 connect. Perhaps I just missed this on list connect discussion but why not round up to the NIB he will 28 ?? anybody he will 28 or is that ??

GERT DORING: I didn't get the question.

AUDIENCE SPEAKER: Why /29, why not rounding up to the nibble /28?

GERT DORING: That was based on the fact that for most of the early allocations, the NCC did only a /29 was reserved so if you want to treat all existing allocations the same as everybody can be rounded up to a 29, that is the maximum you can have. Because there is no 28 that people could go to. For new allocations, it wouldn't have made a big difference but it was sort of made to balance existing versus new stuff.

AUDIENCE SPEAKER: For retaining sparse at the RIR level?

GERT DORING: The RIPE NCC has changed the allocation model over time. Initially, allocations were done with a reservation of a 29, and then the next RIR, next LIR block came. Nowadays, sparse allocation is use sod nowadays we could round up to whatever you need, but for the older ones that would ?? well, the proposer consisted ?? considered that this would be unfair and so decided to have a 29 in there.

AUDIENCE SPEAKER: I understand. Thank you.

GERT DORING: So it's really in a way arbitrary. For an DNS reverse delegation 28 would have been more convenient, indeed. So, I see nobody else coming to the microphone, then I jump to 2011?05. There is a lot more policy text to it with clauses and restrictions and so on but these are the important bits. It basically says that when the last /8 has been reached and exchange points need address space for their peering network, and specifically only for the peering network, not for services, anything else, office buildings, just for the peering at work, they can still get address space from a set aside pool. There is very specific restrictions who can get the space and what it it:it be used for. If you grow your space you have to return the old space and, the group agreed that this is a good thing to have and so it's in last call, as well.

It initially came from Andy Davidson, who is Working Group Chair of the EIX Working Group, was discussed there as maybe we should do something about it and then Andy brought it over, so there has been fairly strong support from the EIX Working Group on that. And unless something surprising happens last call ends at May 9, and then it will become policy. So any questions on that? Good. Because that gives us lots of time to do the transfer policy discussions. And that is what we have now. We have one policy proposal that is currently active in the system and has a number and formal status and so on, brought up by Sandra Brown who will be up with me in a minute, and that got lots of feedback from the mailing list about half of it positive and half of it negative, so it's a bit unclear whether that ?? pursuing that one is a good way forward, so we had two new proposals come up that are not formally in the system yet because, well, it takes a while to do the formal bits for Emilio ?? but there might be a more interesting way to tackle the issues and so the proposers agreed to bring them up as well even if they are not a formal proposal yet and get feedback on all three and then decide how to go on. So Sandra first and then Remco.

SANDRA BROWN: Good morning. Yesterday, I spoke to the relative abundance of IPv4 in North America where there is five IPs per person, roughly, and the fact that there is much less in Europe, about .8 per person, and, you know, you can find of use that as a rough estimate of ARIN versus RIPE region. So that is kind of an example statement of why we need Inter?RIR transfers.

So the main purpose is to allow transfers to and from other RIRs, to supplement the pool of IPv4 and to provide access to the addresses in other regions and, the most important thing I think is to keep the registry up?to?date, I think that is important for all of us.

So, the main body of the proposal, the first statement here, for the NCC to recognise transfers when the counterpart RIR has a policy in place, and then the bottom statement is just a point to the conditions that follow.

So three conditions on space, and these I authored looking at what the other regions had in terms of RIR policies, so I chose a /24 because other regions had//24s in their policies, that you had to be an authentic holder of the space; in other words, you couldn't be somebody who didn't really own or ?? own the registration to the space, that the source was defined by the RIR where the block was held and the recipient defined by the RIR where the block was held, and then lastly, when in the RIPE NCC, a few points; number one, that you get an affidavit from the signing officer, that it wouldn't be retransferred within 15 months and I got some feedback on the 15 months, why 15 months, why not less or more so the 15 months was a bit controversial; that the transfer block had to be used for operational purposes. The point being there that it couldn't be a speculative transfer like you couldn't transfer it with a purpose of retransferring it for profit in the future, trying to avoid speculators. And then to conform with the any spam directive in the European Union.

So the feedback I received this is the most important point that we have the two follow?up proposals that are on the table this morning, that there is a lot of interest within the RIPE NCC to simplify the policies and the documentation that is followed. So, the notion that transfers should follow inter ?? Inter?RIR transfers should follow the same rules as intra RIR transfers, and I heard that loud and clear, and so I think that is a main theme of what we are going to talk to between Remco and me and ?? and I today. So if, these other three points are of lesser importance, but I did want to bring them up because they were made in the feedback. Preference to use the word "transfer" instead of "sale." On this one I want to make the point that in many cases it is a sale, and I know that people don't like to hear that in many cases but money is often exchanged except in those cases where it's a transfer from related ?? or between related companies.

The next point is why limit the retransfer period to 15 months, and that, the intent there is to try to limit the speculative transfers, so, in other words, try to prevent people from flipping IPs for for profit, so 15 months seemed like a reasonable period to do that and why a minimum transfer block and someone suggested why shouldn't it be a /21 similar to the intra RIR transfers, and I think Remco and till tackle that issue in the follow?up proposal.

So the path forward, you know, I have gotten a lot of feedback and what I'd like to do is withdraw the initial proposal and try to simplify it, Remco and I have been talking off?line with a new Inter?RIR transfer proposal and Remco is going to present it, and what we want to do is simplify the proposal so that it's much more in line with intra RIR transfers, with the intent of making the RIPE transfers much more aligned with each other and what this will do is, it introduces a couple of new problems, and then to tackle the problems, we will also introduce a second additional, we call it a time?line amendment, so right now, transfers are limited to only a three month usage allocation, so we will introduce a second new proposal 03 to remove the limitation on the period of use for a transfer, because three months isn't really practical in a transfer situation; you know, if you are transferring from an entity for ?? from another country, then you want a longer period so we will take he will those two things. And then implicit in all of this and not to be lost in the shuffle, is the idea that needs justification is therefore still on the table, so within the RIPE service region you have needs justification and they also have needs justification in the regions of RIPE and APNIC and therefore you are aligned with those two regions and it should be a no brainer when it comes to the justification conversation across all the regions.

So, we think this is a good path forward and I can take questions.

GERT DORING: Is it on? Thanks for coming up and presenting this. I would suggest having only clarification questions now and having the discussion after the other two have been presented. Because then the ?? then we can sort of look at the whole package at the time. That was into the clarification, so then it's Remco.

(Applause)

REMCO VAN MOOK: So good morning everyone. Here I find myself on stage against talking about transfer policy something I promised myself I'd every ever, ever, ever do again in my life but here I am. And here are my slides, amazing, fantastic. I am going to talk about Inter?RIR transfers, soon to be called 2012?O2 provided Emilio doesn't get anything else in between.

It's a joint proposal by James Blessing, Sandra and me. It aims to put Inter?RIR transfers in place in the most minimumal way possible in terms of the policy text. So what we do, simple inter RIRs transfers with as little new rules as we can get away with.

In order so to have as little rules as possible we have a lot of definitions. And this is just to make the policy text a little bit easier to read. I think you will find the definitions mostly self?explanatory, since we have a bunch of entities and policies, I am just clarifying what they are and how they relate to each other.

So, with that said, the Inter?RIR transfer policy for transferring to the NCC service region means that the transfer is in line with the policy at the originating RIR. The destination LIR, so the LIR within the NCC service region, is qualified to receive the address space according to our intra RIR transfer policy as we already have. And the region that the ?? that the address space is coming from has to have an Inter?RIR transfer policy in place.

You can pretty much guess what the other one looks like, transferring from the NCC service region means that the transfer is in line with the policy at the destination region, the originating LIR and v4 address space are in compliance with the rules that we have in this region and again, the other region must have an Inter?RIR transfer policy in place and that is it.

GERT DORING: OK.

REMCO VAN MOOK: I see Geoff.

GEOFF HUSTON: This is a clarification question so could you go back two slides. It's to the RIR service region and what you are saying is that coming into the NCC, you have to meet the NCC's policies as the receiver, yes?

REMCO VAN MOOK: Yes

GEOFF HUSTON: But you are not saying anything about the holder of the addresses that is disposing of them and the policies of that region with respect to it.

REMCO VAN MOOK: That is rule number one.

GEOFF HUSTON: That is a strange piece of wording, Remco, I am sorry, because it's not ?? no honestly, it's not the transfer; you are actually talking about the disposer, the transferee, because it's not the transfer that is in line with the originating policy so hence my question comes from confusion there, I am sorry but that is not very clear wording to ?? if you wanted to say that the disposer has to meet the policy framework of the region in which those addresses are registered, it would be clear tore say that as you have done in part 2 about the receiver.

REMCO VAN MOOK: OK.

GEOFF HUSTON: I am neither for nor against this of course.

REMCO VAN MOOK: Of course you aren't. But thanks for that Geoff, I will look at the text again. Paul.

AUDIENCE SPEAKER: Paul from APNIC. This policy is very much the same and in most respects I think better structured and presented than the one that we have at APNIC so I think they are sort of perfect counterparts in that they do interact in the way that they are intended to I think, from the APNIC point of view. I hope this also answers Wilifred's earlier concern about exactly how an intra RIR transfer would work vis?a?vis the receiving and originating policies because in effect we have got ?? we do have a very good example here of coordinated policies rather than identical global policies, which I think Wilifred may have been alluding to there. Thanks.

REMCO VAN MOOK: I see Wilifred nodding. Randy. Thawed thawed one of the things that has been raised in various RIRs that have been discussing this is having specified a need based and I would like to see that added. I love simplification but ARIN was big on having needs based, one of the criteria.

REMCO VAN MOOK: Sure. The needs based is in the transfer policy that we have for within the region that I referred to, so the needs based is in there.

AUDIENCE SPEAKER: If you don't specify it, if it's changed, needs based goes away.

REMCO VAN MOOK: Yeah, but at the same time I don't want to set ?? I want this to be as minimal as possible and if we get rid of needs based in ?? within the region, there is no point in keeping it outside the region, I want those to be in sync as much as possible and at the same time, I can't really see this region every abandoning knees based but there you go.

AUDIENCE SPEAKER: It's just something for ARIN, most likely.

REMCO VAN MOOK: I am more than happy to explain all of this to ARIN and why this fits needs based.

/STEF stiff: I see your concern but actually ?? those constraints in this text would mean if we changed the local policy intra RIR transfer would have different policies than inter and I think that would create an even bigger mess. If this policy is accepted we know that the transfer policy applies to both inter and intra RIR transfers so the needs based stuff will be taken into account whenever that might change.

AUDIENCE SPEAKER: It's not the problem passing this policy but of ARIN accepting this policy and passing their own transfer policy. And if they don't see needs based in there they may not move forward.

REMCO VAN MOOK: I am sure we can adequately explain it to our friends in ARIN.

AUDIENCE SPEAKER: I have to respectfully disagree. That was the main point in the first place, not seeing it in the policy. Anyway, that is my comment.

REMCO VAN MOOK: Thank you for your comment.

Paul Wilson: APNIC again, to clarify from APNIC's perspective, the situation is the same; our intra RIR transfer policies now relies on a needs based assessment before a transfer can be approved. That is for everyone's information, because of course, earlier, we didn't have the needs basis in there; we added the needs basis to the intra RIR transfer policy specifically so that we had I think on ?? from the community's perspective, a compatibility with other RIRs expectations but we do see that the needs based intra RIR transfer policy is exactly reflected by and required to be implemented by Inter?RIR transfer policies and as for ARIN in particular the ARIN requirements that have been discussed in their candidate Inter?RIR transfer policies only require that the recipient RIR has a compatible needs based address management system, if I recall correctly. And I am quite sure that APNIC, with our intra RIR transfer policy, satisfies that requirement; it was one of the particular issues of discussion when that policy was changed a little while ago. Thanks.

REMCO VAN MOOK: Thanks, Paul. Anyone else? Anyone from ARIN would like to comment on this, since we have mostly been talking about ARIN here? No. In that case, I guess I will go to the next one.

GERT DORING: I would say go to the last one and then we will have to ask the audience whether the roads presented is what we want to go forward on.

REMCO VAN MOOK: This is a very short one, about unintended side effects. And this is a amending the intra RIR transfer policy, which is something I really promised myself I'd never, ever touch again, but here we are.

So, the current transfer policy has this nice little paragraph which says, well, here is the needs based allocation, etc., etc.. there is only one minor issue here that we basically to keep this piece of text as simple as possible we simply referred to additional allocations for the rules set out for needs based evaluation. And then we accepted run out fairly, which changed the rules for additional allocations, which actually means that like additional allocations you can only qualify for block of address space worth of three months of demand and that has broken the current transfer policy. And there is a really quick fix to this, and that is to get the term stated specifically in the text for the transfer policy, which says so we keep the reference to all the other rules for additional allocations but saying ear than for additional allocation, for the purpose of determining need for transferred allocation, a period of 24 months is used in the evaluation." Like we used to have back when we were talking about transfers back in 2007, 2008, and that is it again. I like simple and short. So I am just going to go back to this slide because this is basically the only content I have.

NIALL O'REILLY: Can I play that last sentence back to see whether I have understood it correctly, and I don't know whether this is my slow brain this morning but what I think you are saying is for a transfer ?? let me start from a different point. Run out fairly will only apply to new ?? to additional allocations?

REMCO VAN MOOK: That's right.

NIALL O'REILLY: That seems to make sense to me at least, as one of the authors, Co. authors of run out fairly and transfers will be treated according to the classic model.

REMCO VAN MOOK: Exactly.

NIALL O'REILLY: Works for me.

REMCO VAN MOOK: OK, thank you.

GERT DORING: Any other comments on this particular one? Andy.

AUDIENCE SPEAKER: Plus one to Niall, that sounds very normal and sensible.

REMCO VAN MOOK: Anyone else wants to plus one this, or like? No. I am so disappointed. Well, Mr. Chairman...

GERT DORING: Yes, I am a bit wondering what to do next because I expected queues on the microphones and bricks and tomatoes and flowers. So I could make a bold statement of assumption like if you don't protest, it has to be fine. That is not particularly well regarding consensus process but might help raise some comments.

AUDIENCE SPEAKER: You would like a brick. I don't like that text. I don't like that we are promoting the trade of IP addresses by saying you can get IP addresses if you can buy them somewhere and then you have the 24 months and the calm and the way things work, when, at the same time, if you try to use the usual system and don't want to pay for your IP aaddresses, then you still have the stress of only being allowed to get for three months. So, if we should do this for transfers, I think we should put in a claim that it is something that can take place after we are run out completely, and not as long as we still have the choice of an additional allocation. I really do not like that buying addresss are set somebody better than using the usual system, as long as that is is in place.

REMCO VAN MOOK: I completely hear your sentiment there, absolutely.

AUDIENCE SPEAKER: I am Nenagh from TDC.

SANDER STEFFANN: By the time the policy is accepted, the difference won't be that much.

REMCO VAN MOOK: We might be talking about a period of weeks.

REMCO VAN MOOK: If I am lazy in filing this proposal, the problem will go away. I see Daniel.

DANIEL KARRENBERG: Speaking for myself. Just being completely Ger man anal; run out cleat defined it, does that include the last /8 or not? I don't think the intention is it includes the last /8 but if we add words to this that should be clear.

REMCO VAN MOOK: Thanks for that, Daniel, that is very helpful.

GERT DORING: I think indeed that the current text pointing to the additional allocation policy which stops to exist as soon as we hit the last /8 means that our transfer policy isn't go to work there.

REMCO VAN MOOK: The text is not going to go away. It's just not applicable any more for additional allocations and that is the problem with keeping all the rules in place but at the same time it's very convenient.

AUDIENCE SPEAKER: Nigel Titley, speaking for myself. I think at the moment we are in the process of rearranging the deck chairs on the Titanic and furthermore, we are rearranging them for the benefit of the deck chair attendant, which is to charge us for them. Thank you.

AUDIENCE SPEAKER: A comment from Elliott in chat, he says one concern I have is that the LIRs offering service to small businesses start selling their IPv4 block and, at the same time, price out ranked on the mic row blocks they charge that would place IPv6 transition on the backs of small businesses.

REMCO VAN MOOK: I don't particularly see right off how this would ?? how this would specifically help or block that kind of movement. If you have a better business in selling your address space than selling services then you probably should reconsider your business model and that applies regardless of whether this policy is in place or not.

AUDIENCE SPEAKER: My name is... I come from from LACNIC, and I am standing here as I have two comments, one is at the request of Emilio, I wanted to comment that the status of Inter?RIR transfers in LACNIC actually in our last policy forum last October there was a panel discussion, the possibility of needing an Inter?RIR transfer for the LACNIC region and the general opinion of the room was that such a policy will be needed but no proposal has been put forward so far. So, we will see what happens in the next policy forum, but it's too late for the next one, maybe for the October one, we don't know.

My second comment regarding the text comes from problem ?? misunderstanding on my part; the previous proposal mentioned that, it refers to this policy for the justification of needs based, right, but then this text starts saying something that other space may only be allocated to another LIR that is also a member of the RIPE NCC, which in my understanding of the text creates a weird dependency because one text refers to the other but this one explicitly excludes the possibility of an incoming transfer.

REMCO VAN MOOK: Thank you. For your first comment, you are more than welcome to steal the text that we are compiling here for the proposal in the LACNIC region. And for your second, yes, well that is ?? because the transfer policy we had in place was an intra RIR policy and we are now rejigging our policy structure to make Inter?RIR transfers possibly without actually having to revisit the entire transfer policy itself, which is probably something that is got to be without end and quite clearly something I am not going to pick up

NICK HILLIARD: INIX. Referring to the comment that Nigel made, I think in the short?term, this isn't about facilitating deck chairs and the Titanic but life jackets and life boat seats in the Titanic because we are not at the stage where we can run feasible IPv6 only services. In general I think I like your proposal here. As a sort of a ?? from a philosophical standpoint, what we are trying to do here is facilitate a functional market and from this point of view, the issue that we are trying to deal with is a purely economic issue, which makes technical people like me peculiarly unqualified to make sensible comments on it, so in terms of creating a policy which is very loose and which is, you know, has very ?? creates very few market constraints I think your policy does very well from that point of view but I worry about the future possibility of abuse such as price fixing in particular and IX ?? at least IPv4 address hoarding by institutions so that they can essentially control the market and engage in price fixing issues like that.

REMCO VAN MOOK: OK. Just to be perfectly clear, the text here is not the full current transfer policy, I picked out the relevant parts that we are hitting limits of right now and I think you will find that the entire transfer policy has some limits in place right one.

SANDER STEFFANN: Clarification, is this a concern about existing transfer policy or about getting the period back from three months to 24 months like it was before the run out fairly?

NICK HILLIARD: No, it's a general comment about creating an economic Eco?system in which the likelihood of market abuse is reduced. It's nothing in particular to do with this policy or the policy that was suggested yesterday; it's just a general concern that I have about the fact that here we are as mostly technical people, attempting to define the terms of a pure economic market.

SANDER STEFFANN: Thanks.

REMCO VAN MOOK: We are still in time for coffee, I am amazed.

GERT DORING: To wrap up, could I get back the presentation from Sandra, please. Exactly, that was the slide I wanted to bring back. As people have expressed a dislike for 2012?01 and we have simpler proposals on the table that should achieve the same thing as in make sure that transferred address blocks are properly documented, that we have as simple as possible transfer policy if needed. This is the path forward proposed and I actually want feedback from you now on whether this is fine with you or completely unacceptable, and we do it with a round of nodding and shaking heads. So if that is what you think we should do, please nod; if you don't like it, shake your head and if you are reading e?mail, just ignore me. OK, I would like to see at least three heads move. You are really not awake this morning I hope for a bit more of active participation.

So I would like to leave it to the proposers to sort this out, whether you want to go forward with your plan. I think from the Chair's perspective, I don't see anything wrong with following this path. I have not seen many shaking heads. I have seen lessen /TKORSment than I would have liked, but anyway, it seems it's time for coffee. So can I get my slides back now.

So we are not doing that one but we are doing that one now. So, we do a coffee break and give you time to recover from yesterday night. Tomorrow morning, 9 o'clock is the next slot of address policy where we will have, I hope, more lively discussions about new ideas. Thanks for being here, thanks for your feedback. Enjoy your coffee.

(Applause)