ap-wg

Note: Please be advised that this an edited version of the real-time captioning that was used during the RIPE 56 Meeting. In some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but it should not be treated as an authoritative record.

Address Policy Working Group Session 1 11:30am, Wednesday, 7 May 2008

CHAIR: Thank you. Welcome back everybody from the coffee break. We are a little bit late and we have lots of things to do, so those standing out the doors, yes, please close the door. This is the Address Policy Working Group and well, we are going to do address policy discussions. First of all, let me welcome all of you and then let's enter discussion of the agenda.

I have sent proposed agenda to the mailing list and haven't received any comments, so I assume that this is not the worst of it. If you want any changes to the agenda, please feel free to jump up and down at the microphone and comment on it. The first thing is, well, the usual stuff: Thanking the scribe, that is Alex from the RIPE NCC, thank you very much. Approving the minutes and agenda bashing - I have not received any comments to the minutes circulated to the mailing list, either, so unless somebody speaks up now and says "I have been completely misrepresented or I remember things very much differently, I will declare the minutes final. OK. Nobody is jumping up and down. So the minutes from last time are now final. Agenda bashing. We have two working group slots, one 90-minute slot today and same tomorrow. Today is a little bit shortened due to the IPv6 stuff. The first thing today is a very short overview of the proposals that have been concluded since last meeting, either withdrawn or implemented. Then, we have a couple of new proposals that 2008-01, -02 and -03. I plan to have the proposer of 2008-01 and 2008-02 up here on [unclear] so we can have a lively discussion because I know that these proposals are not so well taken, so we really need discussion here. And the other new proposals 2008-03, which will be just mentioned today and discussed tomorrow.

The largest part of today's working group will be the contracts and certification thing, which is the 2007-01 proposal concerning direct end user contracts regarding PI space, AS numbers and things, presentation of the current status and determination of the next steps. And then, we have some input from the Certification Authority Task Force, they plan to propose some method for initial certification that will become formal policy proposal after this.

Tomorrow, I plan to restart the PI discussions that have been pending, waiting for the completion of 2007-01. That is IPv6 PI, two different proposals actually and the IPv4 PI minimum assignment size proposal which has also been on hold. And then, the end of IPv4 proposals, which is the proposals how to handle the remaining IPv4 address space and the transfer policy proposal. And then AOB open mike of course. Do you have anything that you want to see on the agenda? Are there compelling reasons to shuffle something around? I see someone standing there but he does not he is not looking into my direction so he is left over from the last session.

OK. Then, let's start with today's session. As a short introduction my name is Gert Doering, I am the working group chair. We have we have a co-chair Sander Steffann. If you have any issues with address policy, anything that is bothering you, feel free to speak to either of us if you don't feel like speaking up in a room full of people, just grab us in the coffee breaks and we will try to do our best to sort out anything.

Jumping to the concluded policy proposals, we had actually three sort of it's three times the same thing in a little bit different packaging proposals. All these three proposals have been concerned about how to handle the IPv4 address space when it runs out. It's the thing about give the last /8s in an equal fashion to all the registries, either give everybody five or one /8. There has been lots of discussion about this and there was no consensus so the proposers decided to withdraw all these three and come up with a new proposal, which is basically the same with different numbers, and that will be 2008-03. So, nothing spectacular here.

Then, we have two proposals that actually got accepted and partly implemented; one is the very old one about the IPv6 assignments to end users that changed to HD ratio, and changed the size of the end user assignment, giving the local registry more freedom and determining the /56 as a unit to determine, yeah, well, fullness of an allocation. That has been accepted and implemented. And then there is 2007-04 which is the global policy for allocation of AS number blocks to the regional registries. It's a global policy because it needs to be the same in all regions. It has been accepted in all regions and now it's somewhere up above our level and I have ambushed Wilfred to give a short report on what is happening in the ICANN ASO. Wilfred: Wearing my address council hat for a moment. As you may know, there is the provision that within the address council we have to document and sort of to rubber stamp the fact that the policy development procedures have been followed in all the various regions, in order to agree on a global policy to be submitted to ICANN and IANA and this report has actually been constructed and submitted at the end of April, I think it was, 28th of April. This was done under the leadership of our colleague from Venezuela, Fernando and right now it is in the editorial queue with the NRO because we have to make sure that the wording that is used in that particular note to ICANN is compatible with the memorandum of understanding. So I think a couple of guys are doing a little bit of words missing, which should be done in one or two, three days. So it's on its way. Content-wise it's done. It's just a matter of editorial brush and then a matter of task for the chair of the address council to formally submit this piece of electronic paper to ICANN.

SPEAKER: So if I understand this right, this is a matter of some weeks?

WILFRIED WOEBER: At most, I guess a matter of days.

SPEAKER: OK. So basically since everybody agrees that this is a useful thing anyway, not much resistance has been accepted so it's on its way and will be in place soon. Formally documenting things that have been done that way, anyway. It's just a formal thing. If you are interested in any of these concluded policy proposals, there is the URL where all the documents are archived forever, well as long as RIPE exists, so you can read up what the exact policy text was and what happened to it.

Next block: New proposals since the last RIPE meeting. We have three new proposals. As I said the third one is going to be discussed tomorrow, and two proposals are touching IPv6 assignments or allocations to people. The proposer of these policies is only available today so I asked him to come up today and, well, sort of defend his proposals, discuss with the community and come to a conclusion on whether this is something we think that should be pursued further or just abandoned, because there has been quite some resistance on the mailing list. Lutz, please come up. There he is.

LUTZ DONNERHACKE: Hi. I think you believe I am crazy but it's only a problem of listening to customers. If you are asking why do IPv6 get not deployed, you hear an argument very often, the argument is if we change IP addresses, if we change our infrastructure, it will be the last time. So if we change to IPv6, we will take this and will never will never give them back. It's a common argument. It's an argument for changing providers, a lot of end customers like to change the providers every month to get the next cheaper one. Renumbering is an expensive job and a long time job, even with IPv6. So if you want to get IPv6 deployed and we are listening to this argument, we have to hand out provider independent space. It's the main point. So, the proposal is to go in advance, to start from the RIPE community and to proactively hand out IP space, provider independent IP space to everybody currently using the Internet. It's a very extreme position. We can do it because we have for these people, we have the database at RIPE and it's database entries are correct by correct, the LIRs are acquired by contract to keep this correct so we do not have any problem with it. Sorry, if you are lazy. And we have a lot of suggestions from the working group, the first is to be a little bit flexible. No sides fit all so it should be possible to hand out more or less space from 48 to 64 are proposed, and another proposal which is a little bit time consuming but might be useful, is to not assign the PI space but to ask the admin people of the if they like to get PI space, get in contact with them, or maybe design the right prefix length and then assign after a request from them or acknowledge from them.

If this proposal will fail we have two outcomes in the press: The first outcome is RIPE community refuses to deploy IPv6. The second outcome, internal outcome, PI space is not necessary for deployment, only one of the set lines will go to the newspapers. It's our decision which one we get. I purposely choose another t-shirt today; we have Tamagotchy, it's IPv6, and we are going to shut it. So discussion on this proposal.

No arguments against, so it's accepted.

CHAIR: It's working now. I see at least one person queuing up and I think that there must be more persons awake in this room and have opinion on this.

MICHAEL DILLON: First of all I am concerned that this could damage the routing table by encouraging large number of PI entries that might not otherwise be there, because these organisations might be satisfied with PI allocations in their implementation of v6, so this is I think the wrong direction to go. And secondly, I do not believe that anybody should get any addresses any time unless they agree they actively agree to accept them, so I don't believe that we should make database entries without some kind of acknowledgment communication between the RIPE and the recipient of the addresses. Now, when you apply for a block of addresses, we can assume that the agreement is there because otherwise you wouldn't have sent in your application, but because RIPE is initiating this, there needs to be a mechanism to be sure that the I N num holders understand what is being done and they agree to it that they [unclear] yes, they want this address block and they will use it.

LUTZ DONNERHACKE: Thank you. It's address from the working group. Sending out an email to the admin holders and asks them if they want to take the PI space we offer them. And agree on the size.

NICK HILLIARD: I am completely unclear as to what problem you are trying to solve here. The proposal the current mechanism for LIR allocations is that you sent an email to Hostmaster at ripe.net and you say "please can I have an LIR IPv6 allocation" and then they say yes here you can as long as you have got an address plan that is fine. So from that point of view 2008-02 is entirely pointless. You ask for something you get it and you are

LUTZ DONNERHACKE: And they want to change and you go to another LIR and you have to change your address and you do not want to do this.

CHAIR: Things are going a little bit across right now. Right now, Lutz has only presented 2008-01 so�

NICK HILLIARD: I am sorry

CHAIR: Your argument is taken for 2008-02.

LUTZ DONNERHACKE: Different point. I will make it clear later.

AUDIENCE: For 2008-01 I would like to reiterate probably for the first time ever and probably the last time that I am ever actually going to agree with Michael Dillon on anything. He has a point to make this time, there is no contract, there is no indication that end users actually want PI space. In addition, 2008-01 is going to conflict very seriously with 2007-01 which implements a payment system for end user provider independent to IP address space and I would respectfully suggest that if you are going to hand out IP addresses to end users and then demand payment, that that puts RIPE in a very difficult position indeed.

LUTZ DONNERHACKE: RIPE will, if we conclude on a payment and then offer PI space to a lot of people, it will be considered a spam, yeah, legally.

BILL MANNING: Bill Manning. So, on the idea of money, Trudy, yesterday, and Randy today and other people have talked about IP address ownership as in IP address blocks become property. What I see here in this proposal is RIPE handing property to people and those properties become taxable and, quite frankly, I may not want the tax liability of RIPE handing me a chunk of property that I don't really want.

LUTZ DONNERHACKE: I follow this discussion, yes, I know.

BILL MANNING: So I am not on the assumption that property a property value accrues, I think that the taxable the taxable nature of this property and forcing it on people, is something that RIPE probably doesn't want to do.

LUTZ DONNERHACKE: Yes. But we have this problem today. We have space and out in the same way. We have PI outer space for v4, which can considered as property. We have the same PA space which can be considered adds property, maybe as loan property.

AUDIENCE: More or less agree with the previous speakers that it might harm routing, it might harm business models but did you consider that automatically assigning PI to every holder is probably crucial but a lot of work, Geoff is doing, Daniel is doing on actually measuring the IPv6 deployment because we currently see a large discrepancy between assigned or allocated v6 and stuff actually boot up in the routing table. If we should books to everybody without people asking for it we probably end up with 0 to 1 percent of the IPv6 space actually being routed and visible on the Internet. That might change some graphs dramatically

LUTZ DONNERHACKE: There was already the suggestion from the working group to ask first. And I think that is a good idea.

AUDIENCE: Raymond of Finland: I don't know, I came in a few minutes late, sorry for that. Is this 2008-01 assigning IPv6 to PI to every INET NUM shouldn't be there another PI in between there. Wouldn't it be sensible to change in this way: That you give out IPv6 PI to the ones who own IPv4 PI?

LUTZ DONNERHACKE: No.

AUDIENCE: No.

LUTZ DONNERHACKE: No. I do not I personally do not like IP space at all. I brought customers to give up PI space for PA space, it's very hard work but possible, and I personally do not like PI space and I do not definitely want to give advantage to current v4 PI space holders. I think the currently should not get extra gain from it

AUDIENCE: Maybe to get the old PA or PI or v4 back.

LUTZ DONNERHACKE: I do not look or suggest to ask everyone taking part in the Internet if they want to get v6 PI space.

AUDIENCE: Peter: DNIC was a registry of last resort back then and I am currently the acting chief historian of this company, which means I have been guiding Internet colleagues through I in the database since 90 or 80s. I appreciate your optimism regarding the quality of data in the RIPE database, for these allocations or assignments in that case but I don't share it. Which means, there is a lot of cruft in there and you are correctly mentioning that going through all this contractual obligations, that are subject to another policy proposal, there might be a lot of dirty work to do, but this is one issue from the practical perspective why I think this 2008-01 is useless. The second one is you actually proposing to imply 1989 eligibility criteria for PI space to 2008, 9, 10, 11, whatever eligibility criteria for IPv6 PI space and I don't think that is wise. Not even knowing how the PI space and criteria would look like, much of this address space isn't routed today and hasn't been routed for the last, like, 15 or 18 years. So, these people would probably not qualify for PI, anyway. And we shouldn't make mistakes again that we have probably made like 15, 18 years ago. 18 years is probably actually a good span of time to grow up, so let's just get away with it and go ahead on the agenda.

LUTZ DONNERHACKE: Thanks.

CHAIR: Two more comments and then we need to move on to 2008-02, then I think everybody has been said.

WILFRIED WOEBER: Without any formal hat other than another historian hat, trying to do a little bit of last resort stuff in 93 for IP address in Albania if anyone remembers, there was one hostmaster back then doing that in the good old days. Anyway, but that is just background. I don't have dish haven't made up my mind yet to the sort of the body, the core of your suggestion whether I would like it or whether I would not like it but I am having a problem with the argument in favour of it like when you start today point fingers at headlines in the press. And I don't think that that is personal opinion, I don't think that policy development process in this environment should be influenced at all or at least not to a reasonably big degree by anything that is put in black on white paper in the press. We know about or many of us probably know about the quality of those headlines, where they are coming from, and I don't see a direct relationship between that type of publicity and the real life in the Internet over there.

LUTZ DONNERHACKE: I don't think there will be any headline.

WILFRIED WOEBER: OK. I just wanted to voice my opinion. I think this line of argument was not appropriate.

CHAIR: Thanks.

AUDIENCE: This might be along more in the routing working group, I think it's relevant here as well as one effects the other. You are aware that, well, presumably, that many ADSL providers will enter in /28, /29, /30 used by their customers and you will be giving out PI space to every single one of those. Have you considered the impact of two and a half million possible additional routes in the routing table and the amount of churn that you will get from when somebody reboots their homemade globally propagated update in the BGP tables there or perhaps if a major ADSL provider goes [unclear] blip and you suddenly get a couple of million routes being withdrawn and announced a few minutes later in the global routing tables, the operational impact sounds quite bad. The BGP sessions of bringing up a new session, a transit session wean router comes up and having to learn two and a half million routes is going to take a long time and population on the line cards takes even longer. This does sound like an operational nightmare. Currently with a few 100,000 prefixes, we are seeing address space hijacking every so often and it's not too difficult to keep an eye on things because there are so few prefixes out there. When you start adding two and a half million there and actually trying to shall make sure people's contact info is up-to-date making sure people announcing it are authorised and so on it's looking like a very administrative nightmare as well.

LUTZ DONNERHACKE: Routing tables are interesting problem. I don't think that that much routes will appear, but I am very surprised from the audience, nobody is claiming against argument that PI space is necessary when

CHAIR: OK. We need to well, first of all, we don't make decisions on RIPE meetings, so this is to get comments from the audience and we will take this comments into account and, well, there is definitely no overwhelming consensus to go forward with the proposal, so we, well, we will discuss it afterwards and then decide how to proceed or what to do with it.

Let's go to 2008-02. Less do a little bit more quicker because we will take too much time away from

LUTZ DONNERHACKE: OK. Second proposal comes from similar observation. There are technical people out there and ISPs, they are playing with IPv6 and they have still problems with their management. The management and the people still believe in the 200 customer rule, they didn't update their policy knowledge. They see billing issues, they see legal issues and so the management will refuse to take part or to get an assignment. This proposal is to actively remind them to get such assignment. I would like to as suggested in the mailing list to not assign them plainly, just send an email that is available and they can get it and if they say yeah they will, they will get the assignment. So it's the shortcut and pressure from the other side.

CHAIR: OK. We have heard the comment from Nick already that, well, putting things on people that are not asking for them but might get a bill for them later on, is maybe not really good way to tackle it.

AUDIENCE: Change the current existing things that if I want v6 I can usually mail hostmaster I get it so shouldn't we just abandon this and put it into the NCC services working group and request the RIPE NCC to send everybody a big flier and send the email explaining that the 200 customer rule is gone and you can actually, well, might take ten minutes for hostmaster to reply and get your allocation. Technically changing the well not change the policy so much and so should this be an address policy or is this NCC services thing.

CHAIR: This sounds like an interesting plan to be more proactive about it without actually changing the policy.

LUTZ DONNERHACKE: It's no change. It's a one-time operation.

AUDIENCE: Not technically changing the policy you are basically saying everybody should get an email, if you want your addresses you can get them here. Current policy states if you are an LIR and you want your addresses you more or less can get them by sending an email to hostmaster.

CHAIR: I see Leo coming up to the microphone.

LEO VEGODA: I sent from ICANN. I sent a mail to the list and I sent two mails; one said what about the billing implications of this and then I got an off-list mail from some other RIPE NCC saying you didn't pay full attention to the review we did and in the review we said that if everyone gets an IPv6 allocation, then the everyone everyone's count goes up, so there is no impact on billing. Because it's all proportional. But my understanding of the revision that has been proposed is that the RIPE NCC invite people to request an allocation and those that take up the offer get the allocation, which changes the billing implication, which obviously people would be buying into this, but that means we it's sort of like going out and actively selling address space and going and saying to people, hey, we have got this thing that you might want to buy from us and can you buy it, please. And is that the way we want to run this system, to actually try and make sales?

CHAIR: Good argument, actually. We are a little bit caught between sort of having to promote v6 and not being supposed to sell addresses, so this is a tough one.

AUDIENCE: So these two proposals and proposals they had in the past was to give address space to every single AS number and so on. Call me naive but I thought people wanted address space v4 and v6 because they had a need to communicate with other people and they needed the addresses. Giving the presentation we heard yesterday and today there seems to be very slow uptake and we know there might be some economics and why people eventually move to v6 they won't just hide behind NATS. I fail to see what we are gaining by banging people on the head with v6 block. Do we think uptake will go faster? Apparently don't need v6 addresses because they never asked for them and they thought the threshold of filling in this nice LIR portal you can do in less than ten minutes there was too high a barrier entry for them to get this space. Do we think giving it away will remove that barrier? Is that really the big problem for employ v6. I don't think so. I think that is not solving anything to be honest. I don't see the point. Completely.

CHAIR: OK. Thanks. Hans. Couple of interesting things here: The question is, do we need to change the policy in order to get more people to get their v6 addresses? To me, it sounds like no, the barrier isn't really there any more. So the question is, what level of marketing which Leo said here should we do? We could I think we have spent all this morning doing awareness of the v6 thing that is happening, is that awareness or is that marketing of the service? There is somewhere in here there is a border, right? If we had been commercial companies, the presentations this morning would have been marketing presentations for the service. I think it's a good idea that we suggest to the RIPE NCC they do more information to the members that there is v6 addresses to be had and how to do that. We do that traditionally through training, we do that traditionally at these meetings. Maybe we can do it in the newsletters that go out anyway. Maybe we should do it in more direct mailings or in other interactions like whenever you contact the Hostmaster maybe there should be by the way, do you know that you could also get v6 addresses? I mean, there are levels we can use here to create more awareness without necessarily calling it marketing. Thanks.

CHAIR: OK James.

AUDIENCE: I can sympathise with technical people at LIRs who are unable to get their first v6 PA block because they need management approval, how about just proposing just the first /32 v6 PA doesn't affect their billing score

CHAIR: We can't actually do that. That would be AGM matter, actually.

AUDIENCE: I am still wondering, this is a solution but what was the problem? The problem that is suggested that exists is people are dying to start with IPv6 but they can't get the addresses. Well, that is not true. So, I think it all boils down to a glorified PR exercise doing this, closed eyes automatic assignment without thinking whether we still think it was a good idea ten years from now when we wonder where the new swamps space came from. So I think people should never be forced to accept gifts which they didn't ask for. If people need it and think there is a high barrier, then we are lack lacking in our information profession, so we might have a look at that, maybe the regular NCC member letter that goes out every couple of months or so, could carry yet another article on how you get an IPv6 address block that ask probably as effective as any version of this proposal. Without the, I think, very, very dangerous side effects of handing out address blocks to people who don't want them, don't need them, will sort of lose them and then we have created more of a problem than we have solved.

CHAIR: OK. I think that sums it up pretty well. So we don't seem to have consensus on this, either. But we seem to have consensus on giving a message to the NCC: Please be a little bit, if possible, be a little bit more proactive about telling people how easy it is to get v6 addresses and deploy v6 and things. And we will all get together then and decide what to do with the proposals.

Give Lutz applause for standing up there and catching all the matters.

(Applause)

CHAIR: Now we go into the contracts and certification session. We have about 40 minutes left of working group time. We will run a little bit over into lunchtime but we started late. So Nick, could you please come up and summarise your proposal, 2007-01.

NICK HILLIARD: Good morning everybody, I think. My Nick is Nick Hilliard from INEX and 2007-01 is a proposal to increase the responsible stewardship of directly assigned or at least provider independent numerical resources such as PI address space, ASNs, that sort of thing. Now, this is just a brief recapitulation of what the proposal is all about. First of all, we have a situation where provider independent address space, they are all handed out free and this creates the rather anomalous situation whereby they are, therefore, more attractive to end users than PA address space. This is not what we, the community, in RIPE really wants to see.

We have a secondary problem in that there is a very serious level of abuse in hijacking of IP address space simply because the data in the RIPE NCC database is rather, well as Wilfred and others have pointed out, it's a little bit dubious in places. There is indication in the proposal about sub-assignment. Just to reaffirm provider independent IP address space are direct End User assignments, knots for reassignment.

And as I have mentioned the responsible stewardship issue is very important because currently, IP or at least PI address space is handed out with no expectation that it will ever be seen back again, and this creates numerical routing leaks, where this address space just goes off out into the ether and nobody hears from it again. This needs to be sorted out.

As a final consideration, we are at the position that we are just about to start handing out PI, IPv6 address space or at least this is one of the proposals at hand and it's very important to get a good policy into place before we start handing out any of this address space because PI would seem to be where things are going, or at least IPv6 where things are going.

Now, from the policy point of view, the policy just tells RIPE look you know we have a problem here, just go off and deal with it. A little bit more complicated than that. These are some of the issues that RIPE have been having to deal with, and there is quite a lot. Apart from the budgetary planning, which is to say how is this going to impact on the RIPE NCC budget, there is liaison with the Dutch tax authorities, you know, is this sort of thing going to cause problems with the relationship that RIPE has with the Dutch tax authorities. There is going to be an update necessary to the articles of association, probably. In terms of local Internet registry end user contracts, there was a suggestion that the RIPE would create a contract for this purpose, that is not a reasonable position to take. RIPE NCC can create suggestion for what a contract should contain. And the pre implementation planning will also require approval at RIPE the RIPE NCC general meeting, in particular for the articles any changes that might be necessary for the articles of association.

In terms of on the ground implementation, well I think I am very glad not to be involved in this because it sounds like a very difficult project indeed and when all is said and done and when it's completed, I am going to take my hats off to the people who have who are going to be involved in it. It's going to be a multiyear project, there is going to be a lot of difficulties. One of the things which is becoming clear is that although ERX assignments are explicitly mentioned in the proposal, they will be put at the bottom of the list. Now, they are categorically the most difficult assignments to deal with and it's not clear whether RIPE will be able to deal with them meaningfully at all. This is something that is going to become clearer as time progresses. But it's worth mentioning this.

The there was an email sent out by Axel to the address policy working group mailing list, suggesting that for direct assignments to end users that it would be necessary to become a local Internet registry. It appears in retrospect that that is probably not the best way to deal with it, so there is probably going ton associate membership category which will, apart from having a lower cost, will have fewer rights and also fewer responsibilities than running a local Internet registry. It's a good compromise between not having, the possibility of direct relationship with the RIPE NCC and the other alternative, which is the local Internet registry system.

The reason that we do need a direct relationship path with the RIPE NCC for PI assignments is that there are some pathological special cases, for example ccTLDs and smaller IXPs where you have on the one hand, a requirement for political neutrality, I mean if you have a requirement to get PI address spaces, if you request them and then pay an existing LIR member for them, you could create the potential situation that those members suddenly become preferred members of your association and that creates all sorts of political shenanigans that really as a smaller IPS I don't want to have to deal with personally. And similarly, when you have to pay lots and lots of euros to maintain your address space, this all creates a problem, so these are kind of the reasons why the local Internet registry mechanism that Axel was suggesting, probably isn't the best way of dealing with it.

For address holders who want to continue the relationship with their existing LIR and pay for the addresses through their LIR, that is fine. It's estimated that the vast majority of end user assignments will be handled by existing LIRs and that you know, only a tiny percentage, you know, a couple of percent will be going through the RIPE NCC, anyway. So this vastly reduce the burden on the RIPE NCC.

So these are just some of the issues that have come up since then. I think we have broad consensus on the on the proposal, I think everybody agrees that it's a good thing, it's a necessary thing and in particular, given our position with IPv6 provider independent assignments coming up, it's the right time to do this.

So, questions?

CHAIR: OK. A few words from my side on where in the policy development process this thing is right now. We had last call on the address policy mailing list, the last call ended on Monday this week, so formally, it's now out of the hands of the address policy working group. It's one week now in the hands of the collective working group chairs group to decide on where the process has been properly followed and to determine whether there is done consensus or not. It's being discussed so there is no final outcome yet and it will be discussed for a couple of more days. Yes. So much more for that.

If it goes into policy which is likely to happen, eventually, then the next thing that needs to happen is that RIPE general meeting, the AGM that has the legal power to actually do things like implement a new type of RIPE members and such, is to discuss it and to agree on it and get the status changed and so on so we have a RIPE general meeting today and if you are a RIPE member, please go there. It will come up, there will not be a possibility to actually have a decision today about it, because this has to be sent with invitation letters and everything in advance, but we can voice what we want to see happen today and vote on it on the next AGM on the next RIPE meeting in due do you knowy and in parallel of course the NCC can planning the actual implementation.

So I see Michael Dillon standing there.

MICHAEL DILLON: Overall we are in favour of this proposal, not just me but even the company I work for in this case. I would ask a question on the list and it I didn't quite see the answer, was that would the implementation of this be able to be separated into two phases so that future PI allocations could be done under contract before all the rest of the work that is done, which I presume is needed for applying a retroactively?

CHAIR: This is basically the plan, that as soon as this is formally in place, all new allocations, new assignments, will be under contractual basis. And somebody with a really, well, with well good nerves, then goes through all the existing stuff and gets it done.

MICHAEL DILLON: OK. Thanks.

CHAIR: So�

AUDIENCE: Just for probably my personal information, I suppose there is knew version of the proposal that has all these subtleties and refinements in it?

NICK HILLIARD: Well this gets back to what Gert was saying, that the proposal has hit the final stages of last call. The proposal doesn't have all of these subtleties mentioned in it. Primarily because they are operational requirements. I think there is probably some level of community expectation that, you know, RIPE will go ahead with these suggestions as they are suggested here, but they are explicitly not in the proposal and it's probably too late to put them in at this stage.

CHAIR: Actually, I was hoping to get Axel to say a few words about it. There he is. He was hiding in the back.

AXEL PAWLIK: There is not that much more to say. I agree with what Nick has said. We like a challenge, this will be a challenge, it has been a challenge already between here and the services working group and the general meeting and what goes where. It's fairly complex thing. We in the executive board have followed this, have discussed this informally [unclear] we think that we can implement it as Nick has basically put forward. It's good practice to look at articles of association from time to time. This is something that we possibly can implement through associate memberships, things like that. We would look forward this afternoon and general meeting and, by the way, if you want to attend the general meeting and haven't registered yet, please do so now. We would look forward to hearing something about prospective fee levels and the like. Otherwise, yes, we are looking forward to implementing it.

CHAIR: OK. A couple of things: I think most of the stuff has been said, I just want to sort of wrap it up and formalise it. So, well, interrupt me if I am saying something stupid now. I would actually want to put a formal action item on the NCC to, and also in the minutes and there is less room for misunderstandings, to help draft a contract or a contract framework for the LIR to End Users. Because we have something like 5,000 LIRs, they all have a lawyer and I don't think it's a useful exercise to have them all start from scratch, so if we have some sort of contractual framework that has the details that must be in there and can be adapted to regional law, that would save all the local registries a huge amount of work and make sure the important things are actually in the contract. So that would be my action item number one to the NCC.

I don't actually see anybody shaking their heads, jumping up and down, running to the microphone. OK. It's an action item on the NCC so Axel is jumping up and down and happily agreeing to do it, or did I misunderstand that.

AXEL PAWLIK: Well, I hesitate to provide contractual frame works, anything that does look like an actual contract, to so many different LIRs in different countries in our service region. I would very much like to provide you with principles for contracts, basically the corner stones that, from my point of view, need to be in there to make it all work.

CHAIR: I think that would be perfectly fine, just having something I can give to our lawyer and say, please draft a contract for our customers that really has all these things in it and everybody else that is needed by local law.

AXEL PAWLIK: Happy to do that.

CHAIR: Thank you. The second an action item is actually also new and that is just to formally bring the ongoing policy thing to the AGM today. Just bring it up and say, the Address Policy Working Group has agreed on we need to do something for Dubai. Thank you. Is there anything else that needs to be handled here? Is there any open questions on how this will hopefully go along, any comments that we should take into account. It seems the network is back up. People are still listening. Maybe we have just done it. Nick, thanks for coming up and summarising things.

(Applause)

CHAIR: And now it's Nigel Titley. Is he around? Yes, he is also hiding in the back. As you are hopefully aware, there is a project underway in all the regional registries to get resource certifications, which are meant to be useful for improving the quality of the data in the RIPE database, improving the ability for local registry to actually verify if a customer comes up and says this is my network, please route it for me. And of course this directly tackles address policy because the things that we decide that should go to local registries, have to be signed by the RIPE NCC to actually make sure that it's valid. And they have come up with things that need implementation.

NIGEL TITLEY: I hope this is the last time you are going to have to put up with me presenting in this conference but let's go ahead. Right, as has been said, the Certification Authority Task Force having decided that initial certificates should be issued or should be available at any rate, has put forward this proposal to indicate how it should be done and the various principles that should apply.

OK. This all came from the last CA-TF meeting in March 2008 and I am presenting on behalf of the CA-TF and awning ward questions should be directed to the CA-TF of course of which I am also a member.

OK. This is a summary of the proposal: And I won't insult your intelligence by reading it to you, but basically, it allows provides a guideline on how members of the RIPE NCC can receive certificates for the PA space that they hold.

These are the main points: Firstly, the RIPE NCC will issue certificates upon request. We will not force them upon you. You have to ask for them. And but we won't charge for them, not to start with, as far as I am aware, anyway.

Only RIPE NCC members can request a certificate. This is actually quite important because it's quite important that there should be a contractual relationship between the issuer of certificates and the person that receives them.

Third point: When the RIPE NCC receives such a request, they may actually ask for details to ensure that the requester is the actually holder of the resource concerned. That is of the IP address space concerned. This may appear fairly obvious but the RIPE NCC can't go out issuing certificates willy-nilly to whoever turns up and claims to own address space.

The certificate will be issued via a secure channel and at the time of the proposal this is proposed to be the LIR Portal which is presumed to be secure.

Finally, no not finally this is a slightly contentious but it's quite reasonable when you look at it. The certificates will only stay valid as long as the LIR retains its membership status. So, in the event of continuing nonpayment, cessation of membership, closing of the LIR, et�cetera, et�cetera, et�cetera, the certificate would be revoked. Now, the reason for this, of course, is that the certificate is linked to a contractual relationship. As soon as that contractual relationship is broken, then the certificate should no longer be valid.

And finally, technical issue: You can request a single certificate for multiple blocks of PA allocation if you wish. And this will be the default. If you wish, on the other hand, you can request multiple certificates for multiple blocks. It's entirely up to you but this will be the default.

That is basically it. This is the first time the proposal has been put forward you. Discussion.

CHAIR: OK. I start the discussion myself, actually, and complain about PI and AS numbers and things.

NIGEL TITLEY: Right

CHAIR: The proposal said pretty explicitly that an LIR can come and ask for its PA space.

NIGEL TITLEY: Yes.

CHAIR: So what is the plan for the other things that show up in the routing table and should have certificates?

NIGEL TITLEY: As far as I am aware, this proposal only covers PA space. If there is an intention to extend that to AS numbers or PI, then that will be the subject either of extending this proposal or of an additional proposal.

CHAIR: OK. Well, not speaking as an address well, I can't avoid speaking as an address policy chair right now, but I think we, given that we will have a framework for PI holder contracts, soon now that we should tie these together and include that, if a contractual relationship to a PI holder exists.

NIGEL TITLEY: Yes there is no reason whatsoever

CHAIR: For a certificate.

NIGEL TITLEY: There is absolutely no reason. Where a contractual relationship exists then I don't see any reason why a certificate should not be issued

CHAIR: And that is half of the reason why we underwent the exercise in 2007-01. So this should go in there.

AUDIENCE: One argument here could be that let's move ahead with this as a starting point and then we can modify this policy to include other things like AS numbers and other address space when we have some experience with this. So don't stop this process by waiting for the other things to fall in place.

NIGEL TITLEY: Yes. Bear in mind this came out of the march meeting when the PI proposal was not fully formed or not fully set in stone.

CHAIR: I think if we word it carefully, if we put the clause "if there is a contract then something else holder can get a certificate as well" it should not be holding up this, but as soon as the contractual framework is there, you can automatically get certificates for the rest. But that is not for me to decide, that is for you to decide and for the mailing list list, so other comments please.

AUDIENCE: How about when there is an LIR that has PI space? I think of small registries and exchanges and stuff like that.

NIGEL TITLEY: If there is a contractual relationship with the RIPE NCC then I don't see any reason why such objects shouldn't have certificates associated with them.

CHAIR: OK. Any other comments? Please. We have time for before lunch.

MICHAEL DILLON: Am I correct in understanding that these are the same certificates that would be used as was mentioned before, would be used to allow or disallow a BGP announcement to come through a filter?

NIGEL TITLEY: Yes, correct.

MICHAEL DILLON: Therefore, if a substantial number of LIRs have these certificates and implement systems so that all BGP announcements are pre filtered based upon the certificate, and if the LIR's budget inside that the budget for being a RIPE member inside the company is held in some kind of unimportant corner of the company because it's such a small amount of money and only happens once a year and they fail to pay on time because it's not terribly important, all of a sudden all Internet access for that IPS could be shut off

NIGEL TITLEY: Yes, I used to sign the RIPE payments for BT and yes this can happen.

AUDIENCE: So this is called securing the routing system?

NIGEL TITLEY: It's also called getting your payment system in decent shape. Which kind of leads into the question: Is it appropriate for the people who run the LIR in a company, is it appropriate to allow them to request such certificates or should this thing be handled at a higher level within the management of the company? Should RIPE actually be issuing them just to the administrators of an LIR or should demand that the CFO or or the legal counsel for the company sign an agreement before the certificate is issued to be sure that the people receiving the certificate understand the potential implications of it for the business?

CHAIR: That is surely an internal business process within your company?

AUDIENCE: Well, let's say that, in any company, I mean there are going to be well-run companies and less well-run and poorly run companies, and for the Internet to function, we want everybody's network to function; we don't want all the poorly run companies to keep disappearing off the network because somebody forgot to pay their bill, so I mean, the RIPE NCC should really you know kind of work for the collective good here and help poorly run companies to not make those mistakes, and in fact, one might be able to make the legal argument that RIPE NCC is actually damaging these poorly run companies by ahow long them to shoot themselves in the foot. I am not a lawyer so I don't really know if that is you know, we can see that there is a potential down side of this whole system.

NIGEL TITLEY: There is always a potential down side of not paying your bills.

(Applause)

CHAIR: You know, I think I see the point, but I don't think we need to have this go back and forth any further because, well, yes, there is there is there might be a problem here but, on the other hand, we might want to encourage timely payment, and I know that the NCC is not that strict about it, so, usually, you don't lose your address space if you don't if you are overdue for one day or so, so you need to be serious about nonpayment to really get hit. But there was a comment from Lutz then I think Daniel and Hans.

AUDIENCE: I had the same question about entities certificate or DNS signature is broken yesterday. Yes it's intentional, routing systems should routes which are not certified. It's intentional. Has to be so. Otherwise, we have the problem as the old ERX assignments, nobody is available, nobody is responsible, we do not get anything. Routing has to be cut for such he be entries.

AUDIENCE: To Michael and to Lutz, Daniel with RIPE NCC hat on. Yes, I think Michael's concerns are valid, I think they should be brought up here. At the NCC when we were looking at this and when the task force was looking at this, this came up and it's quite clear that a lot of education and other activities need to be done to actually tell people what it is that they are getting into, and that is part of the programme. Yes, I think Nigel is also correct to say it's how this is inside companies, it's an internal business matter, so we can't go and dictate that or even make too strong suggestions but we can say these things are important. I think it's not up to the NCC to say how the certificates are being used.

NIGEL TITLEY: Correct.

AUDIENCE: So you know, if what Lutz wants gets implemented, only gets implemented if the ISPs want it that way and if what Michael fears, like you know automatic disconnection happens, it's only because ISPs implemented it that way. Quite frankly, my personal opinion is, and it's an informed opinion after talking to ISPs in settings of sort of critical resource management and things like that, that once I have heard were very careful with this and actually rightly concerned so the way I personally see this evolving is that we get use of certificates for purposes of provisioning and things like that, first, which have much longer cycles than realtime cycles and only if we gain confidence that this is actually working will we use it in stuff that is closer to realtime.

NIGEL TITLEY: Yes.

AUDIENCE: So the upshot of this, this is all important but it shouldn't influence the policy, which is what I think Guert was trying to say. I think these things needed to be exposed.

CHAIR: Thanks and it's in the minutes now and we really can read it up, think about it and make a good decision.

AUDIENCE: I was following up on what Daniel said, that the routing policy between the ISPs is not dictated by the policy we set here but looking at this from the other side, as long as we don't have the certificate, it means that anyone can announce, BT or anyone else, routes, and destroy their business in a violent way, so paying their fee to RIPE NCC just as they pay their fee for as SLL certificate to secure their online customer portal is sort of significant part of their business and I am quite sure that all this telcos know how to cut off their customers if they don't pay their bills. At least they are able to do that for phones. They may not be able to do it for Internet but some are getting there, actually. And if somebody wants a purchasing system to automate this, I mean I am in the in the business of providing that.

CHAIR: OK. Thanks for the comment and I think that was an important one, the certificates give people the ability to do route origin checking. If it's only used for ISPs towards the customers, we already have win situation, that might not ever ever hurt BT but might help them because customers cannot come up and say this is my address space.

So I think I hear some concerns about the specific implementation in the end

NIGEL TITLEY: Yes.

CHAIR: But that is not really part of the policy. I think we should go forward with this and make it a formal policy proposal, make documents and we will be happy to help you.

NIGEL TITLEY: And we can adjust the wording to apply to other objects other than PA space.

CHAIR: Thank you. That is pretty much it. We have recovered the time that we started late. It's now five minutes before lunch. Thanks for coming, thanks for having a good discussion and I hope to see you all back tomorrow at 9�a.m. so don't party too much tonight. I have been told that this PI business is important and it will be in the Address Policy Working Group tomorrow at nine. So be there or don't complain. Enjoy your lunch.

(Applause)

Address Policy Working Group Session 2 9:00am, Thursday, 8 May 2008

CHAIR: Good morning everybody and welcome back to the Address Policy Working Group. We are already three minutes late, so please grab your coffee and take a seat.

I have first of all, I have, well the agenda for today. That's the same slide that was there yesterday. First block is to restart the provider independent address discussions since we now have a good base for the contract framework, and can well, discuss these without having to argue about contractual basis and stuff.

The 2008-01 proposal assigning IPv6 to every inetnum holder will not be discussed any more because the proposer has decided to withdraw these proposals. 2008-01 and 2008-02 have been officially withdrawn yesterday since he got lots of feedback, which said, there is no concerns on this proposal, so he said it was valuable input, but the proposal itself is not going forward.

We will spend about 30 minutes on the PI stuff, trying to figure out how to proceed.

And then we will go to the end of IPv4 session discussing the global policy for the remaining IPv4 space which is the thing /8s to RIRs when the IANA pool runs out.

Then there is the proposal from Tony about corporate, if the distribution of the remaining IPv4 free pool, that's the if one RIR runs out of space, blocks can be transferred from other RIRs. Tony will be here and collecting feedback on what he think about it.

Then Filiz will give us an overview on how transfers work in other regions because that's a fairly hot topic these days. And then we will discuss the specifics of the 2007-08 proposal, that's the marketplace. If there is anything else you want to see discussed either come up now or just mention it at the end when we have any other business open microphone.

I see nobody going to the microphones. Let's just start right away.

I am sure you remember the 2006-01 proposal that was trying to bring forward PI policy for IPv6 that everybody could agree on, and well, there has been three iterations of this proposal and until a certain point it was clear there was no consensus and one of the big blockers was that the proposal said, ah well, you should have a contract with the RIPE NCC, but it didn't specific what specify what sort contract it should be and people were unhappy about that.

We have that part now, we have a formal way to get the contracts with 2007-01, so we can move ahead here.

In the discussions about 2006-01, we had arguments for /32 assignment size or /48 assignments, and some iterations of the proposal had, weren't in there that if a magic solution to multihoming is to be found the PI space needs to be returned. Actually the latest version does not have this any more, so most of the stuff that was sort of controversial is already not in the version 3.01 any more. But, on the other hand, the proposal is over two years old, so the overall IPv6 network and the view of what's necessary and what's not necessary might have changed since then, so the goal for now is to get feedback what should be in there, what must not be in there, and then Jordie can integrate that and we can proceed with the proposal.

So, what do you think? Should we have a provider independent address space in IPv4? All the other regions seem to think that this is an absolutely must, and there is no way to do without. So, if we decide that PI is evil, are we giving RIPE members and unfair disadvantage versus other regions or is it just being a lemming and following everybody off the cliff? Do we need something else then at 48 as assignment sites for end sites? What do we have to fulfil to be able to get a PI prefix. I think James was first and then Wilfred.

AUDIENCE: I'd say yes we need to do P IPv6 because the reason there is magic multihoming method otherwise. A /48 is, I am happy with, we need to make sure that the PI allocation is big enough that they won't need a second one running out of space and a /48 gives you two to the 16 sub net, so that I think should be large enough for anyone. Maybe a larger if they need so.

AUDIENCE: Just not speaking in favour or against of the core of the proposal, but just a couple of logistical observations. First of all, the thing like differences in the regions, this is not a global policy proposal. It's just a regional one. So we are perfectly fine in this region if we decide to not follow the lemmings for whatever reason. If there is a feeling, that sort of putting out my Address Council hat for a moment. If there is a feeling in the community that this should be coordinated across the regions, then it should be put up and presented as a global policy proposal. Otherwise, I am pretty fine with the fact that we are doing things which other regions are not doing, or we are not doing a particular thing which other regions are doing. So sort of that's part of the formal gain in the policy development here.

The other observation I'd like to put into the discussion is that we have pretty much removed most or even all of the restrictions in the regular policy environment to get IPv6 address space, not looking at the fact whether it's PA or PI, because looking at the local Internet registry level or looking at the ISP level, there is not too much difference actually. It shows up in the routing table one way or another. And we already have this special provision force exchange points to get PI, and I really don't sort of see why we should have, in the long run, two or maybe three or maybe four or maybe five, whatever, special case provisions in addition to the regular distribution channel. That's, again, not speaking in favour or against, just short of trying to find out whether we need the regular PA stuff, whether we need the special exchange point stuff, whether we need the special PI small stuff, whether we maybe need something which is in between.

And the last observation here is regarding�

CHAIR: Could I just, I am losing track on all the different points, so I want to sort of comment on the individual things and how I think we could tackle it or whether it's relevant.

Yes, this is not a global policy proposal. But there has been feedback on various lists at having a fairly major imbalance between regions is actually annoying members of one or the other region that say, if we just had our headquarter in a different country, we could do our business in a completely different way. So this is something to take into account.

It might be a useful exercise to try to align the policy spec, but I think that's fair impossible.

Regarding the [unclear] they could become an LIR and get a /32 approach. For certain size of enterprise, this is hard because LIR is expensive. For larger enterprises, this is pretty much not a problem, but there is sort of, well, psychological hurdle in declaring themselves to be an ISP, because they feel they are not. So, maybe this is not really an obstacle because they could become an LIR and just get a block. On the other hand, a routing table slot is a routing table slot but if they only need a 48, would they be happy with a 48 then?

Just pointing it into the discussion. You had another point and then we have some more speakers.

AUDIENCE: I think we should go on with [unclear] because the third one is not related directly.

AUDIENCE: I think when I started working on this policy proposal in different regions, I started with size of /32. Then in several regions there were comments that the /32 is too big and in fact the final policy that was approved in AfriNIC was a /48. Now, there has been a small discussion in AfriNIC because even the staff realise that all the /48s are being filtered and they are unable most of the ISPs to sort it out, at least not in a short time. So I just want to make this observation so when we consider the size, we decide if we want to be in the risk or in the situation of having a risk of during sometime, most of this PI not being routed correctly, okay. Just an observation.

Then, regarding how to move on with the policy proposal. We just made a small change in the way we proposed this to LACNIC, which is the only region which is still not approved in addition to this one, and it's breaking the policy in two different policy proposals: One of them for the organisations that already have IP 4 PI, so if they already have IP 4 PI they can immediately get an IPv6 PI, so this seems obvious it will past, and then asking for some extra justifications for those that do a new start which just IPv6 PI. Just an idea about a possible part to proceed here in case we have too much discussion in a single proposal. So we can split it in two ways. If you have already IPv4 PI, let's go for this and if you don't have, maybe we need to have more discussion about the requirements.

CHAIR: Which is something I personally wouldn't be so happy. I want a v6 policy that's clean and not too much tied to the v4 stuff, so people would run for a v4 PI to qualify for a v6 PI or something like that. So I'm not sure whether this is really a good idea.

There is more people waiting behind.

AUDIENCE: From SIDN. We are unable to deploy IPv6 at this moment so I want to talk in favour of the proposal at this moment. A /48 would be sufficient for our operations to get independence of the ISPs in our country.

CHAIR: Specifically asking about this. As Wilfred mentioned a possibility, would you it be a possibility for you to become an LIR and get a /32 or is there specific reasons why this is bad? If you help us understand your situation better we can make a more educated decision on why.

AUDIENCE: Our main objective is to get an L registry running and not to be an ISP on LIR in that perspective. So we would not at first idea become LIR to get the IPC blocks.

CHAIR: Okay.

AUDIENCE: Some observation on Jordie's comments about the /48s being filled by [unclear] I still think we should even with v6 should stick with that routing or other administrative purposes, shouldn't be a reason to get a bigger block and some observations made during Wilfred's talking about, yeah, we get like special case A, special case B, so more or less in favour of PI because we need it anyway and we can stick around being special casing for DNS, special casing for exchange point. Special casing for CC D L registries and in the end we need it anyway.

The third observation I am making is that maybe, I can't really rationalise but somewhere I have a gut feeling that the /32s of today are the/As of tomorrow and to simply become an LIR to get a /32, we might regret this in 20 years and having the same thing again with IPv8 or IPv10, whatever it's being called.

CHAIR: One thing I forgot to answer to Wilfred about all these special cases. I think if we get a decent PI if we come to the consensus that we need a decent PI policy, then we can fold in all the special cases. So, there would be some benefit to it, if we decide this is wad, then we will have to live with some special cases, but well, then they are not doing much harm, but

AUDIENCE: May I just reply to that and to the SIDN guy.

I think with the changes that are on the way with IPv4 PI assignments requiring a formal relationship either to a local registry or to the RIPE NCC, I think we we should start to forget about the distinction between being an LIR, this perceived emotional formal distinction between being an LIR and not being an LIR. The thing that's going to be the reality of the future is if you hold resources, you have to have a contractual relationship with someone, either you either an LIR to do that with, or you go to the RIPE NCC. And if I hear the arguments like I don't want to be an LIR, an honestly I don't see what's so bad about being an LIR, it's not that much work or that much cost, then in the future you will have to have formal relationship with the RIPE NCC anyway. So whether or not you call that a special case assignment and you get into a contract or a contractual relationship or whether you establish an LIR, there is no big difference. There may be a difference and that's things that we try to discuss or not to discuss yesterday in the general meeting, it's just the special cases that come with a particular type of contract. So, I don't really see why sort of some of our colleagues are so afraid of becoming an LIR, because there is no too much difference in and looking in particular to IPv6, being an LIR is not the big work load on the RIPE NCC, because there is much less overhead, there is much less clerical work to do and much less other things. So, for me personally, it just boils down like finding out is there a difference between the size of a block of resources you get, either being 32, being 48, being 47, being 31, is there a difference in the workload on the RIPE NCC, then you have to probably pay a different amount of money because that's where we base or fee structure on, or there is not. So what's the big difference in the end? We already removed the requirement to have customers in the historical sense, so you just can get your address block, that's my point of view.

It may be simplistic a little bit.

AUDIENCE: In terms of the PI proposals, we are actually waiting on PI for the... /48 wouldn't be big enough in terms an assignment for pH in terms of address policy which we have laid out. I don't want to go into what we are doing on the face of the record here but I'll certainly go through it with anybody what wants to have a look at what we want to do.

In terms of a documented exception, no problem trying to document our need; I have that. I think there is no way that we want to register as an LIR. I think it's bad practice in terms of, you know, creating exceptions to get around rules. I think we need a firm documented approach in terms of PI and PA space. If we don't have that, I think you are going to have dichotomies in the likes of, you know the way you have it in ARIN right now where you have other organisations that have space that ordinarily would go to LIRs but they have it due to historical regions or it's grandfathered it in. Just the point it's that if we could lock on the PI discussions but for our organisation /48 isn't bill enough. Spec spec specific question to you: Can you second the LACNIC observations that ISP are filtering this or is it more like some dark edges remain but mostly it works?

AUDIENCE: That's the key to what we are trying to do. In terms of I mean, it could be argued that any organisation doesn't need more than a /48. It's a massive amount of subnets and IP addresses. But it's the routing. Where ISPs are only routing a minimum of a /48 that puts boundaries around what you can actually do with T

CHAIR: I was specifically aiming at, have you seen that it works or have you seen that too many ISPs are filtering the 48? So is 48 a reasonable thing because it works or do we wiggle around the routing problem?

AUDIENCE: I think it's reasonable because it works right now.

CHAIR: That's a very important data point.

AUDIENCE: Just in terms of our ARIN and our APNIC allocation, we have two /44s, or [unclear] in [unclear] region. It's part of our strategy that we are trying to get a 43 PI from RIPE as well. So...

CHAIR: I completely lost track of who is next, sorry.

AUDIENCE: I keep hearing the word enterprise. There is another community out there called governments and hopefully if the communication we are launching in a few weeks time has the effect we want it to have, you will have requests for addresses from governments and governments don't have business models, they don't have customers. We in the Commission, we already run our own networks in Belgium and Luxembourg, we host content, we do all sorts of things. We have got 20, 30 thousand users inside. We will want our own v6 space. As simple as that. And I'd hope that when if we gain any traction on that, we actually have to appear to be moving forward and asking for v6 space, there are no silly reasons for saying no. Technical reasons, no problem. Routing problems reasons, no problem. But I think governments will want their own v6 space. How it's given, I'll leave that to other people to decide but they will be asking, hopefully I'd like them to ask, I hope the response is positive. Thank you.

CHAIR: Which is a good argument. Thank you. If you know who is next. I think Hank might be.

AUDIENCE: Although we have a sort of PI allocation for the peering LANs, we don't have our own allocation for our own services and because we are not an organisation by nature, we really would like to have them, but becoming an LIR just to buy IPv6 space doesn't feel right. We get our allocations through our LIR and I think the system was designed like that.

So it doesn't feel right to buy other space if you want to phrase it like that.

It would be no problem for us to have a formal relationship, and I guess it would be logical with either the LIR or the RIPE NCC itself to get our own routable v6 block. As it is now, it doesn't just feel right. That's why I am not an LIR yet.

CHAIR: Thanks. Important data point. Just people really speaking up that have the pain. Five more speakers and then I need to close this, otherwise we will not have enough time for

AUDIENCE: Michael Dillon, BT. I have helped companies get PI space in the RIPE region, also in the ARIN region. This is obviously not in IPv4 space. There is quite a variety of companies and business models and reasons for networking out there, and when you look at some of what maybe even for us are dark corners because they are outside the sort of typical networking area and typical enterprise customers, they really do have a need for in some cases, space that's registered in a global registry so that they can point to it and say you know, this is you can trust this IP address because you can see it in the right database and it's got our name on it in the financial services sector that is frequently done, and often frequently demanded by customers like banks.

I think when we started doing IP addressing and created this concept called LIR, it was pretty obvious to most people there were two types of networking organisations, and one type had relatively fixed needs. Their network wasn't going to grow very much. It was sort of bounded in scope. And the other type of an organisation was going to constantly grow and expand because that was the core of their business model; the ISP. I think with IPv6, we are getting into an area where a period of time where perhaps that growth isn't going to continue forever, there are a limits to growth after all. But, if we we have devised things so that the LIR is both the recipient of the big address block and the organisation that we expect to grow and grow and grow the network, and then the PI space is the recipient of the smaller address block and not expected to grow, not expected to add other organisations to their network. If we sort of change the way we do things with IPv6 so that a PI is not necessarily the small address size, and that a /32 is not necessarily only for those organisations that are in the ISP business. I think we can have a sort of a more rational system and there are more slots that any particular Applicant can fit themselves into. So...

CHAIR: Just for specific clarification, the sort of networks you have mentioned like banks, they want, mostly want global unique space that has their name tagged on it but they don't want to have it routed. They just need it for internal purposes.

AUDIENCE: This is the bank as a customer. Banks do lots of different things but one of the things they do is they do transactions between themselves.

CHAIR: This is really for none on the public Internet purposes but unique space for internal things.

AUDIENCE: Yes. The nonpublic Internet is growing and growing and I call it an Internet because it has many companies and they all have ASes and

CHAIR: I am aware of that. I just wanted to clarify it.

AUDIENCE: For instance a service provider that manages the transactions between banks.

CHAIR: Understood.

AUDIENCE: You know, they have to have PI space. So, if you have that type of a scenario that I described for a company like HP are going to say look, you are a big company. We don't want to have /48s, 49s and 50s, so we will give awe /32 [unclear] but you are not an LIR, we don't expect to you add other O to say your network. We don't expect you to be functioning like an ISP. You know, we just want to keep the relative simplicity of IPv6. Right now we have it so that there are three public subnet sizes: There is a /5 for the really small home users, people in their home or their apartment in the ARIN region. There is the /48 for any other customer of an ISP. For PI in ARIN region and I think LAPNIC is also a /48. There is the [unclear] for the big organisations like an ISP or an university or let's extend that to really non LIRs and let's not call it an LIR either. But do it on exactly the same terms you would do for the smaller organisations who get the /48 PI.

CHAIR: Thank you I need to cut you a little bit short. Sorry for that, but there is three for, four more people waiting in the line.

AUDIENCE: Hopefully I can keep it decently short.

I am most interested in keeping an eye on actually the effect en routing slots that's coming out of this. And well, okay, I would like to explicitly state that well, okay, there quite certainly is technical consensus with large scale uncontrolled use of PI will definitely create problems in the routing system. And we actually should take this into account in the address policy. Well of course dealing with a routing system is essentially the problem of the operators. But, well, okay, making clear in the address policy that certain things are really creating problems and under undesirable I think is a fair split of responsibilities instead of saying, well okay, let's work out the operators, the economic consequences of it and fight with the customers and raise the prices and so on. So, there are three conditions that I see where PI does not pose a problem. PI does not pose a problem where the PI announcement never shows up in the routing system. I would claim that we probably can minimise problems for PI space that is mandatorily renumbered every two or three years because that would provide at least a chance for cleaning up every once in a while, and of course, if the technical work that some people are working very hard on these days, in providing a severely upgraded IPv6 routing architecture comes to bear fruit, well okay we obviously will also be out of it, but my prediction is well that okay, solutions that have come out of it like say what we are seeing in this will mean that a PI addresses in the end will not show up in the routing system.

CHAIR: Which would then be perfectly fine.

Regarding the unbounded growth, we have the contracts in the way and that should stop explosion of this. We will see some growth, definitely. But hopefully not unbounded.

AUDIENCE: I fully agree, and so I wanted to explicitly state that well, okay, everything that you mention as being a threat, keeping people away from doing the contracts is actually a feature which, of course, may come with some comments like, well okay, I am really surprised to hear that, say, the EU Commission or HP or companies, organisations of that size feel threatened by, well, okay, the request to join a contract and, well, okay, of course the needs of large organisations say such organisations that actually have explicit IT service organisations in their tree. Well, okay, they almost you almost can argue in those case that is they have an internal service provider. So, well, okay, my request is whatever we do, I very much want to see some explicit notion in the policy that actually tells people that yes, PI is available in cases where it's needed but well, okay, it is really not the way that everybody like my dentist and baker should go.

CHAIR: Okay. Last speaker.

AUDIENCE: In regards to PI space, by saying that everybody could sign up as a LIR, you don't really solve anything in regards to the routing table. However, for PI space, I think it's needed for example, for organisations that don't want to go down the route as a LIR. It has something to do with specially what at the moment is being talked over IPv4, it's stewardship and it goes both ways. Basically they go to an [unclear], to one LIR and they ask them to get the PI space because they want also more just the PI space, they want consulting, they want help with getting their routing sorted out even though they are peering with multiple peers, they go to one peer and they will ask them to give them help. And because they don't necessarily have the knowledge, the know how to do it themselves and that's where I see that PI comes in. But obviously, when PI is is or if PI is implemented in IPv6, I definitely would be in favour of having a form of contractual or stewardship put in from the beginning so that

CHAIR: That's there anyway. We just signed it off yesterday.

AUDIENCE: For routing table point of view, it will if you force everybody that wants PI space to become a LIR you have solved nothing with regards to the routing table, that go grow anyhow, if you have 48 in there or 32 in there, because then you just have an organisation in there that needed a 48 and they got a 32 but they are still slotted in the routing table.

AUDIENCE: This is partly in response to the gentleman from HP mentioning that he was after I think a /44 and I got the impression that part of that was that so it could be announced in different ways as multiple /48s from various sites. I'm not sure if that was the exact case but I know people will be doing this with enterprises who got non-connected sites and want to announce things different ways.

I think it's important when people making address space requests that there is some mechanism had that they can specify how they are planning on announcing it so they will get a suitably designed set of space that they will find being routable. I am sure you are aware of it, there is a very sensible set of filters out there, prefix filters for v6 which makes sure that people aren't accepting announcements which are smaller than registry allocation sizes, so if somebody wants to get some PI and they shoe manage to justify a /32 they need to make sure they are actually get it from a block which it's announce with /48s if that's what they are planning on doing with it. If they get it from the block where it's only accepted as [unclear] they have got a block that's useless to them or will cause the whole filtering by the community to breakdown because they have gone and got PI, they have justified a /32, they wanted to announce a /48, but because they didn't ask for multiple /48s...

AUDIENCE: I agree with the former two speakers. I am running a network. It's from a global perspective as well. It's already there and I would like to filter and if we formalised it, we can probably get some dedicated block where we see the /48s or /44s or something coming and we know it's there and we can educate people on actually accepting those routes and get it go routed globally and technically, it is already there, so please formalise it and give me a framework where I can build my filters upon and getting some real things except for like people bend indicating all kinds of ways and finding different special case where is they would justify for basically PI, and just name it I don't care if it's called PI or whatever, but just find a way for people to get space and get it routed without getting a /32 and without becoming an LIR, because I am equally unhappy with like 5,000 people becoming an LIR and getting a /32 from a routing perspective is like 5,000 people getting a /48. In the end it's 5,000 prefixes in my FIB and my router needs to cope with it.

CHAIR: Okay. Thanks. Last, last comment please.

AUDIENCE: Just one short thing. For all the speakers who were talking about filtering, please keep in mind the current mindset that, well okay, primarily filtering for length of prefixes quite certainly will not meet the security requirements of a large scale production IPv6 network, so routing filters in IPv6 will become more differentiated and prefix length will be just a secondary concern.

CHAIR: Okay. We are definitely overrunning the time I have planned for the PI discussion, but it was I think important to get all the feedback. What I seem to be hearing is that there is no fundamental opposition against this. There is lots of voice that is say there is benefit to this and there is some concern on getting the mechanics right, so since we don't do any decisions anyway on RIPE meetings, I think we have heard enough input to start a new round with the document. I think Jordie has been listening very closely and Jordie and Filiz will prepare the next round of the document and it will be circulated on the mailing list. So then we need your input again of course to see whether this is the way it should be or some other details.

I think that was quite fruitful. Thank you.

There is the other IPv6, the other PI thingy I wanted to discuss today; that's the PI size proposal 2006-05, which basically says that if you have a number of hosts that you want to have PI addresses for, but the number of hosts that you have is not sufficient to justify a /24, but you need to get the /24 to have it routed, then you can just say I need a /24 for routing reasons and you will get the /24.

There was quite some discussion, quite some concern about this. One of the big problems was that it sort of makes it far too easy to get a big IPv4 PI block while the PA holder still has to do all the justification and everything.

We cannot discuss this today. Actually, I would propose to just send it back to the mailing list and restart the discussion there. Since we just have too much other things today that need to be discussed, and it does not seem to be such a big itch actually, so the urgency of the IPv6 PI was higher, so we take this to the mailing list, unless somebody objects and really wants to voice something today.

Okay. Thanks for understanding this.

So, now we enter the end of IPv4 session. This is the three policy proposals we have on the table today. First speaker is Roque from LACNIC these [unclear]. He was here well in Amsterdam, well on the last RIPE meeting on stage, and presented with a different head, but now he is working for LACNIC and bringing back a new round of this proposal.

ROQUE GAGLIANO: Thank you. Just to clarify. Right now I am a LACNIC staff member but at the time we introduced this policy, I was working for part of the LACNIC community and I was here last year, if all of you remember, presenting actually a proposal 2007-06, which had a similar, and the same concept as 2007-03 where we were discussing how we were going to distribute the last pieces of addresses from the IANA block to the RIRs. At that time, if you guys remember there was two proposals, one of the JPNIC team, another one from me and another person from APNIC. And what we wanted to discuss last year was basically if we could agree on that this was a good idea and if we can have a discussion on which would be appropriate allocation site for that last allocation from IANA to the RIRs.

What we are proposing basically, is that each RIRs is going to get an equal amount of space from IANA to each RIR. So what we did after the RIPE meeting last year is we just came together, we just rewrite the proposal and get a unique proposal and got the feeling from the different communities that, in order to get a consensus, the appropriate site would be one /8 per RIRs.

Just to remember everybody, this is a global policy to what it means is that each community has to the policy has to go through the PDP of each unit after it gets approved, it goes to the NRO, ASO and then ratified by the ICANN board. Just remember we are talking about a long period of time, and us as Geoff mention add couple of days ago, we are talking about exertion day perhaps of something, 2011 plus, minus 18 months, so... time is not something we want to have on our side.

So what's the status in different regions? In ARIN region, we presented this last version in Denver a couple of weeks ago and now the proposal is in last call, which means that it's going to go through the AC to their steering committee and the board, and that's what is missing there.

In LACNIC, we introduced a policy in LACNIC last year, a very similar one but a different value for the last allocations, so what we are going to do is we are going to be debating this new text next meeting in three weeks, but the previous text already got consensus, so we feel pretty good about that.

In AfriNIC, the same thing as LACNIC. The previous text was introduced last week, got consensus but now we are coming back with a new text to reach a final consensus and that's going to happen in AfriNIC 8, which is the first week of June.

In APNIC it's still under discussion and we did it, we did have some discussion in the last meeting.

So, basically just to show again how it works basically the well what we are going to do is we are going to reserve a /8 for each RIR, when the last allocation happens [unclear] is going to get the last piece, but then everybody is going to get one /8.

And that's it.

CHAIR: Thanks for coming and refreshing our minds on what this is about. I think I will make this very short. Three comments please. Zero comments is quick, but I had hoped for a little bit for feedback.

AUDIENCE: I think this is a really bad idea. I think any of these soft touch down type of proposals that fiddle around with address allocations near the end of IPv4, the IPv4 lifetime are a bad idea because all they do is they move the point at which IPv4 resources become hard to get and they move that point closer to us in time. So the effects you see, most of us aren't really concerned about IPv4 exhaustion, we are concerned about the effects that IPv4 exhaustion will have upon us and I think these [unclear] will happen sooner when we do things like this.

CHAIR: We have done a little bit of maths yesterday and it's sort of like for the big regions, this would have an impact of maybe two or three months actually. For the small regions, this is actually a major impact, so it will gift regions where the network is really tied together with strings, because they don't have money to upgrade anything. Some more time to get things sorted out, so this might be taken into account. I'm not sure whether it makes a really big impact for the RIPE region at all, two months, give or take. But it's important for the other regions, so consider this

AUDIENCE: You seem to be trying to sell this as a kind of global aid plan to less developed countries. I haven't heard it phrased in that way before. Now, I think

CHAIR: It's not my job to sell anything. I just want to point out that there is arguments against it and there is an argument that might be used in favour of it that should be considered.

AUDIENCE: I think the general public perception of this type of thing is that it's just people playing around with numbers and maths in some completely disconnected from the real world area. So yours is the first comment I have ever actually heard that actually ties it to a real world benefit.

ROQUE GAGLIANO: I just want to make a comment that if you look at I mean, we are not just trying to do maths because the maths is very tricky especially because as Randy's presentation yesterday showed, the amount of ISP that consume a big amount of addresses is very small. So a little movement in those ISPs brings a big move in those dates,. So I think this policy actually helps better because it brings certain certainty in a sense that okay, so what's going to happen when we can get to the last allocation? You don't know in RIPE if that last RIR going is going to be lack anything, AfriNIC, APNIC, whatever, so when we talk about two months, actually I mean, you just don't know who is the last one to go to IANA. So there is a lot of benefit on also like, today in LACNIC we have some proposals about what to do with [unclear] /8, they are saying okay we should keep something for double stack for new members to be sure they can do the other stack. We should try to get a maximum location site. People want to try to do some stuff. The other thing is that it's been argued that it's a very strong message that you give from the outside RIR community about that it's not business as usual, we are going to do something when we get to that stage not everybody is going to get very nervous about what is going on.

CHAIR: We are seriously running out of time. I am sorry for that, three more comments, then I will do a show of hands to get a feeling in the room. Then we go to the list.

AUDIENCE: I think when thinking about this, it's very important to keep in mind the actual play out of it, and whether you can actually enforce the policies that you are making. I have a very big concern when thinking about this that if the only substantial amounts of an allocated v4 address space with located in what's now called the smaller regions, what makes you think that somebody who really needs this address spaces from the sort of larger regions will not find some way perfectly within the policies to actually obtain that address space. It's so easy to set up, or to find a legal entity in those regions and just request the address space. So, that's number one.

The other is, a similar thing applies to all the policies about setting stuff aside for. How do you define dual stack stuff? How do you fine the specific purpose and how can you actually enforce a policy that has a special use kind of thing? Unless that question is answered, I think these things are dangerous, but that's just my private Internet citizen just put yourself in a situation when actually this has happened, you know, and BT comes and says here is BT Africa.

CHAIR: Well taken, yeah.

AUDIENCE: I think what we are facing here is the end of something, and it's kind of two extremes: Either we keep the policies as they are and we run and hit the wall or whatever Randy said yesterday, or we try to be smart and do sensible things. And the trouble here is that it's very unclear what sensible things R I mean, Randy had a quite a few good points in his presentation yesterday that as Daniel pointed out, it's very hard to predict what the behaviour of those with a lot of resources and then not only IP addresses but also money, how they can adapt to whatever we try to do here. So, unless we enforce a very strict regulation in the end here, it's going to be interesting to see if whatever we do has any effect at all. I'm not going to discourage us from trying to do sensible things. I am trying to have a controlled end of this lifetime, but I think it's very difficult to see how we can do this. Speak okay. We need to put this on the mailing list anyway. Just to get a feeling for the room, could I please get a show of hands.

First of all, those that think that this is a reasonable thing to do and that we should be following this approach and do some reservations for the RIRs. Please show me your hands now.

Okay. Quite some.

Those that think that this is a very, very bad idea and we should not change the allocation policies at this point in time no matter what?

My gut says that it's about the same amount.

And those that think that it is not going to make any difference anyway, so do whatever you like?

No, that was a comment that came up last time in the meeting that said, N equals one or N equals zero will not really make a difference for the RIPE region, so these folks said go along, it doesn't make a difference.

[unclear] nobody is really one person.

So, we really need to bring this to the mailing list and try to get consensus either way. Thank you.

The next thing is the proposal from Tony Hain. We also need to keep this to 10 minutes maximum.

TONY HAIN: I will be very quick so that there is time for discussion.

Actually, I wanted to change my vote in the last one because I didn't know you were going to ask the last questions, so I voted wrong. Anyway.

So, this is taking the previous discussion in a slightly different direction. Thinking about the state of, one of the RIRs has run out of space but not all of them, and what do we do in that time window because that time window, depending on exactly what you believe is either months or years, and it causes a strange warped input to any market that's trying to form, because you got run region where this resource is gone and another regions where it's still free and the expectation that people are going to sit back and just say well I'm in the region that ran out of space, I am out of luck, as Daniel was pointing out, you know that's not a good thing to go down that path and believe that people are just going to be nice and say, well, you know, the other region has it, I don't need T I will go find the resource, right.

So, any trading market that tries to emerge will have this fundamental impact of competing with free resources. So, the proposal I put out, the fundamental aspect was that the RIR who has run out of space becomes an LIR of the other RIR that has the most resource left. There are a lot of numbers that I threw out. I was actually just putting numbers on the table just to have a discussion. There was absolutely no discussion in any of the regions about those numbers. So, that's still there. The question really for the point today is do you want to go down the path of thinking about having this state of an LIR as opposed to people just running off to find the resource, however they want to find it. And we can talk about exactly what the mechanisms are independent of that.

The specific advantage of going down this path is that the existing relationships are maintained. If you are a RIPE member, you continue to work with, you know, RIPE to acquire your address space. The fact that RIPE is getting it from another RIR instead of IANA is something you don't care about. The specific disadvantage is that if you don't go down this path, you need space, you become a member of whatever RIR or you acquire some other entity that becomes a member of the RIR with space and therefore, they see more resource. You know, monetary income for the duration of whatever address space they have left. So, you know, there will be some financial shifting if you do nothing. If you go and you know adjust this, then there has to be some kind of cooperation between the registries.

We are trying to figure out how do they cooperate with each other when IANA isn't their central point of allocation.

This has been discussed at APNIC and at ARIN. At APNIC the discussion was rather negative. They chose to table the discussion with no opportunity for input. At ARIN, the discussion went the other way, and people understood the concept, believed that the concept was right, that the numbers that I had put on the table from wrong which I have no concern with at all. I assumed they were wrong. I was just putting something down. So with that, I would open the floor for discussion.

CHAIR: Okay. This takes a while. I see people already standing up. I would say, a limit to five comments and then get a show of hands, because we really already running into the coffee break.

AUDIENCE: One question: There are RIRs that have national registries between them and they are the actual LIRs. What does your proposal mean about the pools that are sitting there and, well, okay, for a world where everybody would have would be thinking about his own advantage should the RIRs that don't have national registries in between rush to create them?

TONY HAIN: That's actually an interesting point and possibly that would be a defence mechanism if you chose to believe that you wanted to do that. So...

AUDIENCE: Just a question, could you give us a little bit more insight why the APNIC region did not reasonably discuss it or did not like it?

TONY HAIN: There was nothing concrete. There was a specific instance where I was accused of racism, just leave it at that. You know, I have to assume that the assumption there was that you know, I was out attacking particular regions and I'm not, I am trying to say that there will be this state that registries will have customers moving all over the place if they don't do something to sort this out amongst themselves.

AUDIENCE: The point being that I am a little bit surprise that had a valid proposal does not get the proper treatment, i.e. a discussion or sort of development opportunity. I think it's not in line with our ways of living to just tell you or anyone else no, we don't do that and we don't even think about it.

TONY HAIN: I understand. I don't think we need to worry about that any further here today here.

CHAIR: I think we need to take that sub-discussion off line. I think it's a weird case but not for this room right now.

AUDIENCE: Ray from ARIN. I want to comment on the bullet regarding what happened at the ARIN meeting and the status of this proposal in the ARIN region. In fact, when a show of hands of done in the room it was 12 in favour, 25 against. Also, the Advisory Council had its meeting and the results of that meeting, which had been posted to the ARIN PPML, was to abandon this proposal in the ARIN region.

TONY HAIN: So further coming back, that was the original proposal, yes, the discussion was against and the follow-up question was: How many people were in favour of continuing work on this? And that was the point of this bullet.

AUDIENCE: Well, I think that this tends to give the impression that this proposal as it was proposed in the ARIN region is still alive and it's not. There is not been a counterproposal or a new proposal made in the ARIN region regarding this situation.

CHAIR: Okay.

AUDIENCE: Chris, from Google these days. I have a question about this in light of the situation that exists today where folks not in ARIN or APNIC or RIPE will go to other regions to get address space and use the other [unclear]. I know of at least two fairly [unclear] examples of this that happen relatively often.

I am not sure that the idea that you know I am not in the RIPE region so I am not just going to get address space from RIPE just doesn't hold water at all. People do that today on a well they do it today.

CHAIR: I think it's mostly in a more formalised way to get this organised without having people to set up subsidiaries all over the planet.

TONY HAIN: Large global corporations do this today, absolutely.

AUDIENCE: I am not talking about large global corporations per�se. I know of at least a couple of large global [unclear] do and they do it pause they have operation in region. This is people that only have operations in California and only have a hosting company in and have no links anywhere in the world and they have APNIC and RIPE address space and use in California.

AUDIENCE: I am from APNIC and also from JPNIC.

Just your comment, in this slide, the APNIC showed a closer with opportunity further or further discussion, I need to check if it is if it was this shape, but I am sorry, I didn't keep track of that discussion because of because I participated remotely. But I need to check of this situation. But, at least in APNIC, that that policy doesn't have the consensus, didn't have the consensus at the time.

And second comment is, yes, APNIC is the region which has the LIR but in case of the APNIC, we have a shared pool at APNIC and just serving to their RIRs with the APNIC's pool to the actual LIR. So this is not the case of your concern. Thank you very much.

CHAIR: Okay. Thank you very much. I have now heard a couple of comments on the mechanics of the policy process in the regions, but I haven't heard much about whether the proposal itself is something to go forward with. So please another show of hands how to proceed on the list.

First question: Is the generic wording of this proposal, the general idea, who is in favour of following up of this work in that direction? Okay. A few people.

Who thinks this is a stupid idea and we should just abandon it? There is too many people already asleep. Really, about three quarters of the room have not raised their hand.

AUDIENCE: It could be they don't have an opinion or they choose not to express one.

CHAIR: Well... since there were more persons, we cannot have more comments, sorry.

AUDIENCE: It's not a comment, just you are saying twice this morning, people are not awake. But there is maybe another reason why we are not voting is the way you are asking the question. They are the wrong question, I am sorry.

AUDIENCE: What are the right questions?

AUDIENCE: One of the right questions could be, not it is very, very bad idea or it's a stupid idea. It's not like this, I guess.

CHAIR: Well, okay. Anyway, I have seen some support and less voices about this is a very stupid thing. So I suggest taking another round on the mailing list and see what comes up in comments. Thank you.

Okay the next thing on our plate is the trading. There has been lots of discussion about what happens then the RIPE pool or the RIR pool runs out, that people are going to trade IP address blocks and there is a proposal on our plate to regulate the market for addresses, like in the RIPE NCC keeps track of documents and everything, and before we start into the specific proposal, Filiz has volunteered to give an overview on the transfer policies in other regions and the ongoing discussions. I need to ask you to speak fast.

FILIZ YILMAS: I have definitely try to be really really fast.

Just one clarification before I start going through the details of transfer proposals. I want to just make sure that I hear that question from other people, the transfer are recognised already currently within the policy framework of RIRs. The form and shape of these transfers are having new approach now with these new transfer proposals, and that is that the previous approach where transfers were happening just by simple takeovers or mergers, may not be the case in the future. So those new transfer proposals are targeting those cases. You know, this is the first thing to make very clear.

So, in previous times, yes, the LIRs, ISPs will take each other or they will merge, so their network will merge but the network will stay the same most of the time. The customer base would go on living on the same network, accordingly that the addressing would stay the same.

But this is now with these new proposals, that you will see in a minute, there is a difference, there is a different approach. There is something happening in that direction. And one other thing which is my preliminary note on my slides is that these, even the current practices at the moment where transfers are recognised by takeovers and mergers, they are happening in different frame works, because regional policies differ. We all know that there are five RIR regions and they deal with things slightly differently. You may there are documents, there aren't policy documents there aren't. In some them traditionally some details are listed like in ARIN's case they are very keen in listing certain things in their policy document, while maybe in RIPE document, you don't see that detail, but because the RIPE community defines these as procedures and leave it at the procedure level, okay. So anyway, it's not really one to one. That is my other important point to make.

Now, new transfer proposals: Why are we having to start with? I think it's everybody's consensus within this week and it has been for a while that we are approaching some interesting times, together with IPv4 depletion discussions and people are coming up with different policy framework, proposals regarding this, you know, same problem or transition towards the IPv6, whichever the way you would like to see it. But, yes, depletion of unallocated resource pool is approaching, it's much clearer to be a reality soon, well it is believed to be, so these transfer proposals that we are going to see in my slides in main, they are there to deal with these kinds of transfers which will not be emerging necessarily from takeovers or mergers [unclear] been understanding, but just transfer of address space between two organisations.

Now, we have three active ones of these in ARIN, APNIC and RIPE region and I will quickly start with ARIN. They call it a simple transfer of IPv4 addresses, and the major difference from the other two, it comes into effect after the IANA pool runs out. So as it is written at the moment, and it needs prior approval from the ARIN, so based on justification and need, is still a primary factor within ARIN's transfer proposal in the new one. They are bringing certain conditions on the transferring organisation, recipient organisation and the address space that is going to be transferred itself. Now, the terminology differs again. They call these organisations transferor and transferee, but I will stick to the transferring organisation and recipient org. for the sake of clarity in my fast slide.

The transferring organisation, what are the conditions that are being brought up? The ARIN member should be in a good situation, well the fees should have been paid recollect the policies should have been followed. They should be residing in the ARIN region and they should not have received any IPv4 address space within the preceding 24 months. And they may not request further address space within the next 24 months after the transfer.

Now, as the receiving organisation, there are a few more extra checks other than being a good member and intending to use the space in ARIN area. I am coming to the major point here: They need to justify to ARIN before the transfer that they seriously need this address space. And ARIN needs to approve that.

So, the other requirements are, they should not have provided any address space to somebody else in the preceding 24 months and they can not transfer it to somebody else within the next 24 months, with the exception obviously of business failure.

They may request and receive a contiguous CIDR block large enough to provide a 12 month supply of IPv4 addresses. And there is a rate limiting in the number of transfers that they can be involved in and that is a six months period, one transfer within that six months.

The address block, minimum allocation size should be considered. It should be coming from either from the blocks that mainly ARIN is managing, and there shouldn't be any dispute over the block, and there are some extra possibilities of size and assignment constraints over the number, how much you can break in the transfer block into.

Now, they are introducing two new concepts in a way quite detailed, as I said, ARIN documentation and the proposal in that sense. They are talking about the prequalification mechanism. This will be available for both transferring and recipient organisations, basically maintaining a listing so that these people who are interested, they can find each other. And then for recordkeeping purposes obviously, the whois registration will be updated after the transfer.

ARIN is keen on keeping the old concepts that address space is not property and it cannot be sold and the distribution is still, should be still based on justified need. Those are my highlights and those are my observations again.

Now, I will move it to APNIC new proposal. The main thing one of the highlights does not require APNIC's prior approval before the transfer as opposed to what we have seen in the ARIN case. And it is, in effect, as soon as it is adopted, so they are not going to ways according to the proposal as it is written, they are not going to wait until the IANA pool exhausts.

Now, again there are conditions on the source, recipient and address space, there is their terminology again but I am sticking to my own terminology here.

Address block: They have a fixed size, a minimum size and that is /24, that is the minimum size for the block to be able to be transferrable. It must be an APNIC administered block and it is obviously subject to APNIC policies, this is stated explicitly in the document.

Transferring organisations should be a good member and cannot receive any blocks from APNIC within 24 months after transfer. So one of the constraints that ARIN is bringing, APNIC is also applying it.

And for the recipient organisation, basically they should be applying the policies over the transferred block that they receive properly other than being a good member.

Now, current state of things: Like I said, these are my observations. I have been in these meetings where these proposals have been discussed, and that was in February and April and what I heard from there, and this is publicly already announced, they will both be revised but within the next, words I am bringing back as from my experience, what I heard from the floor in the ARIN floor, they were they mentioned continuing working on such a relaxed transfer proposal so the concept is going to continue obviously, and justification is an important point. They really made it explicit that they want to retain in their proposal, and IANA depletion time to start with may be changed, maybe towards sooner was considered in their discussions.

Now, in APNIC's case, they decided they will simplify the text and nonpermanent concept of transfers will be added. Now, please hold on. This is the first time I mention nonpermanent, and now I will explain what it is, but it comes with our new transfer policy.

I know Remco, you will present after this, but just for the completeness of the proposal, I picked up the highlights of your proposal here and I listed it on my slide with your permission.

Basically, in RIPE's case, we are talking about the block must be unused so it will, it should be empty, no live network with customers over T the minimum allocation size of today should be considered. All allocation policies must apply, and can be a permanent or nonpermanent basis; I believe you will explain this in your proposal, so I will leave it to him. But no prior approval of the RIPE NCC is required is quite explicitly stated in the proposal or as in the proposal in RIPE region, and recipient, the organisation that receives the transfer cannot transfer within 24 months; that is one restriction.

Now, I believe I have done that quite well, but I know the information is quite coming from all directions. I just created a table of reference. I know it doesn't look very well because it was a complete miscommunication between me, PowerPoint and Excel, but this is the best I could do, I hope it will be helpful. So... was that quite fast and useful? I don't know.

(Applause)

CHAIR: Well, actually that was what I wanted to say. Thank you and give her an applause but the audience feels the same.

Remco, are you around? So we are now going into the specifics of the proposal in the RIPE region. Remco will summarise the key points and then we will have a discussion on that.

REMCO VAN MOOK: In time honoured tradition of pictures saying more than a thousands words, I will mostly illustrate with pictures. So next step for IPv4 moving 32 bit address space after 2010, which is now changing to 2009.

So, this is our reality check. The way things are, the way things will be, and the actual overlay in between. And that might be smaller than you think.

So, future of IPv4? This is a repeat of slide I have done the last time. I have included some extra stuff in there. I have tried to put the proposals that we are looking at today in the time line, so you see where we are with current policy. The proposals and the transfer proposals and perhaps some future wisdom might be very welcome.

None of it is going to save the world, cure the common cold or save us have eventual doom in IPv4. So, we need to get IPv6 all ready and there is no other way around it, but we need to keep the old banker, IPv4 alive for a bit longer.

Recap from last presentation: So, we are moving allocated but unassigned address space only between LIRs within a single RIR, the RIPE region, in this case. It's either going to be temporary or a permanent move or transfer. With temporary, I mean that you give away a block from one LIR to another for a certain period of time, and you can think of that as, instead of selling the house, it's taking out a lease on the house. So, you'll get your address space back in any period of time you care to define or agree with the other LIR.

RIPE NCC to continue to function as a clearing house. So keeping the books. We don't want to get involved in any conditions that the LIRs in between might agree upon. And we are definitely not going to regulate that.

So some new additions, the proposal text has been much improved. We now have two year moratorium on new allocations. That's not just the allocations that have been moved through the transfer policies. We also PA allocated PA space as a two year moratorium on it. So if you are getting your block from RIPE NCC today, you can't trade it, even if the policy gets adopted you have to wait for two years.

We have cleared up the relation with the current certification efforts a bit. We might have been doing that a bit too well, actually referring to policy that's not in place yet. So that might have to be taken out again.

The key points of this proposal: It's a very minimal proposal. It's setting out the barest possible framework for enabling transfers. I think we are in a big hurry to get something like this sorted out before it becomes pointless. Any additions and changes that we come up with later, we can add as we go along. And one of the points is that we want the RIRs to stay relevant for IPv4 even if there is no IANA space to be handed out.

So what are our options? If at first you don't succeed, we run, and I think as far as transfer policies are concerned, this is crunch point. If we go to discuss this for a lot longer, then it would have become pointless. So, I think that we should move this forward now or abandon it altogether. And with that, I'll take your questions.

CHAIR: Thanks for wrapping it up. Something that I think should be kept in mind is that people are doing transfers today. The only thing that's different is this proposal is meant to help the RIPE NCC to keep track on what's going on. Not doing this will not stop people from buying other companies just for the address space.

AUDIENCE: Michael Dillon, BT. Personally I am of the opinion that this is all a waste of time, the transfer stuff, because we are talking about a period in time in which the IP address space is used up, which means that most of it is in use and not available for transfer to anybody, and since we have seen some statistics that largest chunks of the IP address space is, has been allocated to a small number of very large ISPs, whether it's in the RIPE region or ARIN or wherever, that's basically the case. So, not only are these companies that typically are constantly growing the network, and so, therefore, don't have aren't likely to have a supply of free addresses handy to sell or transfer or give away, or return, but even if they did, it would cost so much internally, in internal costs to validate and check and get approvals to release addresses and make sure that the left hand isn't giving away something that the right hand actually needs. That I just don't see that there is going to be a significant number of transfers at all all over.

REMCO VAN MOOK: First off, I don't think that most organisations are as large as BF is so I think that the left hand and the right hand might not apply to I think a lot of stuff I actually think will go through the transfer policy. I don't think we will have ever be seeing any /11s or any space of that kind move through transfer policies, but there is actually quite a few things around in the world, content and enterprises, who would very much like to get their hands on a /20 or anything which will be available somewhere because, when we are increasing use we are also increasing fragmentation to that space will be around. We need to have a mechanism to get at least properly administrated, to see where it goes instead of just sitting on our hands or hiding in the basement.

CHAIR: I have two things. First of all, I have been asked by the scribe please always clearly state your name, because he needs to write it up for the minutes. And then well, formally it's time for the coffee break. I apologise for running over, but I think this is important. So if you can bear with us for ten minutes, I think we should come to some sort of conclusion. Please go ahead.

AUDIENCE: I have a very, very quick point of order and then a quick question. I broadly support the proposal because it allows the community to document and understand the changes that are going to happen anyway. I agree there. Could I please understand the rationale for saying that only PA can move and also the rationale for saying that PA space mustn't have any assignments made within it before it can be moved, and does that also include assignments for your own infrastructure as well as to end users?

REMCO VAN MOOK: Okay. Just to clarify on that last point. The reason why I just put the proposal in for allocated but unassigned PA space because I thought that was the easiest block to address, and with it, I don't mean that we can't include P O or allocated Enda signed address space in later stage, but again I wanted proposal to be as trimmed down as possible. So, yes, I fully agree that we might eventually expand it to other address space as well.

AUDIENCE: Dave Wilson, I take the point Michael makes that it's going to be difficult to free up space and I don't think there is any doubt about that. But as I see it, the vision we have passed any state in the proposals talked about already where we are rearranging the space that has left. The vision that we have for any point [unclear] exhaustion is that organisations need to move to IPv6 and in order to move to IPv6, you still need some IPv4, and we expect I expect at least, that this will take place at different rates in different organisations. So, as far as I can see, unless we do nothing, and I don't support doing nothing, the only option we have is to provide the possibility for some organisations to free up space more quickly and allow other organisation to say use that space until they can complete their own transfer. I see no other kind of proposal, other than yours, Remco, that can get us out of this and get us to that state. And so I support your proposal.

REMCO VAN MOOK: Thank you very much.

AUDIENCE: Tom Best. I am curious if there has been any evaluation of the legal implications of this. Technically, when you take a, something that was being treated as a common pool resource and you transfer it to a private party and you make that transfer, you make that asset alienable, in other words that party can choose the timing and the terms and the identity of the person that gets it after, the word for that it [unclear] privatisation and when you private advertise something it has huge task and regulatory and accounting implications and although this is unambiguous case, there are many ambiguous cases in the real world and in fact there is a very elaborate economic and accounting doctrine called economic substances where lawyers and accountants ignore the form that perhaps that institutions would like to project and just pro can you say on the substance. What I am suggesting is the substance of that is very close to private identification and it probably is something that merits careful review.

One other thing I'd like to point out too in terms of the need to move to v6.

When you when you if you vest the v4 resources with value, and if the value is substantial, it's going to create perverse incentives also I mean, the value of the v4, of the legacy address space will continue to rise forever until a point when the entire universe of Internet resources now gets to be, you know, relatively parity and then smaller than the stuff on v6. But if you are someone who has this resource and you have the means, if you know it's going to be more valuable everyday you wait and in fact if you make your users and your content the very last thing you my great, this may create perverse incentives which will, which could delay migration to v6 for centuries.

REMCO VAN MOOK: Answering your second point first. I think that actually, it will be a huge incentive for v6 to evolve and to answer, and the other point you are raising, I think that the entire v4 legacy address page will eventually be worthless because everything has moved to IPv6. Now, that might be a while, but I think that if v6 is the freely available resource and v4 comes at a very significant price and is hard to get at, then you'll see an automatic migration. Actually, it might finally make the business case for adopting IPv6 within various organisations. And then coming to your first point about privatisation, yes, I fully agree that there is a legal and economic aspect there, but I don't think that that is anything we can do about. So, whether we adopt a framework to do transfers or not is beside the point, because people are doing transfers and if enough people are doing transfers, it's also a standard. It's a de facto standard and your accounting and your legal team will adopt it by legal standards, and your [unclear] authority will probably also say okay, people are apparently making a bulk out of this, even though it's officially not allowed so we are going to tax it anyway. I mean, you can get tax, you can get taxes on illegal arms trade so why not on illegal v4 trade.

AUDIENCE: Just a quick question. Something James Rice: I wonder have you carefully considered the effect of using the minimum transfer size being today's allocation size rather than the allocation size for the /8 transfer addresses are coming from. Because you are effectively possibly fragmenting the allocations from blocks up to eight times as much as they are currently today. So for instance, two on two slash eight is a minimum allocation side of /19. Are you definitely sure you want to allow transfers of, in sizes of /22 rather than /19s in that block.

REMCO VAN MOOK: There has been some thoughts on that and I think that by increasing the user of a resource, you also increase fragmentation eventually, so we could stick with the minimal allocation size for that /8 and there has been some thinking about that, but eventually I don't think it's going to make any difference and I'd rather keep it clean and simple and have a single number rather than have a separate allocation size for each /8 that might be transferred. So that's the reasoning behind it.

AUDIENCE: During the last RIPE meeting you represented a set of principles regarding pour there is a follow up, we worked again on this issue and we have a new common position which on paper, and on IPv6 exhaustion was on the IP policy mailing list. I think that before going that way, before assisting a process to transfers, we have to carefully consider the impact of such a move, I think we will create a market and we will have a lot of implication. I propose to this position paper from ETNO and clearly we are not in a position to support this proposal and the reasons are clearly explained in that position paper in the RIPE policy mailing list.

REMCO VAN MOOK: Thank you for that comment. Actually, I think that it's a widely spread fiction that this proposal is actually creating the market. The market is there. We are just going to document it and we are going so say, okay, no more of the illegal stuff.

AUDIENCE: Will we see this market and we have to consider the impact of that move, it's already called change, I think

REMCO VAN MOOK: I agree.

AUDIENCE: We have to carefully consider all impacts and read the ETNO position, we tried to analyse those impacts and think about it.

REMCO VAN MOOK: If and I fully agree that if we had two more years to fully analyse whatever aspects we need, and what we need to address, we should do that. But the case in point is that we don't have two years left. Actually I don't think that if we don't start working on the implementation of this very, very soon it's going to be pointless anyway. That's why I was also suggesting in my presentation that I'll remove it or are we going to abandon it.

CHAIR: Okay. Daniel.

Daniel: I'd like to come back to the end of the Filiz's presentation, just to make sure that we really understand what we are doing here.

It is Tom has pointed out that you know, if we privatise these resources, it has interesting consequences and just to bring this out a little bit more clearly than he has said it. In my actually it might actually increase those perverse incentives. You know, if I am a big sill right now, I have got lots of IPv4 resources, it actually, in my opinion, will prevent me from going to IPv4 if these things are sort of just a common resource.

The other thing is, if you look at ARIN, APNIC, just look at the differences there, I think one might look at this and say, hey, it's ARIN again in their tradition over specifying everything and being amateur regulators as some people have said before in this meeting, but what they are really trying to do to my mind is to maintain the address space as a public resource, and quite forcefully say, you know, cannot transfer it unless the need has been demonstrated beforehand. Whereas, our proposal and APNIC say, you can transfer it, the registry will register the transfer, and then have, in both instances, a one sentence thing in there which says the usual policies apply. Now, imagine the following case: There is actually a transfer happening where the transferee doesn't have a demonstrated knee. So what has happened is that a commercial transaction has taken place, it says I sell you this address space, excuse me for swearing in church, do you think that the RIR has a chance to go after them and say, hey, you know, you only need half of this, we'll take the other half back, after the commercial transaction has actually happened? I think this is maintaining a fiction and then if we do this, and we shouldn't maintain the fiction. We should say outright we are privatising, because otherwise it brings the RIR into a untenable position. Because they would have to actually enforce the policy, they would have to actually look at the need and then undo a commercial transaction that has already happened. I don't think that's realistic. So, what's happening here we can do that, we can go with this proposal and say, this is just window dressing, but what we should realise that it's just window dressing. We are privatising this resource and I am not going one way or the other. I am not saying one or the other is better. We should just be honest with ourselves that the sentence in there that says the policies, the existing policies do apply, you have to really have a demonstrated need for those resources. That's window dressing. It's not realistic. And we should be aware of that.

CHAIR: Okay. Last comment from Roque and then wrap up.

AUDIENCE: I don't have a comment on the policy but I have been requested to transmit the view of the LACNIC board of directors that states that any policy involving the transfer of legacy resources, should be discussed between all LIR communities in a global basis. Thank you.

CHAIR: Okay. Thanks for that. Do you want to wrap it up or

REMCO VAN MOOK: No, can I ask you to have a vote to see what people think.

CHAIR: I am not going to ask the stupid proposal question, because I have been told that this is not a way to run the show. Who, in the room thinks that we should go, move this on pretty much unchanged without lots of further discussions and reiterations and changing and delaying it for two more years, but should really press this on quickly? Please a show of hands.

Okay.

Who thinks that we should abandon it because it's not serving a useful purpose and, well, not going into the right direction anyway?

Okay. I have seen a few hands but it's more hands for going ahead, and I assume that the rest is, we don't have any strong opinion on this. So... I suggest to, well, go into another round of discussion on the mailing list, a quick one, as little as the PDP permits. We cannot declare consensus anyway. We need to have, to follow the proper phases on the mailing list and

REMCO VAN MOOK: I agree with following the PDP process but better hurry.

CHAIR: Okay.

AUDIENCE: One short comment: We should listen to our LACNIC colleague and I think you might want to ask the question who thinks it's important that actually the regional policies are better aligned than they are right now and to give a to ask the appropriate parts of the policy development process is in the different regions align themselves and maybe give it a deadline so quickly, but you know, so that you would talk to the ARIN, to the AC and so on or ask the RIR management's or whatever to at least you know, start the process to see whether it can be done.

CHAIR: Okay, who in the room thinks that it's important to align that across the regions and to really investigate in that direction? Okay. I am not really sure how to tackle that, so I would like to put an action item on the NCC to I am always happy to get insight from the wise folks. The action item on the NCC would be to, well, keep track on what's going on in the other regions and figure out whether it's possible to align this stuff and if yes, help us do it.

AUDIENCE: I am speaking as a member of the Address Council now and there is some work in starting to do some coordination there, in particular looking at the form for approval of proposal policies in all the regions and trying to make a proposal to align that. That's a a very first step into looking at something in all the regions and proposing it to be more coordinated. Of course that could be taken through the policy development process as well particularly for global policies, which is our concern, but it could also be taken further to policies. I'm not saying that the Address Council should do this work on its own but at least we have started something there and since you have brought it up here, I can take that feedback back to the Address Council and say that there is at least interest in the RIPE region that we get this done and maybe do more in this area.

CHAIR: Thanks for this information. And please, keep us informed.

Thank you all for your patient. We have seriously overrun, but I think it was important to really have time to discuss this and well thanks for good and valuable input and see you again in Dubai and on the mailing list of course.

(Applause)

(Coffee break)