These are unedited transcripts and may contain errors.

---

The Address Policy session commenced at 2 p.m. on the 8th of October, 2009, as follows:

GERT DORING: Welcome back to the Address Policy Working Group. I am happy to see so many of you here with conflicting Working Groups, hallway talks and everything going on in parallel.

We have quite as long list of things to discuss and I think this is going to be an exciting Working Group. This is the agenda for this 90 minute slot. First thing will be a presentation on well IP usage in not typical ISP customer environments and subsequently different needs for addressing and this is basically to extend our horizon and maybe point out some of the problems that might show up.

Then we have temporary, well, a new policy proposal that might become a regular one, depending on feedback, about temporary assignments after the v4 run out which is currently pretty much not covered by the policies. Then we will get back to what I had to skip yesterday, the open policy proposal discussion about 2009?01 which is the global policy for IPv4 address blocks being given back to ICANN, IANA and then redistributed. After that, I want to discuss what ideas you might have about the areas covered by Alex's presentation yesterday about, well, things that take lots of time in the registration services due to maybe not very clear interpretation of the policy or maybe not perfectly in line policy things. Then we have the open policy where anything can come up that is policy related and we have proposal from Dave Wilson coming up, how to amend our policy process to better cope with global policies that get stuck in other regions, and that is pretty much for this afternoon, and I think we should be able to cover that in time.

So for the first presentation, I welcome Dr. Wellbrink from the German ministry of defence, not in formal clothing today because I told him here in a suit and a tie would be a very bad idea so he is very adaptable.

Dr. Joerg Wellbrink: Thank you for the introduction, ladies and gentlemen, thank you very much for the opportunity to give you some information on what the German armed forces are doing with the Internet protocol version 6 actually on our plans. Bag soldier didn't come alone, I always and ?? somebody yesterday said I am the politician guy, I am not a tech guy, I am not a tech guy, I know a little bit to be a dangerous, because I know there is some tech guys around here, I brought one of our practitioners with me so he can give you more technical details on what we are actually doing and this is Dr. /THAO*PB who is going to have some slides and explain some of the stuff we are talking about. I am with the ministry of defence and working in a branch ?? I am working in a branch that is responsible for modernization andy /SERBly modernization for IT systems so it's kind of fitting that we look into the Internet protocol version 6. The presentation basically is twofold:

The first part is I would like to tell awe little bit what we think about networking issues, why we think Internet protocol version 6 is very important to us, and the second part actually we want to show you a real world example so how are we going to deploy the Internet protocol version 6 and it is also thought that you might see this little difference between a regular ISP and tactical communication systems. So that is basically what we try to cover today.

Just to give you a quick overview, what are we doing these days? We have almost never at home. We are pretty much abroad and here are eleven missions that we are manning right now, and they are totally different in scope and size. So like Afghanistan, the ISOF mission, more than 4,000 soldiers in Afghanistan myself two years ago for four months so pretty much officer every officer has gone at a certain point. This is the biggest mission we have in the motion. Other missions like the one in the lower right corner, UNIFIL, a navy /SPHOEUGS they try to hunt /PAOEUR ats and whatnot, that is a totally different one that you can't compare, so what I try to tell you is every mission has different requirements for the networking purposes.

That is picture to confuse you. We are always playing these games with names, network centric operations. What it really boils down we try too far communication system link all types of networks, censor networks, so censor systems, weapons systems of those, interconnecting them but not only for German armed forces but in multi?national context so it could mean an American sensor is given data to German weapons system, or a non?governmental organisation is putting information into our system so we can see whether the reconstruction effort (sensor) is moving forward or not so it's totally different in size and scope.

The one problem we are having, and I figured yesterday I was introduced something like captain /48, I am not, and I am not stating that every soldier should be assigned with /48, the problem we are facing is this is new ground for us as well so what we need to come up in an international context is, some idea how we are going to configure out networks, so we need to talk to the American folks, we need to the British folks, how they are going to do it. Germany is willing to start this process within NATO and EU, in order to get an idea how are we going to maximise interoperability from the very beginning and that is why there is some initial thoughts, how can we do it, we took a recommendation of IETF, which didn't really work out that well, we have no idea what the Americans really do with their soldiers and so we are going to start this process in order to get it going. However, what we are really happy about is, I didn't get this T?shirt IPv Act Now. That is actually what we want to do, we want to Act Now and start and I think we are in a good way, together with RIPE, to get going, which is what we want.

As I said, we are modernising our forces so what really happens is we basically have two different sets of responsibilities: We have our homeland network, that is contracted out, so we have a contractor doing everything for us to modernise our homeland IT. Of course, we have a contract and we are responsible to provide the address /SPAEURBGS the IPv6 address space so that is our task. Everything else they are going to do and I guess they will work somehow like a normal ISP, and so I am not going to cover that in detail because you do better know than I how they work. But on the other side, on the right?hand side, we talk about our mobile communication system of the German armed forces, so that is actually what I'd like to show awe little more in detail. We have a unique chance with the German armed forces because we are just procuring brand new systems, so the backbone of our system, Dr. Tian is going to talk a little more in about this, is mobile communication system, that is the backbone for our missions, the network backbone. That is brand new, brand new technology, state?of?the?art. We have access networks on the lower left?hand side; CCIS, command control and information systems. We just procured a couple of them, we are in the process of procuring more and they are state of the art technology, we use Cisco routers and whatever are available for us and we can use IPv6 with it. Also, if you look into we are using digital radio, we are, right now, in the phase of developing a software defined radio and so we have a really good chance with very modern hardware to use this new Internet protocol and we are very aware that IPv6 is one key enabler to do network ?? network standard operations and the unique thing that I and my generals, you have a clear identifier or clearly identifiable addresses, which is good. What you can do is automate a lot of configuration processes so you don't have to send well trained administrators into the theatre, and our /WAO*EUF finders don't like to have they call it foot print, they don't like to have administrators around them, they like to have boots on the ground, if we have an argument you don't need a lot of people in theatre because we can do a lot in Germany from there, it's a good argument. So, and the other advantage, clearly, is using IPv6 for mobile communication, mobile networking so that is basically the reasons I can tell to generals and they buy into that.

Let me describe the mobile communication system just on the surface and Dr. /THO*EU is going to cover that in more detail. It's a deployable network solution and for every mission we will use basically this system, no matter where it is. So it consists of hardware, /HOUFL, that we can deploy (obviously) we don't have it in Afghanistan yet but it's going to get there pretty soon, we just procured it and tested it and validated and so we are going to move forward to deploy it. You can see some of the details on here, what is really important to us is we do have a backbone now, and on the slide before you could see the satellite, we just launched our first communication satellite so we are really into it, it's going to take six or eight weeks before it's becoming operational, but we are pretty much independent and within our communication system so we can work with that.

Let me just click through here quickly. How does it look like? First of all the NOC, national operations centre, that is in Germany, that is where we need those well trained administrators, and in theatre, we basically have always four units, two system units, with a backup, a network management unit, one is the mass /SA* and one is the slave (master). We do connect our axis networks which is the next lower level into this backbone, and then below those accessible networks there is basically our deployed weapon systems, soldiers and whatnot so this is the /HAOUPBL structure from top down for you. (Huge).

So some basic requirements, that is certainly different, especially the second part of it. We say we need to be able to do at least eight strategic missions in a theatre of military operations, which means that we have eight times mobile communication systems we should be able to deploy eight times. The centralised management, con /SURPBT management is going to be conducted in Germany in the national operations centre and what we don't want is NAT doing edge or peers, that is very important to us, it seems to be very, very complicated and the doctor can talk in more detail. When you do an exercise with nagses in IPv4 and everybody has the same address it's difficult to do. He talked about double netting, /KWHRAOPB it is, it sounds pretty complicated to me. The special access networks, we cannot really specify how many special access networks we need. It's going to be a number larger than 10, and, you know, this is totally different from what you would perceive. I mean, you pretty much need to know how your network looks like. We don't know beforehand because we have to go into there and then we have to decide about the size and the scale of a mission. We also have varying amount of addressable end devices, it could be router, could be a computer, whatever, so you go up to 4,000 end devices in one network, accessible network. And then, you know, even in future, we have independent sensor networks, could be biometric sensors on a soldier and we do some research in that area. (Biometric) what we always need is fallback position, and so we need some auto key in there just in case. And each access network has to demand its own virtual private network.

Well that was the, let's say, overview, and we come into the technical details and Dr. Tian is going to talk to that.

SPEAKER: First of all, I would like to disclose some technical details. Here, we see a system unit our infrastructure, we see our consists of four routers. That is in four routers in order to have a reliable network infrastructure and due using of identical platform on the interfaces we can say we have a reliable network. Why is it important here? Because we going to speak about size address spaces and we should know that our routers are label H how theers, we have only in KLS network and each must support not only VRF for management but also for voice and data communication because in our units you see that places in our units we have operational staff sitting here in each node, that is not usual in Service Providers sector. In here is small additional information, by default routers A and B connected to other system units and have to keep our links based on satellite and regional link which are moveable too and our routers C and D are facing our access networks. That is physical features of that link.

With reference to address requirements, as already stated here, I would like to show here some very important decision for architecture of ?. First of all, we have, we are using of course BGP for all our missions and, yes, we would prefer to use BGP for connectivity not only too peering networks other nations but also to our own access networks. That is many services. What we have now, now we have as mentioned, 10.address range. We are using that in current missions. Yes, we have real challenge for multi?nationals missions. And frankly speaking, we don't ?? we do want different situation in case of v6, we don't need net. It is really, really important to state as with the same address range we have to use double nothing con /SO*L. For current release of ? we have some kind of one to one translation, I called it one?on?one translation. We have some policy. I think that is self?explanatory here, the information. Just some comments /PHO*D con suss does not have. Any v6 only links use only static addresses, just for information.

Maybe the most important information in this presentation, we are not sure this is the best way, best format to present the information but I hope at least the compact one. And we have the left pyramid here show the address ranges we are using to support all levels of ? in a mission. We have green ? with all our missions, we have one mission and we have connected access networks to. It is very important to stress here /PHO*D /KO*PL /SEUS is not pure service provider network, this is some kind of mixing of service provider network and due to own staph that service provider and the customer network in ?? customer network at the same time. This is clear enough that ? German army has a mission without mod /KO*PB cyst and will have missions without. That means we will lost the hierarchy we are up shift in our hierarchy. We have for all deployable and mobile access networks we have a concept that is allow that each part could be ought /TPHOPLically involved in each mission. As should be logical. Yes, of course. This mean if wave backbone provided by a partner, we should be able to connect to the backbone. What is important here, what is not usual in civilian sector: Our prepared network infrastructure from access network must be combat ready. Okay. This mean the access network get a prefix, it's not the same, just from concept here but infrastructure is not changeable, no change is accepted, it's combat ready. That mean, of course, we have a ?? we have discussed today that we have maybe problem with utilisation but I think it's another problem, and here, without /KO*PL /SEUS that we have different addressable methods.

Last slide for our presentation I would like to show you some example based on this is a German acronym of deployable access network and the administration of /PHO*D /KO*PB will put full responsibility for a block here, 48 block to administration of one ?. Again accessible networks. This mean the administration of access network is able or will be able to break network in small, layer 3 segments and that is the current concept for current version, under our current access networks have a lot of ? devices. As mentioned before, we can expect here till 4,000 edge devices and maybe more information here, why we do need that segmentitation. We have different security ? in access network, we have different security demands and per default if we have all security implemented in access network we have at least 6 security layer 3 networks, 6 NATO and German, different levels of security demands. And moreover, we have different small sensor networks connected to the access network. Again, we see clear demand for a huge moveable address ranges in this particular situation. Okay. I think that is the last one.

Dr. Wellbrink: Just to summarise what we have been discussing. First of all I want today show you we are really into the business of networking and that is a certain pressure to us to get going because we have this new equipment and it's already deployed, so Dr. Tian an showed you what we are doing right one, is one example how we are going to use our Address Policy and we have to do it now, which is, what he presented to you, so hopefully you get the picture, we are a little different, especially in our mobile communication systems to what you would expect from a normal ISP and I would be more than happy to take questions, comments and tips, hints. Thank you.

GERT DORING: Yes, thank you for the presentation. I think it was useful exercise to look over the horizon to not typical ISP networks. I already see at least one question coming up.

AUDIENCE SPEAKER: Hughes. Just out of curiosity, you are in the unique position to have being a rather closed network, to jump straight from v4 to v6 only. Why bother with the dual stack and the double NATTing if you are going to make this leap as an upgrade you could go straight to 6?

Dr. Wellbrink: Good question. First of all, as I showed you, we have two different sides, one in Germany, homeland and we certainly have to deal with IPv4 in Germany for a while. During deployment we really need to explore whether it's going to be possible to use IPv6 only because we need the applications to come along too, and our applications are a little older so the hardware is brand new but the applications are not so we are in the process of researching whether they are IPv6 capable or enabled or not so this is going to take a while because the software was developed for IPv4 and one of our problems obviously is that they even hard coded IPv4 addresses in there so it's going to take sometime to figure that one out.

AUDIENCE SPEAKER: One more. I am not sure if you can tell us or not, your architecture looks interest, are you making routing decisions in the air or up and down on making decisions on the ground. Are you making routing decisions in the sky or point to point or up on the ground in making decisions on the ground.

SPEAKER: We wish we could do that but can't right now. We are in the process of researching that but will not be able to do it right now.

AUDIENCE SPEAKER: Thanks.

AUDIENCE SPEAKER: From Slovenia. I did not quite well understand what is the unit. You allocated /48 to a unit. Is this a soldier or what?

Dr. Wellbrink: Well, it's an end site is of course but to be honest, we discussed it, a soldier could be an end site in a certain scenario. Like we have group of infantry soldiers that have is a lot of networks with them. If they are dismounted and in a certain distance to their closest access point we only have one guy who really connects to the network so he is going to be ?? he is going to use software defined radio and it's not even a radio any more; it is a node that can communicate, a network node that can communicate so in this particular case I would claim that this soldier is a side at that point.

AUDIENCE SPEAKER: Okay. Thank you.

GERT DORING: I don't see any other questions coming up so far. Thank you, again, for coming up and explaining to us...

(Applause).

GERT DORING: Since you complained that you didn't get a T?shirt, sander actually managed to grab one, it was reserved for somebody who acquired his own in other ways.

(Applause)

We only got money the remaining are all size M and I don't think...

So next point on the agenda is actually /H*EUBG who is staring at his screen and all of a sudden has to wake up. I know that he will be ready, anyway. So this is about a new policy ?? a new idea that might end up being a policy proposal. If you as the community think that this is a useful exercise. I think I have seen the presentation on this one.

NICK HILLIARD: Thank you very much. Nick Hilliard head of operations at INEX, again, it seems. Right, so we have this thing about like IPv4 and it's not kind of going away, been mentioned before a few times. We need to take a responsible attitude towards this. I recommend panic, it's always good option. Something about 16?bit ASNs as well, I think Geoff mentioned this in 2012. I don't know. Any, they are on the way out as well. They are interesting, have slightly different characteristics to 32?bit ASNs, not quite the same and once they are gone they are gone, they are not coming back.

And we sort of know this with our heads that, you know, they are going I don't think we are really sort of acknowledging with our hearts you know what this kind of means and what is going to happen because a lot of the ideas that we are coming up with on the Address Policy Working Group are, I don't know, I just don't see them as necessarily making a lasting impression on or make ago good long?term impression on the Internet.

Lasting longer, making the pool lasting longer, maybe it isn't even a good thing. There is one theory that says hey let's all run out now because there is going to be less deployed kit than in 2012 or whenever it is and therefore it's easier now, it's a theory.

But you see we have a basic problem, and that is that we' sign IP addresses on of indefinite duration. And this is why addresses are running out so fast. We are not getting them back at all. So what I would like to present is this idea where we have an assignment policy based on finite duration or a fixed duration. This is the reduced, reuse, recycle, it's very fashionable in many circles at the moment and I think it's very applicable to address IPv4 and ASNs as well because we can reassign them and get them back after a period of a week or six months or whatever and reused again and again and, you know, they are simply not going to run out. And typically, things like conferences, you know, I mean we want to have IP addresses for conferences and like the cc C and RIPE conferences and stuff like that because otherwise the supply is going to dry up. This is the sort of assignment policy we have today it, it's really nice, you know, sun is shining and we are all going out for a swim and snorkeling around but in a couple of years it's going to be kind of more like this. Which is not so good, I think. So how do we make this work in practice? Well, we have got define a couple of principles here. We have to reserve some numbers, somehow or another. I don't think there is necessarily any good reason to limit the NCC to just IPv4 or IPv6 space, in a policy we should say there should be some ability just to reserve some space and maybe if they want to reserve some IPv6 and ASN 32 space well that is okay too. The critical thing of course is the assignment for fixed time period only. We have to do a few things like changing the address plan requirements because at the moment the address plan requirements state you have to have X percent usage immediately, where immediately is defined as I don't know sort of one month or something like that and then you know sort of Y percent in one year's time typically 50%, obviously if you are going to request a sort of a, I don't know, a /16 for, you know, for just a week, you know, that is not ?? that is not going to be a reasonable requirement to have. We should probably think about defining a couple of categories here, experimental research, conferences, time limited conferences, product testing. There is going to be a bit of an issue of abuse, obviously if this IP addresses or ASNs are passing from person to person or from organisation or end user to end user, and one of them somewhere along the way says look, we are just going to like Spam like crazy for a few days, you know, that is obviously going to pollute the address space moderately badly and recovering from polluted address space can be quite a nasty project.

There are a couple of policy problems. You know do we deal with PI assignment only or does some form of allocation mechanism make sense. I am not sure if an allocation system makes sense. It seems to me maybe direct assignment would be the only way of reasonably doing this. I am not an IANA or ICANN person so I don't really know if there is any sort of terms and conditions in the IANA to RIPE NCC delegation system that would prohibit this sort of behaviour. And there is also some regulatory stuff, in particular I presume at this stage everybody has thoroughly read Nigel's legal comment e?mailed to the Address Policy Working Group. Has anybody here not read it completely? Okay. So you have all read it. Very good. So section 45 here "it could be argued that the RIPE NCC competes with the LIRs when it comes to PI address space... ?? additionally RIPE NCC does not same to reserve some... a/SAOUPLTS. And that worries me a little bit. Now, I am not a lawyer or anything like that but, you know, and there are certain ways around this. I mean maybe it's not going to be the RIPE NCC isn't going to be competing because this is sorted of a temporary assignment only and rather than sort of assignment by fixed duration, I mean who knows. Anyway, this has to be left to the legal ones to sort out, and I am sure the RIPE NCC board will be getting their legal counsel to take a look at this.

So yes, we have ?? we could have some legal consequences but I am not a lawyer so I am not going to speculate any further.

There are a few technical problems. The first is address space poisoning. I guess, you know, we are just going to have to resign ourselves that if some sort of policy like this is going to come into play that address space poisoning is going to be a fact of life. There is no way of getting around it and I don't think there is anything that can be done.

What happens when the end user at the end of their assignment period doesn't stop announcing their, their block or their ASN. Well, I mean it's less of a problem if ASN. It's quite a serious problem if it's an IPv4 address block. That needs to be dealt with rather carefully, perhaps with liaison or by liaison with the intermediate LIR if it's going to be organised by an LIR. There is going to have to be a warranty period as well, you can't take back a block of IP address space sort of on day 10 and then on day 11 assign it to somebody else because particularly because of this advertisement problem. And there are probably to quote some of the illustrious world leader, other unknown unknowns which I haven't really thought about. So discussion and questions?

AUDIENCE SPEAKER: Hello.

GERT DORING: Thanks for bringing this up and I think this is first comment already from Jabber.

AUDIENCE SPEAKER: Yes, from RIPE NCC I have a comment from LANs Wright, his question is what about countries who don't necessarily follow these policies and encourage such usage as Spam, another follow?up to that but maybe you want to answer that first?

NICK HILLIARD: That is kind of a difficult question to deal with because it's not the countries that sort of don't agree with the policies but the people that don't agree with the policies. I mean, this is going to be done on the basis of contractual assignment, there will be legal agreements in place, whether RIPE can enforce those is a different issue that I have talked about a little bit but I mean essentially, regardless of whether RIPE assigns or does not assign a block of address space to an end user, there is nothing stopping that end user from playing Harry with those announcements anyway. They can just assign the address space. It may not be accepted anywhere but, you know, abuse happens.

AUDIENCE SPEAKER: Okay. And I have a follow?up comment: And his comment is let's say an IP application is made for some reason but it is used for Spam, either knowingly or unknowingly, then the address space becomes ?, how does that affect future usage of that address space when someone else receives it.

NICK HILLIARD: This isn't a hypothetical, this is a realistic sort of going to happen sort of thing. RIPE and RIPE NCC can't prohibit it or stop it in any way from happening, and ultimately, any IP address space that is handed back, you know, documents a certain extent tainted with its previous users' bad habits. Some ?? I mean, IP address lists black lists happen, you know, maybe it would be possible for the RIPE NCC to you know sort of announce this as a sort of special use block of address space and ASNs or something like that and try not to filter them too much but I don't see you know sort of the average enterprise user taking too much notice that have sort of thing. In other words, it's a problem, we know about it from the outset but the question you really need to ask yourself is, well, look, would it be better to have this pool of address space and know that there is going to be problems with it, assigning it in the future, so we do simply say, well, forget it, we are just not going to bother. I think the former will be a much more useful position to take.

GERT DORING: Well, I think that was pretty much what I want today comment on, on that, the question is not is this address space perfectly useable or maybe slightly tainted but the question is more like. S some sort of space available or nothing at all? So even if it might not smell nice, it might be more useful than having no space at all. So any other comments from the room?

AUDIENCE SPEAKER: Hughes, I am pretty sure in the ARIN region what they do is hold it for a while to try and clean it up over time, and obviously this problem becomes more of an issue as we run out but we are all going to have to deal with this at some point and every region as time becomes shotter and space less available, so reclaimed space dirty or not is better than not having any at all.

NICK HILLIARD: Yes, very much. And as I said, there is very little that RIPE can do to get blocks like this delisted from you know sort of Joe average enterprise or public service block list. It's a fact of life. So we think this is a good idea?

GERT DORING: That is basically what I wanted to ask. Don't take away all my comments and questions. Could I just have a round of nodding or shaking heads if you think this is a way that we should pursue or that we completely should abandon it? Nodding means going forward with something like that on the list of course; making your hands means abandoning it right away. I see one person shaking his head and nobody else making any movement.

NICK HILLIARD: Consensus by aclaim, excellent.

GERT DORING: I can't really make direction out that have. So I would suggest adding to the list

NICK HILLIARD: We will take it to the list and go through the regular PDP process and ignore Stacey's comment that it ought to be adopted immediately. Okay. Good.

GERT DORING: Thank you very much.

(Applause)

GERT DORING: The next on our agenda for today is catching up what we missed yesterday, that is 2009?01, that is the policy proposal regarding returning of address space to ICANN, ways bit con proversion because it's supposed to be a global policy and part of the global community not playing the same thing. So Axel has volunteered to explain a bit what is happening and then we try to figure out how the RIPE community is going to handle this and move forward. Thanks.

AXEL PAWLIK: I am Axel, I happen to be one of the authors of the original here. Global policy is always interesting, all regions have to decide on one text and then it's moved on into ICANN and ratified by the ICANN board at some time. We need one text for this. And I quickly want to go through the various versions and well, we will probably hear what happened.

Now, this policy is meant to enable a new registry at IANA, a registry for returned address space that we have reclaimed as the RIRs possibly in future. If that is sizable blocks bigger than /24s, the idea is to move them back into IANA and have IANA at some point in time under some scheme reallocate them to the RIRs. Now, the original text basically says in our region here, that each RIR through respective strategies and policies may recover address space which is under our administration and each shall at quarter intervals return return any returned address space to IANA of aggregated blocks of /24s or larger. That is that text.

We took this text from a slightly edited ARIN version, because at the time we saw that was edited already so this is what we want to discuss here so firstly did the process of one identical text version. What happened then is something that I haven't seen but the text got changed in the ?? over there, and John is going to explain what happened precisely. Now, what we have in the new ARIN version is that every RIR may recover address space which is under the administration as before, and then may designate any such space for return to the IANA and ?? right. That space then such designated space will be returned to IANA, shall be returned, and that is it.

Our version looks quite similar. The new thing is really the designate. What that basically means is that in the ARIN version return to ?? designation of such space for return to IANA is optional, so in fact, return to IANA is optional. Our version says once we have the space we will return it to IANA. Small difference.

Where we are with this, with the exception of ARIN, all other RIRs have more or less converged on the current RIPE version. What do we do with this? And then how and all that. I have by now through gentle explanation from My Friend John, understood more or less why this happened, but what happened, John?

JOHN CURRAN: ARIN president and CEO. So recognise that the process over in the ARIN region, we have an Advisory Council and that Advisory Council is charged with making what it sees as good policy, and sometimes that means estimating what is good policy and what the community will endorse as good policy, so at the last RIPE meeting you took something that was in flux and hadn't been at a member meeting, and brought it here. At the end of the day, it turned out what was going to go in front of the members and in fact, in ARIN will go in front of the members just two weeks from now, is the different version that you see, so trying to keep these in sync is difficult and the fact of the matter is that we didn't know what the membership would take. Part of the aspect that causes the material difference between the proposals, is probably the staff comments. This policy proposal on the ARIN region is designated 2009?03 and if you want to run over to the ARIN website and look at policy and look at 2009?03 and then look at staff comments, you will find staff comments include staff and council, and as there is four or five paragraphs that discuss some of the implications of a policy in the ARIN region that mandate the return of the space to the IANA under all circumstances, effectively unless there is an overwhelming mandate from the community for that to happen, we would be in a situation where, quite frankly, the people who become aware of this policy two years from now when they are running out of address space and find out for the last two years we have been doing those returns, might actually say that we weren't involved enough or considered them enough, so there is significant liability for ARIN if we have such a policy that manditorily designates the returns of the space to IANA, to the point where ARIN's council has advised against us and the board of trustees has to take that into consideration. I am not saying that we won't go in front of the community in two weeks. The ARIN community could stand up and say this is the right thing to do, it's what is good for the community and if the board can see that and feel that we are sufficiently strong in the support, we may move in the direction of a RIPE version. If that doesn't happen, though, the version is the one that we believe we can get through with a nominal amount of community support so that is why you see the difference here and it's a fairly important issue, so I want people to understand why the two versions got out of sync, because we hadn't yet got on to member meeting and secondly why it is the one that ARIN is currently considering is more modest in what it suggests for return of address space.

AXEL PAWLIK: Thank you, John.

NIGEL TITLEY: One of the authors of the global policy. The problem is that it's just not two versions, it's five versions, and we have substantial agreement in four regions for the one version and then we have no agreement in the ARIN region. Now, the problem is that if ARIN doesn't accept the global policy then basically the whole thing is down the drain and so it have seemed to me to be sensible for ARIN to at least attempt to get this in front of their community rather than changing it before even presenting it to their community because if it fails to be passed by the community, the entire global policy goes. That is just my point.

AXEL PAWLIK: Of course we could also then readopt the new ARIN version and get that through all the various policy processes, it will take a couple of years.

NIGEL TITLEY: It would take a couple of years to go around to all the LIRs, change the must to may and quite frankly, at that point, we are going to be beyond run out anyway so we might as well not bother.

/RAO*UPLy: Another question on Jabber from LANs write. As a takes a while to acquire IP space why would anyone be interested or motivated to return the space? Thank you.

AXEL PAWLIK: Good citizenship.

AUDIENCE SPEAKER: This is Rajoul from LACNIC, also one of the authors of these proposal. I would like to say something that goes in the direction of this question: This is not a proposal for promoting the recovering of IP addresses, that is not the objective of the proposal. The proposal is that the ?? the objective is that if addresss are recovered by the LIRs so those addresses should be available for all the regions. As all of us know that in some regions, before the existence of the RIRs had been allocated large amount of addresses, if those addresses become available at some point only within given regions, in which I personally think that the RIRs have no authority over those addresses because they were located but the existence of the LIRs so it will create a situation in which in some regions there will be IP addresses for fulfilling the expectations of needs of the ISPs for a long time, for a while in other regions there are the RIRs run out before.

So, this is also a proposal that I think that ? the expectations of many others, including governments, that are very concerned because that in equity in the allocation of IP addresses in the early time of Internet, so the message that we are giving to the community, it's important: The message is: If the addresses are recovered by the RIR they will be available for everybody, but it is not for promoting, if the addresss are not recovered in fact it is better because we will have more certainty in the predictions of the end of IPv4 and so we ?? there will be more motivations for moving to IPv6 sooner. Thank you.

JOHN CURRAN: I would like to respond to one little point, just to be clear; I was also in the room when this was drafted, though my name does not appear on it. Quite aware of the motivation. And Rajoul said when the address space is recovered it will be available to everyone. That is not what the global policy says and that is where the departure from our past practice creates a difference that is very material and makes it look like we might be causing harm to parties here. In particular, our prior address assignment regime in all reasonsence is RFC 2050 needs based assignment policy, which says space is returned to IANA or space that IANA has goes out to RIRs based on need and is issued out to LIRs and RIRs to need to end users and/or organisations. Now, if what the policy said is recovered address space goes back to the IANA to be issued in the same way that it's been done all these years, that is actually not a material change to how we have been doing our policy, it's still needs based and that actually if we were all using fine enough allocation and assignment policies, would actually result in, if we all signed every one, a month's worth of address space and two weeks' worth, we would run out globally all at the same time. What this global policy says is we are going to depart from the process of needs based allocation and we are going to assign recovered space evenly between the RIRs. Okay, now evenly means even sized division which effectively means that the space that is recovered will be available in some regions in excess of need and in some regions if you happen to be using more address space, you actually won't have address space because the recovered space will have been reallocated through this process to regions that don't yet have the need. So by this policy, you are effectively in some regions causing depletion prior to when it would have occurred under our current regime. It's that change being made which is a departure from RFC 2050 which is our global policy for allocation, being done in a process that is much abbreviate, which is going to cause a lot of discussion in the ARIN region, because to do that without knowing the implications for the ?? all the businesses in all the regions that will be impacted by this, is going to create liability on many of the RIRs and many of the NIRs or downstream allocations authorities, so it's not to make addresses available, that is what need?based assignment does; it's to make addresses unavailable, which is causing the difficulty in the policy.

AXEL PAWLIK: Point of clarification, can I make? I see some heads shaking in panic. Maybe not panic. This policy is in both versions, ARIN or any others, is needs?based. The address space will get allocated from IANA to the RIRs based on need. What you are saying is that not all of the RIRs regions further down the chain will at some point in time do needs basedal case which is a problem. John Curran: Yes, the fact that it goes to the IANA and then is allocated on the IANA needs based does not matter if many of the regions don't follow a needs based policy. For example open transfer policy that doesn't reflect addresses assigned or any other departure.

AXEL PAWLIK: Understand.

GERT DORING: Two more comments, Wilfried Rajoul and then I am wrapping up.

WILFRIED: For a while wearing the Address Council hat. I would like to point out here that part of the problem that we are in right now is related to the process of coming up with a global policy and the ?? and in particular, I have lived through a similar situation many years ago when we tried to come up with I think it was called globally coordinated policy for IPv6 stuff. The problem we are in is mostly due to the fact that in some regions there was obviously a very strong feeling that a particular version of this proposal should get consensus pretty early. I can understand where this sort of motivation was coming from, but I am disappointed that although some of us pointed out to those parties that this is going to make us, to put us into problems, there was still the consensus to go ahead with this version although that community was aware that there is pretty much different version, at least probably being adopted in at least one or two regions, so I think what actually is happening, that some parties were trying to ? two different things into one proposal and the first thing being wired is a formalism to come up with a global policy to allow the IANA to receive address space, which is returned, and to redistribute that under a globally whatever regime to the RIRs. I think it would have been very, very easy and simple to get agreement on such a policy. The second line here is actually that there was a strong feeling, and this is not shared by all the regions in the same way, that this same global policy should also be useable as a tool and as a mechanism to redistribute address space amongst the region, to alleviate things which are perceived as not being just or being evenly due to history and I think this is actually the situation we are in at the moment. And I just want to make everyone here in this room, plus all our friends and colleagues from other regions, make aware of the fact that while it is easy to understand why some regions wants to push ahead, it's maybe getting into a big risk of sinking the whole ship.

AUDIENCE SPEAKER: First point is that as Axel pointed out before, this is a needs based policy and it is exactly maintaining the main characteristics of the current system because we received addresses from IANA based on our needs independently of the policies that we apply in our region to our ISPs. So it is exactly the same situation, and I don't think that the policies that we use for allocate in the addresses to the ISPs in every region will not change very much, at least will change in a similar way in every region, but this is just maintaining the same characteristics of the current system, the difference is that currently, the IANA manage only a /8, by this proposal they will be able to manage a smaller unit for allocating to RIRs. In fact, I anticipate that because it is based on needs, the most probably is that, for example, like migration will not qualify in the beginning of this pool or request addresses from IANA from the secondary pool so the most probably is that probably ARIN region and RIPE NCC region will be those that will go first to the secondary pool to get addresses. Originally, this proposal was only produced on legacy space but, later, because some of the authors proposed it to include also any recovery, it was accepted that, but the ?? the reason that is behind that is that in IANA region more than four IPv6 addresses per Internet user. In RIPE NCC region less than 2 while APNIC region less than one. We have ?? has been accused for inequity in the distribution, we have also say ?? we said that we were not responsible of that in equity because since the since the RIR system exist the solution has been based on needs and so the behaviour that have situation has been very different. So in order to go ahead with that assertion that we have made during many years is that we are promoting this proposal. So those addresses that were allocated for any reason before the existence LIRs that cause this inequity, will be in case of being recovered, as it will be available for every region. That is the main idea.

Regarding the ?? what Wilfried said very quickly: When we discussed the global policy for the distribution of the last /8s, there were three different versions of the policy that were approved in different regions but the concept was the same, the principle was the same so there was no problem later in order to get a common version, the authors worked together, so it doesn't matter in some regions the policy was adopted very fast and in other regions it took more time but if the concept is the same, so there will not be any problem to have a common version in the future. Thank you.

(Applause)

GERT DORING: I originally said that we will cut line after Rajoul so please two very short comments and sorry John we are already at minus two then and we are ten minutes over.

KURTIS LINDQVIST: We seem to be making policy based on discussion based on other RIRs and I don't like that. I must be very thick because I don't see the point with the new wording actually gives to this proposal at all. Because if we are ?? what it says if any of the RIRs based on their policies has decided in that region, in the future, feels that they should recover address space they are free to hand it back to IANA and IANA will hand it back to based on need to any of the other RIR regions, and what that need is again decide by each of the RIR regions. This policy basically means if we feel like giving space away we can do so. That may be fine. But it's not making anything of the address distribution fairer or things more certain recovering address space ever. I don't actually see, if we do this change and don't couple this with a future much more closely measure forespace of how we're going to measure need, then it's pointless.

GERT DORING: Thanks.

AUDIENCE SPEAKER: Yes, I have two comments, I will try to race through them. The first one LANs write: How do people feel about charging for space on the monthly or quartering basis if there is no requirement people might be inclined to return the space, where pay fee based on predetermined blocks and the amounts are returned when space is returned. So that is the first comment. I will do the other one. It also makes the admin of the addresss from RIPE's point of view more complicated and thus higher membership fees.

GERT DORING: Thanks for these. It's not easy to find proper words to wrap this discussion up. Well, we are seriously running out of time. But actually I think everything has been said that needed saying and positions have been made very clear. As a Working Group chair I am not entitled to have an opinion on this so I am not having any. As a matter of procedure, my suggestion would be to stall this proposal until ARIN decides on something. If they decide on something, if they decide on the may variant we just ditch it because there is no point on achieving consensus on something that is not going to be global. If they go for the one that the other RIRs have, we continue our process. I think everything else is just not going to work, just from the formal point of view, and so I am staying away from the content discussion.

I don't see anybody jumping up and down and saying I cannot do it that way, so I am going to do it that way. Axel, thanks for bringing this up. And thanks for the explanations from the room and comments about it.

Is Dave Wilson around? I originally planned to have you just before the coffee break and I think that just before the coffee break will be very late in the coffee break now so I am mixing things again so I would like to have your ideas up on stage.

Given the problem we have with our policy process and global policies, we sometimes are in a situation where we have consensus on something which is then not going to work out because other regions have decided differently and Dave has an idea how to modify our process to more easily handle this.

DAVE WILSON: Let me be open and transparent about this, this was inspired by the discussions about the policy we just had. It will I think will not affect it, it's not a change we need to make in this region for that policy because we know how we are going to deal with that but to explain where I am coming from. This is the policy development process as we currently implement it, there are several stages and at any stage before the last, so up to the final call, the authors may at their discretion bring the policy back to a previous state, and we repeat this of course until consensus is reached. There is one funny state, it becomes clear, in the specific case of a global policy, a global policy as you heard needs to have the same broad wording in each of the regions in order for it to be implemented not by the individual regional registry but by the IANA. And there is a couple of different ways out of this I think: One, of course, is exactly what what Gert has proposed to do now which is wait and see and then implement once it's clear what is happening. I think there is some drawbacks to that and whatever way we approach this, but I had the idea that we may make a change to our policy development process specifically for global policy which is this: Introduce an extra state toward the end, at the point where a global policy proposal has been accepted in the RIPE region but is not yet implemented by IANA because it has not yet been adopted in the other regions. I think given this the name accepted, pending and ?? the objective of introducing this state is only one, it is to allow us freedom to accept a policy at this point which we find is appropriate for our region, but acknowledge that discussions still took place in other regions, the policy might need to be reviewed as a result that have if we wanted to move forward and therefore allow the authors specifically again to bring the policy back into this state. If we don't do this, it's not actually clear to me what happens if we find ourselves in a situation where wording changes after its already been adopted in the RIPE region. Perhaps we can interpret the PDP as it is to allow this or perhaps go right back to the start of the process which has certain time limits and constraints. The characteristics of this: Like I say it's absolutely specific to global policies. This is a drawback potentially, because right now the PDP works in the same way for every single policy and so I am talking about introducing an exception and maybe we don't want to do that. As I said it allows the policy to go back to discussion, specifically if it changes in this and other regions then the authors can bring it back further. But if there are no further changes and I assume in the general case there would be no further changes, then it allows either RIPE or the IANA to implement the policy. And the big change it makes from me ?? for me from what we have now and I see and is attractive, it gives us in the RIPE region the freedom to speedily adopt a global policy proposal to reach consensus and go ahead without delay and without the risk of delay, of further delay if the policy later requires a change that we agree with. Now, of course, if there is a policy change we don't agree with, the policy isn't adopted. But if there is one we agree with and we want to get it out of the way quickly I think this gives us the freedom to do that.

Very briefly, I want to outline some of the possible approaches. I have thought of two of them and put them on the board. I am sure, one is we make no change and this is where we sit down, we see exactly how this works from what Gert just said. I think it's possible then that if there are changes in other regions, that it might require the policy proposal to be resubmitted in our region and like I said that introduces a time delay. Another possibility which wouldn't in principle require changing the PDP I think is that we only accept a proposal, declare and accepted at the point where the text has reached its final stage in all the other regions. The good thing is, it's less of a change to our PDP. The bad thing about that it does make the RIPE process explicitly dependent on time not guilty other regions so we have to wait and see how the policy text is going in other regions. So therefore, my preferred approach is the one I outlined at the start, is to introduce at this extra state but I am sure there are other aspects of this so I invite discussion. Thank you.

GERT DORING: Thanks for thinking about this and for approaches to handling it.

GEOFF HUSTON: APNIC. I think it might be helpful at least to describe to you the process used in APNIC to accommodate global policy proposals of this nature. The policy development process includes as its final step the shift from a proposal to a policy which is actually formally made by the executive council of APNIC, in other words the equivalent of the board, because it's a formal adoption by the corporation, by the entity itself. Now, for most policies, that is an endorsement of an existing consensus process. For global policy proposals, their endorsement has typically been conditional, and the endorsement has been that APNIC accepts this formally pending the adoption by the other RIRs that allows the APNIC to then make the judgement that when the others have passed they go, that is fine, that is all that was required. If it is changed by any other RIR it allows that final process to throw it back into the policy development process. The beauty of that is it doesn't overburden the existing policy development process but it is the final status in terms of the last chance before it option by the executive council. Now, I am not sure in the RIPE region what that final step is and who owns it, but amongst your approaches that you might have considered here, that might be one way of doing it.

GERT DORING: Since we don't have this final step as you have, we cannot use it, but I feel Filiz coming up and she's the expert on the policy process.

FILIZ : Relating to Geoff's suggestion and overall I have a few comments about the whole thing. I will start with that last comment. Now, we are ?? our board is not stamping policies or the consensus of the community as a last step in our policy allotment process, however we have the Working Group chairs collective who does that where you already mentioned after the last call status, there it is done by our RIPE collective, RIPE chair's collective. Obviously our board can have some opinion about an accepted proposal later on but we haven't seen that case really drastically.

Coming back to this: We also had a few words with David about this. I think it is extremely useful, not that our current policy development process, it is already allowing this because what we do after the final call, we could just ?? the only thing usually that we need to really complete after the global policies is that we need to publish that document or update the document, whatever is agreed on the existing document. We can wait until all the others do that.

The other thing, the implementation part already needs to wait, see approval over the decision and also the ICANN rectification and we do at this at the moment by means of announcements. In the last couple of global policies you may remember we also took note, yes, this will only be in effect after rectified by the ICANN board. However, I really agree, it will be good to document this within our policy allotment process so it is clear that RIPE region accepting a global policy doesn't mean that is in effect on the day of that acceptance is announced. So that will give room to this very clearly. Thank you.

WILFRIED: The idea of this whole exercise adding another blob here is that we in the existing PDP we have pretty well?defined time lines when the, like yourself, when the Working Group chair sort of thinks there is consensus, then within a reasonably short time frame the Working Group chair collective is expected to review the process and to say, yes, everything was in order, it's accepted, and then it gets published, or we are having a problem with the process. This thing, from my point of view, should actually be sort of a emergency hook to allow us to go to a certain point in the process and then to make the follow on steps in the process, depending or conditional upon a review whether the text is still the same in other regions. And if our collective or whoever is going to take that decision, that still has to be discussed, thinks that what the other regions have agreed on, adopted ratified, is no longer compatable with our consensus here, then we should be able to throw it back into the discussion loop and to do that, on pretty short notice without going again through lengthy weeks or months of having another discussion and getting it again into that status.

FILIZ: That was my understanding already and again, current PDP allows going from one stage to another based on the decision that is will be made and obviously the Working Group chairs will be involved in all those decision?making points. Yes.

AUDIENCE SPEAKER: It seems like a pragmatic choice to fix the process, what we are doing already, so, yes.

GERT DORING: I think what I am hearing is go forward with this and if you would be willing to formally put this into the PDP to change the PDP because that is the way the PDP is changed, by making a policy proposal.

DAVE WILSON: I have some wording which I will put forward.

(Applause)

GERT DORING: Let's see if I can find my slides again, they are somewhere here. We have four minutes left. We have the complete item J not even covered, not even started. I had planned for half hour discussion on these three issues that Alex brought up yesterday about the interpretation of the 80% utilisation rule, about the AS numbers and routing policy, distinct routing policy interpretation and about the difference between IPv4 and IPv6, even if we overrun into the break we are not going to make that so what I am suggesting is to just pick one of these, because I have heard quite a lot of comments about the AS numbers yesterday already, to me in private, to Alex in private, so I would ?? what I would try is to get feedback from the room for maybe five minutes or so on the interpretation of AS numbers and routing policies. So if somebody comes up and say we have 15 different notes, we have different routers and we can document that they have 15 different AS numbers, should registration services interpret this as yes they have 15 different routing policies so they get 15 AS numbers or should they argue that this is just one organisation so they get one AS number. This is basically where the question boils down to and the current policy documents could be interpreted either way. As I said, there have been comments and I want to have the comments open here and then we, if necessary, take this to the mailing list and the other two will directly go to the list because we just don't have time. So where is all the people that have opinions on this.

PIOTR STRZYZEWSKI: I am one of those lucky guys who have two IS numbers and first of all I need to say both of them were assigned through different LIRs, first was many years ago and the next one was a few years ago and we as an organisation, we have different kind of funding so we are obliged to run different kind of networks. The first one is fully academic network, somehow sponsored by the government, as you probably can understand, those guys doesn't like mixing, they found with the other ?? so we are running academic and commercial network on separate boxes, separate routers and links and the same staff and unfortunately one salary. And what I want to say is that we are one organisation and we have to run such an environment and we have that need for two ISs and should be pursued by the RIPE NCC, I don't see the point why RIPE NCC could tell me, sorry, guys, you are the one organisation don't run separate businesses.

ALEX: As RIPE NCC we do understand the situation you are in but the point of my presentation yesterday was that we feel that the current policy text, it can be interpreted both ways, you are one organisation and you need a single AS number because it's a single network because everything is connected but as the example up to I have 15 routers, each one has slightly different peers so therefore I could have 15 AS numbers. So either way, we feel the policy could be interpreted as well, but if it's something in the middle saying for your situation you should get a second AS but maybe if the situation is slightly different you should not, then we have a problem with the policy text, applying this policy text to that.

GERT DORING: To repeat that: The point is not actually to change the policy here but to clarify what we as the Working Group have intended when we did that policy text, I don't know, ten years ago

WILFRIED: Wearing the hat of the Austrian National Research and Education Network. Whatever the organisation formally or legally is does in some cases not have any direct or one to one wrapping to the different services and different network activities and the different routing clouts and different prefixes so I am happy to repeat what I said yesterday: We are one legal entity and one organisation formally but we are operating an exchange point we are operating top level DNS services for our country, we are operating backbone network and services for student, hostels and others and that is the background why different prefixes, different blocks of addresses as set are configured with homogenous routing policy and they have peering relationships with different other parties and that is the reason why the technology to do that is actually described that as one homogenous routing policy from one AS number, that is the definition that I am remembering for an AS, it's they are to describe a set of routers with external relations and on those you simply have the same routing policy and that is our background, sort of from a formal point of view my request or my question to the registration services would be if you do see a real problem other than a minor nuisance, then someone should actually come forward with a modification to this proposal. Otherwise I would rather have the registration services to apply their common knowledge and their judgement in a particular situation and do the right thing because otherwise we are probably going to have two different policies, one is for an organisation which has just one service and there is another policy which wear separate hats and on a more general line my feeling is we have having too many, two specific policies anyway in the first place so trying to pre define every potential aspect could be different than others, is not going to scale.

DAVE WILSON: I won't repeat all the good things the previous two speakers have said. I would like to add that we find ourselves in a similar situation, but it strikes me that the situation, the scenarios described where you have one organisation operating multiple networks, is very close to what I recall being the most compelling argument for removing the routing requirement out of the IPv6 addressing policy, it's very, very similar, and I think we should treat it the same way. I don't think we can just hive it off this time to the routing Working Group, I do understand, but I think the division or a division based on a single organisation unfortunately is is a bad one as has been shown elsewhere and I can only back up what Wilfried said for a solution.

GEOFF HUSTON: APNIC. Just a few observations here. Quite frankly, it's a case of there are many problems, which one do you want to work on? And generally the ones you want to work on are the ones that give you benefit. The few remaining ASs that are left in the 16?bit pool are going to run out with the momentum even if you try to change your policies now would not make any difference.

GERT DORING: We are not ??

GEOFF HUSTON: 4?byte pool go and do what you are doing now. I can't see any particular return on looking at this in any intense level. I agree with Wilfried.

GERT DORING: To use feedback from RS where they see operational difficulties due to well the LIRs interpreting things in a different way than RS does so we are supposed to give some guidance on interpretation of things. So we are not changing policy purposely because then we have to have the full set of proposal and process which this is not going to be.

RUEDIGER VOLK: If memory doesn't fail me, in the good old times the requirement for getting an additional ?? getting ASs assigned was essentially that you document distinct routing policy. I am not quite sure where our policy changed, but I think that is essentially the requirement that we should keep. Interfering with in what way a network operator segments its business or its ?? or its operational infrastructure, is not a business of the ?? of a registration service and well, okay, we might feel tempted to ask are we just being asked to get more LIRs per organisation which would be essentially a change in the fee structure of the organisation.

GERT DORING: Thanks for that.

AUDIENCE SPEAKER: I am from JPNIC which is National Internet Registry in Japan and we have similar issues and how we handle it is instead of looking at things in terms of organisation, we look in terms of network, so if the same organisation requires for additional ASN what we do is request for who they peer with and the reason why they need additional ASN and if we can confirm that they peer with different upstream from the initial one and they can explain the reason why they need additional ASN we assign a different ASN to the same organisation and so far it seems to be working quite well and we don't end up assigning 15 ASN to a single organisation. Just as a references.

Alex: If there are no other comments because I had some private comments in the hallway and they all seem to agree with the comments I had today here, that those comments all seem to agree. You said you received some comments?

GERT DORING: Basically in the same direction. So what am hearing quite prominently is if people can document a distinct routing policy, that is sufficient to get an AS number and if they have a need for 10 distinct routing policies which I find cumbersome to tally maintain but if people really build a network that has ten clearly distinct routing policies and can document this then this seems to be sufficient.

ALEX: That is what I hear as well and we can work with this

NICK HILLIARD: I think the overriding policy that or the guidelines of common sense apply here and that is extraordinary requests require extraordinary documentation and if somebody is going to do silly things like requesting 15 ASNs, well look, give it to them, if they can provide an all of lot of documentation. And good quality justification as to why it's necessary. So if we could possibly codify in the ASN assignment policy document that common sense will apply here, that may be the best thing to do. We are not running ?? well, as regards 16?bit SA Ns, we have a shortage of those. As regards 32?bit we are not going to have and are never going to have a shortage of those so there is no particular reason you to be particularly scroungy about them.

GERT DORING: We are not actually going to change texts, we are just expected to give guidance to RS on how the existing text is to be interpreted.

ALEX: At registration services we try to apply common sense always but the point of this exercise was to make the sense maybe a little bit more common between everybody.

GERT DORING: I think that this was a very worthwhile exercise because the people hit by, well, misinterpretation or different interpretation between this small group and RS and RS dealing with all the other LIRs out there, is actually not something that we as this group usually get to know about. So thanks Alex for standing up here and catching the tomorrow ate toes. Thanks to the Working Group forgiving very clear guidance on this. Of course, we will send this to the mailing list and give people a chance to jump up and down and say this is all not what we intended and in that case we might have to do this more formal but I don't really expect this but still the mailing list is the point of reference. As far as the other two things go, we are well into the coffee break and I will find a way to take them to the list to get them clarified. And if this thing is working, I go to my final slide.

Thank you for being here, thank you for helping us form the policy and enjoy your coffee and enjoy the RIPE dinner tonight.

(Applause)