Archives

The RIPE session on the 17th November 2010 at 9:00 a.m.:

Address policy session:

CHAIR: Good morning everybody. Welcome to the Address Policy Working Group. I think everybody who is going to attend is in the room and found a seat now, so we'll just start. Supposedly there is a bell, but maybe we can not hear it in here.

Anyway... welcome to the Working Group. As a matter of introduction for those that have not been here before. I am Gert /TKORG, I am your friendly Wog chair. I've a second Working Group Chair that's Sander Steffan, so if there is anything you want to discuss about Address Policy, things that you are unhappy with with and don't want to bring it out in the open yet, just speak to one of us in private. We are here to help you. And now we go to the Working Group.

This is roughly what I have in mind for today and tomorrow. So it's pretty much discussion of the formal policy proposals that we have right now and discussion of things that people notice that are not perfect in current policies and that we might want to do something about, or at least bring it out in the open.

More detailed agenda today will start with some administrative stuff. Then we will have two talks from Emilio Madaioed from RIPE NCC about current policy topics and policy overview, like get us all up to speed on what's happening in policy development these days. And about the document cosmetic surgeries project of course, which he will go into detail what that is sent and why we want it. Then Alex Le Heux from the RIPE NCC will talk about something he noticed in the policies that isn't really working out so well and we can discuss whether we want to change something or whether we need to change something in the policy framework. And then both of us Working Group chairs have some details that we noticed. Then it's coffee break.

After the coffee break, we will go into three specific already formal policy proposals. Nick Hilliard and Sergey, anden I will go to widen the scope of this a bit more than just a specific proposals, then see whether we need to do something more fundamental. Then it's lunch break and end of Address Policy for today. Tomorrow, we will have three more formal policy proposals that are already in the system to be discussed. Those ones. And then we have what we call the Open Policy Hour, where you can just come up and present ideas that have not yet been sort of formalised enough to be a formal policy proposal, but that might end up being a formal policy proposal if people agree that there is the need for it and any other business, if something shows up.

So, agenda bashing, so we, in the formal administrative part.

You have seen the agenda. I think it makes sense that way, but, well, I wrote it that way, so if you think something should be reorganised because we have collision with with with other Working Groups tomorrow, or something is missing, feel free to speak up now. I see nobody coming up to the microphone, so that's what we we'll try to stick to. And if somebody comes up, you can always bring it up tomorrow in the Open Policy Hour or any other business, so it's not like the agenda is closed.

Minutes:
We have very detailed minutes from the RIPE NCC staff, who is bloodying their fingers trying to type this all. Thanks very much to whoever did the minutes last time, because they did a wonderful job. And these minutes have been circulated to the Address Policy mailing list and I don't think I have seen any comments, so, unless somebody stands up now and says the minutes are not accurate, something is missing, I didn't say it that way, I will just declare them final. So, anything in the minutes that need to be amended? Okay, nothing. So, I declare the minutes from last time to be final. And we go into more productive work than just administrative stuff.

As a matter of introduction, Emilio Madaio, he is our counterpart at the RIPE NCC. He is the policy development officer there and he gets to sort of sort out what we mess up. So, if we do policy proposals, he has to get them all in nice shape and see that the process is properly followed and so on. So he is doing really important work to help us with this. You might remember Filiz standing up here and giving this presentation. Unfortunately Filiz has left the RIPE NCC and went to ICANN, so we are sorry to see her go, but ICANN will be happy. So sometimes changes just happen. So, Emelio. I am sure he will do an equally perfect job.

EMILIO MADAIO: Thank you for the pressure, Gert. Good morning, I am Emilio Madaio and I work at the policy amendment office at the RIPE NCC. Let me give you a brief update. Starting with common policy topics. In all the RIRs and what's happening in the RIPE community, what the RIPE community has been busy with and then last but not least, the an important update in the, about the PD O, the NCC. So starting with the common global policy topics.
There are some some dates to be given, a recent global policy accepted and ratified by ICANN, and some ?? discussions on IPv4 deletion and IPv6 transfer as extremely correlated topics all over the regions.

This is the global policy ratified by ICANN in September this year, reached a consensus in the RIPE community. Now it is the document RIPE?480. And it's about the allocation pool for the ASN blocks, starting from Jan 2011, there will be no distinction. No longer a distinction between 16 bit and 32 bit ASN block and the IANA and the RIR will use only the 32?bit (IANA)

In terms of IPv4 deletion, just a brief update on what's going on in the other regions. For AfriNIC there is a version 4 of the soft landing policy proposal, that will be discussed starting 20th November, next week, at the next AfriNIC meeting.

Happening as already a deletion policy, let's call it like this, in place but it's also discussing a new proposal, their last policy allows only one single allocation from the depletion pool. They are discussing also an additional allocation and the eligibility for some critical infrastructure to have an additional allocation. By critical infrastructure, they mean configured top level domain. And general particular top level domain.

As already the last /8 policy in place, and at the moment, I am not aware that they are discussing something to change it somehow.

LACNIC as well, has a policy in place, one of the small differences is that they will talk about depletion and they will change the policy of assignments and allocation when their address pool will reach the equivalent of a /12.

IPv6 transfer:
As I said before, it's correlated with the v4 depletion and it's included in the AfriNIC region in the soft landing policy. They are deciding to put a /12 specifically for automatic v6 assignments in order to booth the v6 deployment.

APNIC as well is discussing specific policy to change allocation basing on the v6 deployment needs.

ARIN as well, has a /10 already reserved from the last /8. LACNIC at the last LACNIC meeting reached a consensus on a policy proposal that removed the requirements of a single aggregation as a v6 announcement, routing announcement. That means that whoever had the v6 allocation was forced to nouns it in one single allocation. In one single aggregate (announce) and they removed this requirement.

Going local, I will cover this topic also here, give you an update of what the RIPE community is talking about. I will start first with the policy proposal that completed the PDP somehow and for example, the proposal 2010703 and 2008?04, where by the propose right after RIPE 60, after the feedback, they received at the RIPE meeting and right after. We are not going into the data of that, but they completed the PDP.

2009?01 was a global policy for the allocation of v4 blocks to regional Internet registries. And reached a consensus in the RIPE community in about I think in August 2010. ICANN recently, and by recently I think the middle of October, announced that the global policy abandoned. Basically by a statement for the NRO EC, according to some discrepancy all over the region. So this global policy, although reached consensus in the RIPE community, is now considered abandoned.

2010?04, was a proposal that entered the PDP right after the RIPE 60, reached consensus recently, and it was a proposal that aimed to clarify just one bit of the IPv4 allocation and assignment policy. It is also implemented although actually it was just a clarification on the interpretation of the policy, so we were already implementing it.

2008?07 is an almost withdrawn proposal. It was a very long one and some months ago, the proposal was ?? there was some kind of interest in from other community members to pick it up, for administrative reasons, in agreement with the Working Group Chair, we are deciding to withdraw it completely, so if this came topic, the same need it seen PI some community member, just please come and talk to me or to the Working Group Chair. We will start over the PDP on the same issue, but as 2008?07 proposal, this will be withdrawn.

These are, instead, policy proposal alive in the PDP. They are in different phases of the PDP and I will have to give you an update on that status.
2006?05: PI assignment size, it just ended the review phase. You will have, for this proposal, and all the others I am going to talk about in the presentation during the other Address Policy Working Group, so the proposal will get into the details on that and we'll invite you for discussion.

Same for 2008?08: Initial certification policy for provider aggregatable Address Policy holders. We'll hand in review phase next week, if I remember correctly. And you will have a presentation on that.

2010?01: Is the temporary Internet assignment policy proposal, and the proposal is working on some editing after the feedback received at the end of the review phase.

2010?06 is another ambiguity clean up policy proposal. It's just started the discussion on this policy proposal. There is some feedback, so very likely there will be discussion on this. I would like to stress the fact that this proposal does not aim to change the interpretation or the implementation of the existing policy. It's looking into the clarity of the policy itself. So that the interpretation is clear to all the RIPE community.

2010?02: Is the allocation from the last /8, and at the review phase in agreement with the Working Group chairs, we put this kind of in order to have a proper discussion and define what's the, what's the next step. Although the community feedback in the mailing list is pretty clear.

2010?05: Is the global policy for IPv4 allocation by the IANA post exhaust. That's phase considered in the policy proposal when IANA will deplete completely the Address Policy. So when they will run out of the current 1/8. An update on this is that we ended the initial discussion phase and we were collecting and producing the documentation to enter receipt view phase. There were some small changes to the policy text and we were updated by the proposer. We are still coordinating with the proposer in order to get in the right way into the review phase, but you will have a presentation by the proposer on Thursday. So they will explain to you in more detail. The situation on the policy text.

2010?06: And 08, 09, 10. These are are the very recent policy proposals. 2010?06 was presented yesterday in the v6 Working Group. This proposal is discussed in the mailing list, in the v6 Working Group mailing list and is also crossed in other mailing lists. We are about to enter the review phase on this and so we will publish the appropriate documentation.

2010?08 and 09, are discussed instead in the anti?abuse mailing list, so they will be presented there. They just started the initial discussion phase, as well as 2010?10, discussed again in the anti?abuse mailing list and cross pathed in the database and Address Policy Working Group mailing list.

Last but not least, some update about the policy development office. One of the RIPE documents that was updated this year was the policy development process policy itself. And we have a new document that is RIPE 500 and it obsoletes the RIPE?470. Maybe you didn't notice that because the structure of the PDP is still the same. There are some differences, the one I want to highlight ?? well, the main difference I want to highlight is that we basically made it public that now in the PDP we add RIPE NCC assessment to the policy proposal. There is, at the end of the initial discussion phase when the first feedback by the RIPE community is received and it's clear to the Working Group chairs and the next step in the policy text for you is defined, the RIPE NCC will perform an impact analysis that will highlight what is the understanding of the proposal by the RIPE NCC addressing also what kind of implementation we foresee for the policy proposal if it reaches consensus. The impact in the registry and the addressing system in terms either of fragmentation and address consumption, and also in terms of what will change in the RIPE database, for example. And the impact in the operation /services. So if some procedures, some existing business procedures and processes will have to change because of the policy proposal.

There is also ?? I I didn't put here but it's important to notice, there is also RIPE NCC Board input to the impact analysis, so they will also have a say, have a chance to have a say on this on the proposal analysed.

Last but not least, the legal impact of the policy proposal if something is seen as troublesome from a legal perspective.

And the last slide is about the staff news, as Gert said before, Filiz, my manager for some months, decided to move for better challenges. She is fine and says Hi to everyone. We stepped into the Twitter sphere too. We have a Twitter account and feel free to follow. We like to be followed and we follow back easily. You will see some dates in updates in terms of new proposals and links to it when we publish it or some update in the PDP status of current policy proposals under discussion in the RIPE community. The real discussion will happen always in the mailing list. We just use this as an update for Twitter users in the RIPE community.

And this is about it. If you have questions...

GERT DOERING: Any questions to Emelio about the policy overview? Anything unclear. I think it's still too early in the morning. Lucky you, no difficult questions yet. So please just go ahead with your document proposals.

EMILIO MADAIO: Okay. Still me now. I would like to talk about special activity, cosmetic surgery policy. I will give you now a brief talk about the history of this project, the status and what we see we should do next about it.

It was the ?? in RIPE 57 that the community tasked the RIPE NCC to solve some issues. The issues were related to the clarity and the readability of the policy of the active policy in the RIPE community. And basically in the life cycle of policy after the consensus, it was seen that during the time other policy proposals changed part, sections of the policy. Other new policy proposals were made and they were made in other times when the Internet world was changing so the needs and the requirements by the RIPE community were changing. And the update that then issued were maybe not conforming to a solid layout and a solid structure. So, the feeling the community had about the current policy was that they were kind of patched, like corrected from time to time and that created a lack in structure, in the proper formal test, in congruency and the main consequence was a low readability of the policy themselves.

So they expressed the need to improve such readability and in RIPE 57 asked the NCC to take care of it. At RIPE 58 a project plan was announced and was reviewed by the community and accepted. According to this plan, the NCC, and especially the policy development office, is supposed to create a draft, produce a draft in the NCC, within the NCC, collaborate with the Address Policy Working Group chairs in order to then publish this draft for community review. After the review, there was going to be ?? supposed to be one last call to collect some feedback and another last call just for confirmation, and then everything goes smooth, the new version, the draft becomes the real policy and obsolete the previous one. This post is extremely flexible, so it's very difficult to define a specific time line. Roughly, it's about 15 working weeks. Distributed in four weeks to produce a draft, depending on the policy it can be more. Then one week to coordinate with the chairs. Four weeks for community review and then one week per each last call. But as soon as the feedback asks for, the community feedback asks for a further review, some further changes, it's possible to redo one phase of the process again. And so 50 working weeks is a very optimistic time line.

In the project plan, we are also introducing six policies to analyse and to improve.

At RIPE 59 the finalised project plan was presented and the community accepted to the NCC to start the implementation. So the first policy to undergo this project were the one on the ASN. There was some other discussion at RIPE 60, but I didn't mean to report this one. At the start of the project, these were the web page that were set. This is the web page where everything is set where you can see the status of the project in terms of the presentation, the history of all the cosmetic surgery projects, the status in terms of what are the documents we updated, and on the right column, you see the draft the community is discussing. And all the announcements and the discussion on the draft, on the policy draft are done in the Address Policy Working Group mailing list.

So this is the first one that we completed. This new document RIPE?496 is the new policy for autonomous system number assignment policies, obsoleted the 463 and if it wasn't clear enough, by new policy I mean a new policy text under this project. That means that the meaning and the implementation of the policy is still the same, remained the same, the readability has improved, there is a better layout, there are definitions clearly stated. There is a terminology that is more structured and conformed and clear. Nothing to do with what is NCC will do to implement this policy. So what you expected from the previous version of this policy is what you will get also with this new version.

So these are the next steps. You can see here the list of the policy, the cosmetic surgery project we'll work on. We are ready to publish the new version for these three v6 policies will be merged into only one with. Then we will have the v4 allocation assignment policy and the last one is the policy for reverse address delegation.

Now, it's important to me to stress the fact that we need input, the NCC needs inputs from the community about this project and specifically for this next step we have to take, because we are already working on the v6 policies we have on this cosmetic surgery project. We already merging three of them and have only one. It's an amount of work that will need an important feedback from the community, the review will be similarly important. On the other hand, that we notice with the Address Policy Working Group chairs, that recently IPv6 policy in the RIPE community became a hot topic. So there are policy proposals and there are discussions about v6 policies that covers an interpretation, and the clarity of the policies themselves. So, what's going on, what the community is focused on when it comes down v6 policy most of the time is about the clarity. The readability and not the policy themselves, substantial changes to the implementation or to the activity the NCC has to do. Just pure text revision. This is already the scope of the cosmetic surgery project. So, my interest is to have the community work only once on some specific need they want to satisfy. So, why do the PDP, for some ambiguity, clean up, when we are already working on the same policies in the cosmetic surgery project?

As a counter example, I would like to mention the proposal 2010?04, that was the ambiguity cleanup on the 80% rule presented in the IPv4 allocation and assignment policy. That cleanup needs arrived at RIPE 60 when the cosmetic surgery project was working on another policy, the ASN one so the timing was not the lucky one. At this time, at this RIPE 61, there is also a matching timing, because the community is talking about v6 policy ambiguity and misunderstanding and misinterpretation and the cosmetic surgery project is undergoing with the v6, IPv6 policy that are in place. So, if a policy proposal scope is to try to improve the text of a current policy, and that this policy is an IPv6 Address Policy, then very likely it can be more effective to use the cosmetic surgery activity, the NCC is already doing, to achieve with a larger community review the clarity the community is looking for.

So, this is it. And I have nothing else to say. I just need some input about the cosmetic surgery project. So that's it.

GERT DOERING: Thanks for bringing us up to date what's going on and why. Rob please the.

ROB BLOKZIJL: Morning. I am Chairman of RIPE. I think I am known to people who started this activity. And I don't have a question, but I want to be sure that I understand where we are now. We have identified sometime in the past that the language of our policies is not always as clear as it could be. So, a while ago we sought about how to clarify some of the text. And if I remember right, we identified one existing policy as a kind of pilot experiment E went through what is now the cosmetic improvement project. I think that was successful because what came out was exactly the same policy, that is a requirement, but much easier to read and understand. So, I would strongly suggest to make sure that as new policies are being developed, this tool is part of the process of creating the policy. That is nothing new, because we have always said people who feel uncomfortable in writing English, in the English language, their proposal, they can write it in any version of English and the RIPE NCC will provide expert help in turning it into proper English. So that's basically what we hope we are doing now. Then we are left with a lot of documents that could be cleaned up, and I think we should be rather restrictive there and we should really take the policy documents which are still current. I mean, in half a year from now, there will be a whole lot of policies which are totally have suddenly become irrelevant because they have to do with IPv4 address space allocation, that sport will stop in half a year or so, or in a year from now. But we are in the process of thinking and creating IPv6 related policies as we need them and I think, since we don't have infinite resources that let us at least make sure that the new policies, when they are up for discussion, have gone through this cleaning state already. So that we won't have to repeat and work on accepted policies and then find out, oops, there is ambiguity in the language, what did the original proposal mean? What have we decided?

EMILIO MADAIO: I agree, and this is why I was stressing the importance now to focus if it's about clarity more on the cosmetic surgery than on the PDP, so yes I agree.

ROB BLOKZIJL: So my list of priorities would be: New policies which we are working on is on the first place, and then we have a look at existing policies which will survive more than half a year from now as a second priority and the rest probably we won't have time to go into that at all. Thank you.

GERT DOERING: I think that's actually what is happening already. I see in the impact analysis that the NCC does, that there is a section: This is how the NCC understands that the policy is supposed to be executed, and if there is something unclear, I think it will show up exactly at that stage, so, we are trying to learn from the past. Okay, anything else?

AUDIENCE SPEAKER: I am Sergei from Ukraine. Do we have some time schedule for clarification of IPv6 policies when all the three policies will be combined into one?

EMILIO MADAIO: As I said, we are ready to publish. We just put it slightly on hold in order to collect more feedback now at RIPE 60 because of different discussions going on on v6 in terms of ambiguity cleanup. So, after the RIPE meeting of the RIPE 61, we have already a text we can publish for the ?? for these three v6 policies. We would like to align it more to what will happen at the Address Policy meeting, so to have it even updated ?? to have the community go through already with the feedback and the result we had at RIPE 61. So in terms of publishing it, it's about what will happen here and I strongly suggest to pay attention to all the discussion that we will have, in terms of v6, v6 policy and the others during the session. Because there is room for a cosmetic surgery project to perform some important results. So that's what I am saying.

GERT DOERING: I don't see anyone else at the microphone. So thanks.
(Applause)

I have actually forgot to make an announcement. In your meeting back, you all have this paper about resource certification. We have a policy proposal on our table for tomorrow about resource certification and this has been going on for quite a while because sort of maybe lack of understanding what this is all about, why this might be important and what the implications are. So there is lots of information on the back, lots of pointers. If you have time today, would I appreciate if you could just look into this so we could have a well prepared discussion about the certification stuff tomorrow.

Another announcement. There is, in NCC's services today, Axel Pawlik, the boss of the RIPE NCC, will present a paper about closure of LIRs and deregistration of address space, or address resources today. The document has been circulated to the mailing list, but it will be discussed in NCC Services. Since this, well affects all works as well, it's what happens to the addresses after they have been given out, I urge you to read that, make up your mind on it and comment in NCC Services. That's so far.

The next speaker is already on screen. Alex Le Heux from the RIPE NCC. He had the idea a couple of meetings ago to really improve the communication between the NCC and the community by bringing back things that the NCC stumbles about in their day?to?day work. So edges of the policies that are not as smooth as they could be and today, I think we have transfers on our plate.

ALEX DE HEUX: I am from the RIPE NCC. I have two sections I think in the Address Policy Working Group, this is just about the transfer policy.

Now, for years already, we have a document RIPE?301, which describes mergers, acquisitions, closures of LIRs. It's a fairly ?? it describes quite a few things, closures, mergers, this is, I am talking now about the section which is about when LIRs merge or split up or things like that. LIRs are mostly corporations and they are all part of the cooperate system and corporations they gobble each other up when they split up, etc., etc. And we are treating this as mostly administrative thing. Because RIPE?301, it's not a policy document, it's a procedural document. We tend to verify that there is actually a transfer of assets or business units or things like that by verifying the contracts between the two LIRs. And it's very flexible and it has to be, because we see a very wide variety of situations. We see simple two ?? two corporations have merged, two LIRs and they merge or ?? but we see some pretty wild things as well. We have two LIRs that split up into five or seven LIRs that merge into two. We see huge variety.

And we have been doing ?? it's worked well for many years. And then in 2008 there was a transfer policy that appeared in the Address Policy documents. This is meant to come into really ?? to become really useful post?depletion when LIRs are expected to have, you know, some will have some address space that they are not using; others will have address space that they need and this was ?? this policy ISP meant to make sure that there is no chaos when they start transferring their allocations.

Now, it has a few limitations. Any allocation or part of an allocation that's transferred may not have any valid assignments or end users in it, while what we do under or transfer procedures for mergers and acquisitions, that always has an active network in it so that will have active assignments in it. There is a requirement that the receiving side, and their needs are evaluated by the RIPE NCC and they're approved. And there is a statement that the receiving side cannot reallocate, they cannot transfer away any allocation they received in two years. So, I was thinking, so how should we go to implement this actually?

And because any receiving side has to be evaluated and approved by the RIPE NCC first, the first part of this process would be pretty much business as usual. They would submit their requests, the hostmaster would look at it, there'd be some communication and then eventually there will be an approval for what they want to do. Much like we do today. Except post?depletion of course, that approval won't be followed by an allocation of address space. They'll have to go out and find the address space themselves. So, that's a big change.

And then, we'll be living in a post?depletion world, we'll be in the transition of IPv4 to IPv6 or IPv6 /IPv4 dual stack, something is going to happen and it's likely going to be happening very, very quickly, because, you know, Internet has to keep working so there will be many developments going very quickly. And by that time, any allocation that we made immediately preceding depletion would have a validity period, would have an allocation period of three months, maybe six months depending when exactly we run out of address space and the receiving sides, even if they might move very quickly in their transition and they would only need this extra space for a short period of time, they could not transfer it away again to someone else who needs it for two years, as is specified in the policy. And so there are quite a few restrictions in this policy. And because we are still, we still have address space to allocate, this is not a policy that's ever been used yet. So, we are looking at what might happen.

And because both this policy and the RIPE 301 mergers and acquisition documents involve moving allocations between LIRs, and one of them has all these restrictions and the other one has basically no restrictions, it is quite possible that when faced with these restrictions, LIRs will choose to try to go to the path of the mergers and acquisitions procedures, which are much simpler to do with much less restrictions.

Once depletion is there and it's time to implement this policy, we could, of course, try to restrict the transmergers and acquisitions, the kind of transfers we do there. But there is a big need for that kind of transfer, because it is something we do on a daily basis because we have over 7,000 LIRs and the corporate ecosystem will keep churning and keep churning even post?depletion, so we are not really sure how to limit these mergers, acquisitions, transfers post?depletion.

So, another thing that might happen, which probably would be even worse, is that LIRs look at either the policy here or the mergers acquisitions procedure and they might decide that both of them are too much hassle and they will just transfer or move their address space around under the table and that would be worse because at that moment, we would have no idea any more with where the address space is and then we lose track of the main function of what the registry is about. It's knowing who is using which address space.

So, perhaps it's time to look at exactly what we would like to happen post?depletion with the transfers between LIRs of address space. And I don't have a solution or a suggestion for a solution for you. So, my story ends here.

GERT DOERING: Okay, Alex, thanks for bringing this up. I am not sure if it's completely clear, if I understand you right. We don't have real clash of policies here because one applies to sort of just transferring the addresses and the other one applies to, if I buy that LIR with all their space.

ALEX DE HEUX: Or you buy a business unit of the LIR, or you buy one of their services.

GERT DOERING: It's really sort of a business transaction.

ALEX DE HEUX: It is a different business transaction from but a distance.

GERT DOERING: In the end it's addresses getting transferred under some sort of contract with the business unit or just the addresses, so..., yeah.

ALEX DE HEUX: Yes.

GERT DOERING: I can see that this is confusing. And not as clear as it could be. I see Rob coming up to the microphone please.

ROB BLOKZIJL: I have a few worries with policies like the transfer policy. It's ?? as you quite rightly say, it is quite restrictive, and I have the feeling that this could have been written by academics defining Utopia. We are not in the business, I think, especially post?depletion, to try and regulate part of the ecology. I think our main interest is in knowing where the addresses are today and not so much in how they came to be there and whatever we try to define as a perfect scheme, I can guarantee that people who need address space will find either loopholes or ways around it or do "Under the table" transactions and don't tell us because our policy says that they should not do it, but their business demands it to do it. I think in the long term, we will be using the IPv4 space for many, many, many years to come. Up till now, we have been concentrating on defining sensible allocation policies, and I think we should all learn to refocus inside the IPv4 world into sort of maintenance mode. And maintenance mode, what do we want to maintain? We want to maintain a complete and correct and up?to?date registry of IPv4 addresses. That means that we keep track of what happened to the address space AS and IPv4 space equally which we received from IANA either directly or indirectly. And that means we want to keep track of what happens in this volatile economic field. And I think it is a bit artificial to say, well, we can deal with transfers between two of our current existing LIRs, but the transfer between an existing LIR and something that doesn't exist today but is created next year, oh that's a completely different problem. I don't see that as different. Let's focus on what we ?? the purpose of all this. That is to keep a clean up?to?date registry, which is used by all of you in making your routing decisions, in finding contact points, in solving problems, and let's not spend or waste too much time in creating laws which we can not enforce at all. End of message. Thank you.

GERT DOERING: Well said. Well, I seem to remember how the policy came to be that strict, because we sort of had too many people in the room or too many people in the community being afraid that ?? would ensure if we just permitted anything. No need to respond to that. It's just well the way we happen to get at least some transfer policy. But I am actually trying to find a way forward. I don't see that many people queuing up on the microphone so obviously it's too early to discuss this right now. What I want to propose, and then I'll hand the microphone back to you Rob, we'll find a volunteer or find a small group of volunteers that would be willing to tackle this transfer policy in combination with mergers, closures, acquisition and sort of form a round document and bring that up.

ROB BLOKZIJL: I have two remarks. You mentioned we want to prevent chaos, that's why ??

GERT DOERING: That was the worry that came up.

ROB BLOKZIJL: And our standard reaction is: Make a policy. I think we were all a bit in a hurry there. You can create policies that will stimulate the creation of chaos. Policies that people feel do not fit their situation and they will try ways to go around it, so you missed your target completely. And that leads me to, in answer to your last remarks.

Triggered by the fact that in a few months from now the RIPE NCC will start issuing digital certificates in a rather, I think personally, strange fashion. But the certificate says: "This certifies that these resources have been registered by the RIPE NCC." Okay, now, somebody shows me this certificate. I said, "Oh that's very interesting, where is the document that defines this registry?" Ah, we don't have that." We don't have a formal complete description of what we mean by registry of IP resources. We have all sorts of the databases. So, a few weeks ago I started to work with the RIPE NCC in drafting a definition of the registry, and as soon as the first draft is ready, meaning that it's a technical document, not policy, it will be published for comment of course. Which then automatically leads, if you have a registry, you obviously have registration policies, rules of how to use the registry. Well, we have registration policies, but we don't have a document, one single document. There are bits and pieces scattered over various documents. So, I think that we should ?? and that again it's not creating new policies, it is gathering all these bits and pieces and see whether we can combine it in a new document, but which is then a complete description of registration policy. And I think that comes closer to what you are aiming at, because once we have a better overview of our current registration policies, I think then it is time to think about the requirements for registration of address blocks that, in half a year from now after depletion of IPv4, will start having a life of their own and start moving around. I think what we are talking about is no so much regulating the transfers of address blocks. Our interest is tell us where you transfer it and keep the registry at that time data up to date.

GERT DOERING: I fully agree that having to, having the information in there is really highly important. The problem is we have this policy so we can't just ignore it. We need to formally change it if we want to make it more easy. So, I look forward to seeing the document. I hope to see it soon so we can then start on this. Susanna, feedback from Jabber. This is why I mixed up the order.

SANDER STEFFANN: I have one question for Rob. What is the time line you have in mind for this document?

ROB BLOKZIJL: Since we have announced that the first version of digital certificates will be issued from January 1, I hope to have this document finished and at least one round of comment before Jan 1st. Because otherwise, we are issuing certificates referring to something which we have not properly described.

AUDIENCE SPEAKER: I have a question, it's more a comment actually, from Sasha who represents various LIRs, and he says: For the record, full agreement with Rob.

GERT DOERING: Thanks.

AUDIENCE SPEAKER: Geoff Huston from APNIC. I actually wanted to relate the outcome of the APNIC policy process, since we consider this entire thing at some length from that 2006 onwards. And the outcome in that process was actually a policy framework that had a component while we still have a needs?based allocation process of address space from normal pool. And then a flip when we don't. And the policy basically says that when we move into this phase of the last /8, which is meant to last for some extended period of time and certainly not the current general allocation, when we move into that phase, there are no particular restrictions in terms of moving addresses around between folk. The idea being that once we haven't got this allocation mechanism around, we truly revert to being a simple registry. And a simple registry needs to admit reality, and the fewer policies you have about what you would call reality tends to make the registry more useful for everybody else. In that respect, I think I find myself personally agreeing wholeheartedly with what Rob said here, and as someone who has been in this registry business for sometime, I think that's a very, very wise set of words, Rob, and we should all reflect on it quite deeply. Thank you.

GERT DOERING: Thank you for that update and I think there is lots of wisdom in it, and we will look at your documents and learn from it. John.

AUDIENCE SPEAKER: John Curran, president and CEO of ARIN. I just also wanted to relate, Geoff quite eloquently said at the point in time that we are now about to enter, it is time to reflect on what the purpose of an RIR is and what function it serves. In the ARIN region, with respect to transfers, we also looked at the same problem. We had some different factors in the ARIN region, and came to different outcomes and I thought it might be good to let the RIPE folks hear what that is, because it changes rapidly and it might have a different philosophy behind it.

In particular, we have distinguished between mergers and acquisitions and transfers of address space. In fact, the merger and acquisitions policy says if you transfer the resources that are using the numbers, then the numbers should move along with those resources, and in fact, if the latest revision, it says the numbers that are being used and need to be used for transfer and ones that are not being used should be returned to the RIR. So, in fact, a merger and acquisition only transfers resources that the entity actually uses.

In the ARIN region with respect to a more open transfer process where a party actually literally says "I need numbers, I don't have them, the registry doesn't have them, I need to insent someone to give them to me," we have a specified transfer policy which says that a party that qualifies for an address space per our normal process, given their address space, that would be a year's worth of address space. A party that qualifies for address space and meets the definition of "Need" per today's definition just as we do with requests, can turn around and show up with another party and say I am getting it from this group and I need to insent them or I may not, that's not the registry's job to ask but it allows one party effectively to transfer resources from another, but it still has has a need basis, it still adhered to RC 2050 and the requirement that the party getting them is actually going to use them. That turns out to be important in the ARIN region region because the circumstances that we see. Then it's a different framework than what APNIC has come upon. And the thing that RIPE needs to consider is what framework makes sense. And also something we all need to consider is: How do these frameworks interact with one another?

GERT DOERING: Thank you for that.

AUDIENCE SPEAKER RUEDIGER: Well, okay, clarification question to John. The transfer policy has been actually used or is it just there in place so that when things change, it can be used?

AUDIENCE SPEAKER JOHN CURRAN: In theory it can be used today. Though, it's a little unusual, you qualify for address space and ARIN has an available pool, and why would you go get it from someone else? I guess if you wanted a vanity IP address and you knew who had it, in theory this policy would let you go get it if you qualified for the need and you wanted a particular one. It might be used if organisations wanted address space that they might have been using already but never had the record for and now they to clean that up. But from a practical matter, it doesn't really serve much use until ARIN's available resource pool goes to zero. It's active and available today. We don't have anyone turning the crank on it, if that's help, Ruediger.

GERT DOERING: Okay. Thank you. Since ?? well, one last comment and then I will wrap?up and ??

AUDIENCE SPEAKER: Hans bit /TKPWAOULen, I heard both today and yesterday several refers to say RFC 2050 and it just struck me that do we need to understand better what's the status of that RFC, because I seem to remember that we have in the past discussed whether it should be updated and we abandoned that idea because the IETF didn't really have a role in address space any more, and that may actually be an interesting discussion to have when we move into the new world, because some of the wording that's in there may not be directly applicable any more.

GERT DOERING: Okay. I see that this is going to be more complicated, so, Wilifred please.

WILFRED: This actually opens a very interesting new thread of discussion, in particular the potential interaction between policy development within the regions, following the bottom up process and at the same time, drafts being submitted to the IETF which, if eventually becoming agreed to, would have a direct impact or at least some relationship to the policies we are making, like the ideas floating around that the IETF would ?? could, maybe eventually, sort of take some of the remaining unallocated address space and label it differently or reserve it or do or sort of write and RFC which describes a particular use of that. That's something which might also come into this whole discussion like 2050 is the IETF, sort of in a position to, without double checking with the policy community, trying to do new things to the IPv4 address architecture.

GERT DOERING: Which certainly is an interesting aspect, but at that point I would consider it to be somewhat out of scope for the transfer thing here and if we try to focus on that. We don't need to worry about it, but otherwise, yes, it's a good point.

AUDIENCE SPEAKER: Owen Delong, Hurricane Electric and also the ARIN Advisory Council. RFC 2050 is, among other things, the process by which the IEPF delegated member policy processes and roles to the RIR system. So, I certainly think we want to avoid not right abandoning that because that's sort of what created the RIR system to some extent.

GERT DOERING: Now, I am going to wrap?up. Alex again, thanks again for bringing this up. I think the way forward is sort of to wait for the document from Rob, look at it, find it useful, and then find a team, a small group of volunteers to work on the transfer policy documents and then sort of get this into the formal process as soon as we want, as we know what the result should look like, looking at ARIN policies, looking at APNIC policies and of course that will happen on the mailing list. So thanks for your input.

(Applause)

GERT DOERING: The last bit before coffee is actually the two Working Group chairs of us with some, say, minor nitpicking on policy details, policy interpretation.

First it's me, then it's Sander. This time it's all about IPv6, so this is really looking into the future. My nitpick came up from a discussion on the IPv6 ops at Cluenet mailing list, which is generally a very high quality mailing list and a very good questions about IPv6 are brought up there, and in one of the discussion threads about, can you give your customers a /56 or a /48, someone said that with the new policies cannot give your customers a 48 any longer. I said where does it say that? And he pointed to this bit of the policy document. I am not sure whether you can actually read it. It's the subsequent allocation criteria, and the subsequent allocation criteria for allocations to LIRs says:

"Subsequent allocation will be provided when an organisation satisfies the evaluation threshold of past address utilisation in terms of the number of sites in units of /56 assignments."

And at the same time, the document says, you can give your customers whatever you want. So people sort of read into this that, yeah of course you can give your customer a /48 but if you have up for reevaluation, this is counted as a 56. If you don't have enough 56s, you don't get new address space. So if you give your customers 48, you are sort of like blocking your path to an extension. Which certainly is not the intention. And it's not actually what it says there, but the wording of "In terms of the number of sites" sort of implies that you count sites in units of 56. So aside is a 56, if you give a side a 48 you are sort of breaking the policy.

I have checked with the NCC what they think about it. And they don't see it as a problem. So, if you give a customer a /56, it's counted as a 56. If you give a customer a 48, it's counted as a 256, /56. So it's always been that way, so it's no like needless strictness on the allocation side. So, it's actually working out. It's just a perceived problem. But that means that the policy text might not be perfect.

In that discussion, Arno Mulecamp spoke up, he was working at the NCC in earlier times, he is now I think at ISOC ?? left the ship ?? and he suggested to amend the text in this way. Basically removing the site bits and talking about address utilisation in terms of assigned address space in units of /56, which is pretty much exactly what the current interpretation is, just in more clearer wording.

Now I am bringing this up because, well I need your feedback on whether you think this is a change of policy, which I don't think. Or whether this is just clarification. And if it's just clarification of the wording and not change of policy, this can go into the document cosmetic surgery projects. Emelio is working on the IPv6 document anyway, so if you agree that the current policy is fine, we don't need to have a formal policy change process here, just clarification of the wording, then we don't need to do the big fuss about it and Emelio can just integrate T I'd welcome a little bit of feedback from the group. I'll also send it to the mailing list and get feedback.

AUDIENCE SPEAKER: Owen Dorn, Hurricane Electric. I think that it's not a policy change and it is clarification, just my own personal opinion. However, I don't think that Arno's clarification actually provides clarification. I think that it needs to be very, very clear that you are counting 56 blocks in such a way that assigning a 48 is okay and counts as two 56 of them, and that doesn't do that. That still leaves the possibility for people to perceive that things are counted as units of 56 and if you assign a site, it counts as a 56. And that is a very, very risky proposition as people start considering how to design CPE and you have incidents like free.fr assigning /60s to end users and you have CPE coming out that's built on the model of well the user gets a /60 or worse, you know, 56 is better than a 60 but really, I would rather see 48 as the standard. There are plenty of them to give every resident on the planet a 48 and still only consume 15 or so of address space. So I am really not that worried about giving out 48s.

GERT DOERING: Okay. Emelio you are listening so please don't take this text but come up with something more understandable. Other comments on this please?

AUDIENCE SPEAKER: Plus one is what own says basically. It is just a clarification, but it needs a bit of wordsmithing.

GERT DOERING: Sander?

SANDER STEFFANN: Just speaking as myself now. Would just adding a line that larger assignments will be counted as multiple /56s solve the whole problem?

GERT DOERING: I seem to hear that this would do. Just make it more explicit. Okay. So, I'll bring this back to the mailing list just to make sure it's in the open, it's in the mailing list archives. But I think since there is no real misunderstanding ?? no real policy change here, no ?? not only no real, but no policy change at all, we can really go forward with just clarification of the document.

Okay. Thank you.

Now, it's back to Sander in his Working Group Chair role and he also found something that confused people without actually being a problem.

SANDER STEFFANN: I was talking to some people who were doing assignments to end sites and they had some problems with the text that defines and end site. It says "An end site is defined as an end user (subscriber) who has a business or legal relationship with the service provider."

That involves certain things. The question that they asked is but what happens if I have one customer who has two separate hoaxes with two DSL connections? Do I have to count them as one end site or two end sites? The current implementation at the NCC is that if you have two connections to two different locations, that those are two different sites. Is this the intention of the policy? Is it the intention of the policy different? We think that the way the RIPE NCC registration services implements it is the correct way, but I would like some confirmation on that from all of you. Then, is the text in the policy clear or do we need some cleanup here as well? So, I would like to get your feedback. Anybody has an opinion on this?

AUDIENCE SPEAKER: Yes, do I have a strong opinion.

WILFRED: The manager of the local Internet registry for forth Austrian. I think we will never come to a proper definition of an end site. I think there is no such a thing and however hard we try to fit that into some description based on legal relationships, contracts, whatever, it's going to be royaley broken anyway. Just to give you a hill background. We also support the regional school networks in our country, and all of the ?? well we have nine federal states for funny reasons, we have a governing contract for the regional school network areas for eight of these nine federal states in us a tree a, so we have one contract for nine regional school networks, which are on the separate operational control by different layer 2 and layer 3 service providers. If we would try to apply that definition, I would have one end site. That's not going to fly anyway. Just as input to the thought process.

My personal interpretation of what's an end site that I am deploying for quite a while and try to do that in the future is an end site is an entity which makes its own address plan within the block of addresses which they get. That's my definition of an end site.

SANDER STEFFANN: So basically, you agree that the way that the RIPE NCC is doing it currently is correct? Thank you.

AUDIENCE SPEAKER: Rob sees /TROPL, a fill /KWRUS. If we are trying to conserve IPv6 addresses which is why we wouldn't simply hand out one end site for every DSL connection, then we are really trying to optimise for the wrong thing. We should try to optimise for operational simplicity and therefore, I think this is nothing wrong with the current way of handling it.

SANDER STEFFANN: Thank you. So, ??

GERT DOERING: I can see that Ruediger agrees because he sat down again and is not speaking up.

SANDER STEFFANN: So, my final question: Do we need to change this text? Do some clarify the bit in the cosmetic surgery project or just leave it as it is? Any opinions on that? Then I guess we have to take this to the mailing list.

GERT DOERING: We need to take it to the mailing list anyway, but from what I seem to be hearing in the room, leave it as it is, because it's not bringing up strong enough emotions for people to jump up and down.

SANDER STEFFANN: Thank you.

GERT DOERING: And that's basically it for the first slot. So we have coffee break now. And please be back at 11 o'clock and then we go into the specifics of current proposals. Thanks so far.
(Coffee break)

LIVE CAPTIONING BY MARY McKEON RPR

DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.

WWW.DCR.IE