Archives

These are unedited transcripts and may contain errors.

Address policy session on Thursday, 19 April, 2012, 9 a.m. to 10:30 a.m.:

GERT DORING: Good morning, dear Working Group. I know that it's 9:00 in the morning again so I am happy to see so many of you here. I wonder whether I should have a chat with Ops and create a small network out age during the discussions, but let's see whether we can get the discussions interesting enough that your mail is not so interesting.

This is what we are going to do today. First of two slides. First is sort of a summary and some material for thoughts that Sander collected for yesterday already, but which I moved here due to the, well, the coming up coffee break yesterday and the tiredness of the Working Group.

Then, we have Rob. That is IPv4 maintenance policy up there, sorry for that. It has been on the web for about four weeks with that mistake, nobody spotted it. That is IPv4 maintenance policy F we run out of v4 addresses do we need all that different policy documents if they don't apply any more, anyway. But more to that later.

Then, it's, again, IPv6, and in that case it's really IPv6, the PI and PA /AOUPBification stuff and what has happened just a short update. Then, we have Jan Zorz who accepted to be volunteered to talk about the additional allocation policy for IPv6, which sum some of you seem to be unhappy with and maybe we can figure out where the problem is and how to fix it.

Then, we have the open policy hour with new policy proposal from Nick Hilliard that he wants initial feedback from you, and Poe essentially AOB.

So, anything missing? Obviously, IPv4 maintenance policy needs to be corrected. Anything to be added, anything wrong? No. So, we go to Sander for what is consensus.

SANDER STEFFANN: Good morning. We had a few more difficult policy proposals in the last couple of months and for some of them, it was actually very, very difficult to see if we had consensus or not so I am going to talk a bit about how we judged it, how we, what our approach was and what our reasoning was there. Just to give you a view of what is, yes, what we do and how we think it should be done and ask you if you agree with that.

So, our first very quickly go through the policy development process. Basically, a proposal starts by w? a discussion phase, and there is some initial discussion and if people seem to like the idea, draft documents are written RIPE NCC does impact analysis and we go to review phase. At this point, we don't need consensus; it's just an idea, still.

Then, in review phase, we work on finalising the wording and then we have to determine consensus. So, in this, in this part, we actually need people to speak up if we are reviewing a new policy and nobody speaks up in favour of the policy, then why are we doing it? So we really need people who say, yes, this is something that we want.

So, if we reach consensus here, we go to the concluding phase, also called last call.

And in the last call, this is the last opportunity for people to comment on the proposal or oppose the proposal. And basically, since we already seen that there was support during the review phase, if people don't speak up here, that is fine. We have seen their support F we don't get any objections, then we say, OK, there is consensus and we accept the new policy.

In this phase, the consensus is not only determined by the Working Group Chairs of this Working Group, but by the collective of Working Group Chairs, so there is some extra checks here to see if everything was done correctly.

So, basically, for the mailing list discussions, there is one important rule that says in all phases suggestion or changes, objections, must be justified with supporting arguments. So, that is ?? that is the basic thing that the PDP says about the discussion and reaching consensus.

So, we need two places: Like said, at the end of the review phase we need speak to speak up, silence is not OK. And at the end of the concluding phase, we ?? we declare consensus even if there is silence because we have already seen that the support is there.

So, this looks simple. So, how do we determine consensus? We need explicit support. If there are questions asked on the mailing list about the proposal, they need to be answered. We don't leave any unanswered questions lying around. And if there were objections, then we either need those objections to be withdrawn or the ?? the justification for the objections, if it's shown that the justification is not valid, then of course we don't need to do anything with them.

But sometimes it's a bit more difficult. If people have objections based on non?technical arguments, things like possible future impact, how do you deal with that? What are valid arguments, what is a valid justification for that? And then if somebody tries to counter that, what is a valid counter?argument? As long as it's all based on facts and things like that, it's easy to check, but we are writing policy so we are looking at the future and it's very, very difficult, sometimes; people have objections say oh, I am afraid this will happen in the future, what are the chance of that happening? How can you counter it? We cannot predict the future exactly, so this ?? this is becoming difficult for us, so how are we dealing with it. So the first thing, if possible we try to make sure that every concern and every objection is handled. Either the proposal is changed so that the people who had the objection say, OK, it's fine, or we look for counter arguments if they are there.

But we also have sometimes reached a point where one person or a few people are opposing something and they just say, no, I don't agree with the counter arguments, or, I don't agree with the solution in the text. And then we come to the point where we have to realise that consensus is not unanimity, it's not that everybody has to agree. There is no nobody who can veto a policy. But we have to be very, very careful here.

So, when consensus is not unanimous, we have to make a judgment. So, do we see support for the proposal? Is there a solution that will get unanimous support, because if that is possible, then of course that is always the better solution. Is the opposition justified for supporting arguments? Sometimes people just say oh, no, I don't like this but they don't give arguments so then we can't do anything with it. And is actually, is it just one person objecting on some moral grounds or whatever, or is it real ?? is it a group of people, are there more people who have the same concerns and it's a judgment; there is no black and white here.

So, after we have difficult outcome like this, we publish our reasoning. So, well, it's always possible that we interpret things incorrectly. So we can be wrong. So, this is not a disaster. If people think hey, you made the wrong decision, just speak up on the mailing list. We always listen to that. We always have, at the end of the concluding phase, the whole Working Group Chairs collective that checks if we followed the process correctly and they double?check what we did and if then there is still something that is ?? that somebody say, I really don't agree here, we have an appeals process in the PDP.

So, like I said, sometimes it's not black and white and as Working Group Chairs, we need to make decisions, and of course we hope that you agree with our decision, our outcome. So, but if you ?? please, let us know if you agree or disagree with that. We are here for the Working Group, so we try to do the best we can and it's not always easy, but at least want to explain this to you so you know what is going on on our part and how we deal with it.

So, any questions about this? Any comments?

AUDIENCE SPEAKER: Wearing no hat, just like ?? I really like the situation in which you are right now, that you are judging something is an argument or not because I still remember a comment made on list in 2009 by one of the members of the current Board and the comment was "I want ?? it too" that was kind of a ? argument.

AUDIENCE SPEAKER: Hunkry. I think it's very good that you have brought this forward and it is very good to discussion these issues and for everybody to be clear how the processes work and I have been following the discussions and I have the impression that you have done a good job so far. Thank you.

SANDER STEFFANN: Thank you. Very useful to get this positive feedback. One thing that goes along with this of course, is that if you are discussing things on the mailing list, provide arguments that we can discuss. Mess /APBGS like, I don't like this, well, (messages) it gives us a bit of feeling that there are people who don't like it but as long as there are no substantial arguments we can't do anything with them, so just a reminder that we really need constructive feedback on policy proposals.

AUDIENCE SPEAKER: Peter Koch, random individual. A comment like, I don't like this, gets lower weight than a comment like, I like this.

SANDER STEFFANN: I can give a quick answer to that. If we say ?? I like this, then there is backing documents that you approve. If you say, I don't like this, we can't actually help you in making it better if you don't provide arguments. So if you say you like it, there is a policy text that you are liking. So, that is basically the reason. Koch Koch just because I have a ticket for the bad idea ferry my voice is counted whereas when I refuse to enter the bad idea ferry I am not counted?

SANDER STEFFANN: No, the PDP clearly states that all changes, all opposition has to be justified with supporting arguments so that is what we are applying.

PETER KOCH: Maybe that is the

GERT DORING: Maybe that is not the problem we are not particularly not counter your argument if if we have a couple of people /SPAOEUPBG and say yes I want this to become policy and somebody say I see a problem here in this specific bit, we can work on amending the document or amending the policy to take this into account and reach consensus, or if it's something that cannot be fixed, more people can follow the line of thought and say, oh, yes, Peter is right, there is substantially wrong ?? something substantially wrong with the policy proposal, it's not just Peter's gut feeling that he doesn't like it because it was endanger stability of the Internet, so it helps the rest of the Working Group if the I don't like statements have a reason why because then they can make a more educated mind, and it helps to us see whether it's something that can be worked on while just stating, I don't like it means, well, you don't like it but we don't know why you don't like it. If /T* helps if there is a reason to do something with it.

SANDER STEFFANN: Just to be clear. If somebody doesn't provide a reason, it is feedback for us but we ?? how can we deal with it?

PETER KOCH: So to put this in a bit more context if I may, I see the queues growing. I am not saying you are doing a wrong job and your assessment is wrong, I think you are really giving the right assessment of how the process is written down at the moment which means that it would be biased towards change and that may or may not be OK, and if the community likes that, that is OK, but there is this fuzzy danger there that this bias towards change is opening the thing to capture and we have seen these things happen before where, like, one of the assessments on the list was people are voting for free beer, and I ?? if you vote for free beer, I can't say well I don't like that you get free beer but there is hardy any argument I can usefully make (can) I know this is hand waving but if there is a bias for change which may be good overcome inertia and so forth but where is the safety belt. I am not saying again your assessment is wrong but there is a risk in the process here.

GERT DORING: There is good arguments against free beer and that means the next morning at 9:00 nobody will show up. But, yes, I am actually seriously taking into account and listening and not just making fun of you.

WILIFRIED WOEBER: Just very briefly, Peter, I read you and I think there is quite some good thing in it to think about it, but the ?? I like and I don't like sort of plus one and minus one is not symmetric as I read the process because an integral part of the policy proposal is the motivation and what the benefits are, so if I submit the plus one in speaking N G, to plus one, I implicitly agree with the rationale and with the description like why this is submitted, what the benefits would be. If I would submit a minus one, I would at least expect that I point to, if there are any, to point any drawbacks, like in the assessment of these policies there usually is the benefit and the potential drawbacks. So I think Peter, what you are saying is worth considering, but personally, I don't think the plus one and minus one is symmetric in the sense, of of the vote we had yesterday in the afternoon, I do like the new judging scheme or I don't. Thanks.

RUEDIGER VOLK: With the SIM /ET tree, I am having some problems. If for one direction of a statement arguments are required, I wonder why for the other direction, not. If you are saying and Gert was hinting in this direction that the positive confirmation actually implies the arguments that have been brought forward before and, well, OK, we will have to be careful that in all cases where a statement is confirmed, there have been actually arguments and those are clear.

AUDIENCE SPEAKER: Kurtis Lindqvist. I think there is a few things here. First of all, thank you for making the presentation and it's quite good, it's clarifying this fact rough consensus doesn't mean that there is actually allowed to be disagreeing voices. When it comes to what Peter asked, I think that it's, the symmetrical part is important because, and that is one part of the problem because I believe that just because I put forward a proposal no one is against it doesn't mean my proposal should pass. It's important there is support for change and for doing this. I also think the other part is that I can disagree with a policy proposal just because I think it's bad policy. That doesn't mean I have a lengthy list of issues what have I believe is bad, I just think it's bad policy. I think you have to keep that clear, it should be OK, I think this is bad policy, I don't agree with the proposal in its entirety, I don't have to do a lot more counter arguments. That said, I think what you are trying to address, what you started out saying earlier, you very often have very few votes, and then it becomes very tricky when we have policies that we need ?? we know we need and there is some people for, majority or large /PHO /SKWRORT and very few people against and the question becomes will the ?? the perception might be those people in favour carry more weight than those people against and I think the general problem you are trying to address is there are way too few people speak up and that is why we are having this discussion. If we all voiced our opinions we wouldn't be able this discussion. I think that is the real problem to solve.

SANDER STEFFANN: Thank you.

AUDIENCE SPEAKER: From Netnod. Well, it seems like we have these discussions every five years or so. It doesn't mean that they are not valid discussions because new people coming into the community so I think it's worthwhile. I think Peter's points are very valid, but I think there is a danger here in talking about what carries the most weight, because that is the whole point about, with consensus, right, we are not voting. So it's not about we have got, five, four and ten against. The whole idea is we are trying to figure out, so if you are against it, why are you against it. So I think, you know, it's important to not think in those terms, to actually think about how can this discussion bring us forward, and I think that is where the Chairs play an important role, if someone says no, I am against it, to prod those people, or I am for it, if that is not clear, to figure out why and how strongly are you against it; are you just against this part of it or not. So that is the only point I want to make, that I think it's about bringing the discussions forward, not about getting into dead locks where you say I am against the four.

SANDER STEFFANN: Yes, exactly, thank you.

AUDIENCE SPEAKER: From domain /SA*. I think the situation is not as asymmetrical as it may first appear. Obviously, the people who are for the proposal have stated their reasons. The first person who speaks against the proposal should, from my view, state some reasons, just like the people for the proposal has stated the reasons, and then anybody who says I agree with the guy who disagreed, they are agreeing with his reasons and they will be counted just like the people who just say, I agree with the proposal, will be counted and I don't see such a terrible asymmetry.

SANDER STEFFANN: Except the fact that we don't do counting, but really look at the content, but yes I know what you mean, thanks.

GERT DORING: Indeed, agreeing with arguments against the proposal doesn't need another justification. So saying this will break Internet on Mars and five other people and saying Peter is right. /KWRA*PB is doing the sums today, plus one to minus one.

SANDER STEFFANN: If anything else, put it up on the mailing list.

(Applause)

GERT DORING: OK. Now, next item on the agenda, Rob Blokzijl, RIPE Chair. One of those who have been here far longer than I am, so he knows how all this policy stuff came to be and now ventures to get it all sorted out, I think. As another matter of introduction, the document that this is about was sent to the mailing list last week so you could have seen it.

ROB BLOKZIJL: There we are. IPv4 maintenance policy. Let me show you the problem definition. The 12th of August, later this year, we all learned earlier this week from Geoff Huston that is the day when we hand out the last of the IPv4 addresses from the free pool. That is, of course, an historic date. But more interesting is, try and move yourself forward by one year, two years, three years, and then think about IPv4 policies, if you can still remember what IPv4 is, of course. We have an impressive collection of documents which all relate to IPv4 policies. We are even in the process of creating more today and we should hurry because very soon there is no more IPv4.

What I thought a little while ago, well almost a year ago, is that it will be extremely difficult in three, four, five years from now, when, probably, half the membership of the RIPE NCC has never seen an IPv4 address in the world, because they started their company recently and are IPv6 only, but IPv4 is still predominantly, is widely used on the Internet so they have, somehow, to connect to this mysterious old world, and then say, OK, how does this work? What are the policies? Oh, yes, this document, I think that one also applies, and this one refers to another one which should be somewhere and that is completely a mess. Also, yesterday, in discussing some of the current proposals it was quite obvious that even today when we are all still very much into the IPv4 policy setting world, we have created sometimes confusing circumstances. It was, I found it highly amewing that at one moment yesterday, we were discussing whether something we agreed (amewing) should be fixed, should be phrased as separate document or as amendment on an existing document (amews) or whatever, strong opinions were voiced. I think if we even today are not quite sure any more what we are doing with IPv4 policies, we are sure about one thing: That in one, two, three years from now, we are even less sure.

So, I am going to propose that we are trying to sort this out. As I said, the pool of IPv4 addresses is running out quite rapidly. We have been saying that for quite a few years but this is probably the last RIPE meeting where we can still talk about a pool of available addresses and the next RIPE meeting in September, no longer.

There is a very strong need to keep an eye on IPv4 for many, many years to come and that is because we have to keep the registry in order. Somewhere, there should be documented information of who is using which part of the address space. That is called the registry. Do not confuse that with the RIPE database. The RIPE database contains a whole ?? much wider set of extremely useful information, including Limericks, but we are ?? when we are talking about the registry, we are talking about a well?defined set of data, which, for practical purposes, of course, resides in a database, the RIPE database.

When the IPv4 pool is exhausted, many of the existing policies are no longer valid because most of our policies deal with allocation and that is a game which is over very soon. There is no more free address space to be allocated by the regional registry, the RIPE NCC. So, those policies or part of the existing policies as referred to allocation, become meaningless because they apply to a situation that no longer exists. But other parts of the complete set of policies has to do with the need for registration, has to deal with transfers and a whole lot of other things which are still valid after the free pool has expired.

So I think we need to consolidate and simplify all this in one IPv4?related document.

So, a while ago, I went to /PHAO*EU good friends the RIPE NCC because (my) I realised that registration is ?? will be the most important part of our IPv4, and therefore, for many years to come registration is mainly a technical issue, so, in order not to contribute to the confusing set, I thought I'd better talk to the technical staff who was doing registration, who is keeping the registry up?to?date. So I had many, many sessions with good people from the RIPE NCC registration department. They reviewed key policies like the address allocation and assignment policies because you never know what is hidden in there and it might still be valid. Things like temporary Internet number assignment policies, we looked at legacy space, the last /8 policies, transfers and everything we could find.

As I said, maintaining the registry will be the most, in my view, the most important IPv4?related activities for many years to come. So, whatever in my view we are going to ?? not to develop, but going to restructure our set of documents and our way of working should not deviate from this aspect.

And the ?? well, I sometimes call the maintenance policy, I don't know whether policy is the right word here so don't take this too strict. The collection of what remains should include the description of the contractual relationships in the ?? in our service region. You say, oh, that shouldn't be too complicated; well, look at what we have succeeded in creating today. We have RIPE NCC members, well they have a contractual relationship and there are in your service agreement there are statements about the need to keep the registry in order. That is fine. But then we have, or we don't have, relationships with legacy space holders, which is, again, in most cases we easily describe they are either a member of the RIPE NCC and wave contractual relationship but we never talk about their legacy space, only about the space they were allocated by the NCC; we have PI space holders whore who have either a direct relationship with the RIPE NCC or have a relationship with one of the members of the RIPE NCC or have no relationship at all. And so all that should at least be documented and in the next step is to find a way to simplify this and that is partly policy and partly administrative and I think there is a role for the membership to play here, there is a role for the people who are affected by it to play here and there is the role for the RIPE NCC Board to play here because the at the end of the day, money is involved.

On my list, transfers should be dealt with in this document. When I say "dealt with" what I mean is we should collect all the various different transfer policies and put them in one consistent document. You will find that you will be surprised if you read it. The current Teixeira glued together in one document. You will find there are inconsistencies in the use of language, inconsistencies in definitions and these things will have to be resolved, otherwise they are a source for confusion or a source for gaining in the future.

So transfers allocations from the last /8, unforeseen circumstances. We have text referring to that. Legacy space, I mentioned already. Temporary assignments and I might have forgotten something on this slide.

So, the question is: Do you think this is a worthwhile exercise or you would prefer forget about it it's a mess? Let's file it in the history department and forget about it. I think that would be the wrong approach because IPv4 allocations might be historical but the use of IPv4 for many, many years is an important part of the Internet and should be well?documented and well understood by people and I think putting all the relevant aspects together in one document helps people to understand things and also helps to judge whether you forget something.

So, what I see as the next steps is I send around last week a draft of such a document. It's by far not up?to?date because only yesterday we were talking about new policies or change in policies, so first step would be to go, first step for the authors would be to go through the document again and make sure that everything that is relevant to IPv4 address policy is contained in that document, send it around to the mailing list for further comment and then, based on the feedback, my hope is that we reach a stage where we can say, OK, all the policies which are still valid which we have adopted in the past are now well?documented in this single document so let us approve through our normal procedures this document as the ultimate IPv4 maintenance policy document and declare all the bits on which it is based as historic and then we have one document. Does this freeze our IPv4 maintenance policies in the future? No, of course not; it's a document like any of our other documents. If there is a need to add things to it, that will go through the normal procedures. If there is a need to change things, it will go through the normal procedures. But I hope that in the coming years it will help us to keep the IPv4 address space in our region healthy, meaning the registry healthy; it will help us to understanding how IPv4 is being used in this region, and it will help us to not to waste too much time on confusing ?? on things that are confused because we have an ageing documentation and there are less and less people who remember which documents are relevant in which circumstances.

I think that is what I had to say. So this is not a policy proposal; it's a proposal to clean up the ?? not even to clean up policies but to clean up the way we have come toed our policies and to make it (documented) more future consistent?looking, to make it more consistent for future use and to put some emphasis on the importance of registry, which we always all understand registry is important but we never wrote it down explicitly. Comments?

GERT DORING: Thank you for undertaking this effort.

ROB BLOKZIJL: It's not only me. As I said, there are ?? without a couple of friends from the RIPE NCC staff, it would not have been possible.

GERT DORING: Thanks to all the team but somebody had to sort of like start the effort and drive it forward.

NIALL O'REILLY: Could we go back two slides, please.

ROB BLOKZIJL: I hope so.

NIALL O'REILLY: Next one. That is the one I wanted.

ROB BLOKZIJL: Niall, I know you like to talk but this can be I think a yes or no. But you may expand on that.

NIALL O'REILLY: Well, it's not that short, honestly. I am reminded of when I was at school I might come in on a Monday morning and explain to the teacher I was going to do my homework but... and this man was a great big man who could probably crush any of the pupils with just one hand but his bark was much worse than his byte and in a /THUPBD erring voice he would say "O'Reilly, the road to hell is paved with good intentions" I am not necessarily saying this is leading to the road to hell but there is a lot of homework to be done and the different policies that we have might be seen as the different head waters of different streams which most flow through a land skip and this represents the circumstances that have to be taken account of, there are hills here and mountains there and obstacles in the way and the streams will have to flow on their natural way. And it's not by writing a document, redrawing the map that we can make the Sava join the Danube. It's also not worth digging a big canal because that is too much work. We could make the rivers come together at Novi Sad, we have to take account of the circumstances and do the homework, and then the streams will come together in the right place. If we try to constrain them to come together in another way, we will be on the road to hell. But apart from that I want to echo with Gert said, thank you for leading this initiative, it focuses our minds on something that we should have focused on before now, and there is a lot of work to be done to make it work outright. I want to sound that note of caution.

ROB BLOKZIJL: A comment: I was very reluctant in using the word "policy" in this context because the policies in this document have been ?? are the result of normal process. It is more difference in documentation than create ?? than dig new canals. But yes, well noted.

NICK HILLIARD: INEX. So, I do think it's a good idea to have a consolidation of documents. And there is a lot of reasons for, it makes it's a lot simpler for people, it makes it simpler for new end users as well who have to pass a lot of documentation on to their legal people and it reduces cost and burden there. I am a little bit concerned that the summary document that you wrote in its current form has removed a lot of the existing IPv4 allocation and assignment sort of not quite juris prudence but there is an awful lot of wisdom in the ?? maybe not wisdom in the documents but certainly policy there that is not in the summary document that you made. Now, the concern I have with it is that the last /8 isn't really the last /8 because according to the policy that we have for the last /8 any address space which is returned for whatever reason to the RIPE NCC, for redistribution, goes back into the last /8, so I think for the foreseeable future and by that I mean decades, we are going to see bits and pieces of address space going into the last /8 for reallocation under the policies that we already have. And on that basis, I think we need to be very careful that any summarization document that we have doesn't remove or change the policies in any substantial way.

ROB BLOKZIJL: Yes, you are absolutely right. I must admit that we are working on this sometimes I was tempted and could not resist the temptation to let my private opinion on some of the policies we had, be reflected in modified text. What I will promise is that I will take a step back and make sure that all the accepted policies we have currently will be in their completeness in this summary document. It should not be a document that says well, it's like this but ?? it should really contain all the policies as adopted.

NICK HILLIARD: Exactly.

ROB BLOKZIJL: Exactly. Yes. But some policies don't make sense any more after a couple of months from now, so, we will see, but as I said, we will do a rewrite of the document and pay a special attention to the fact that it should really contain at literally all the existing policies. I can already warn you if you then read it through in one go you will find inconsistencies but that is not our fault; it is existing inconsistencies which escaped people because they never read through policies in one go. And that is something that the community should debate and resolve.

RUEDIGER VOLK: I very much resonate with Niall's saying that yes, the intentions and the goals are something that we think are nice but the approach and the presentation actually seem to me like making things more fuzzy than they should be and reforming our legal and administrative system is not going to work very well when we just start from scratch writing something simple without actually listing which of the laws we are replacing and which of the administrative procedures we are fixing and there is also a big problem. There actually needs to be done some analysis of what policy questions or administrative questions have we not covered yet, so just saying well OK we are collecting all the stuff that is around and well OK, not officially taking up the question of well, OK, what is going to be obsoleted and actually replaced. There is also the thing that there probably are things that need to be tackled and that need to be clearly identified and addressed and go into the final picture. So I think the problem that we are facing is actually more difficult than can be addressed by the approach of saying we are writing is a summary of everything that is around there, and by the way, on doing that we are simplifying a little bit.

ROB BLOKZIJL: No, I think you have misunderstood what I tried to say. We are not writing a summary; we are collecting what exists and we are not rewriting and simplifying things; we are just collecting what exists and then it is up to you, the reader, to conclude that there is holes, inconsistencies and missing things.

RUEDIGER VOLK: Then I want you to actually list on the paragraph references of what you have been collecting.

ROB BLOKZIJL: That can be done, yes. That sounds workable for a working document.

DANIEL KARRENBERG: Speaking on personal title. And I just feel like Remco, I had really made the resolution not to speak up in this particular thing because I think I have done my duty as far as policies are concerned, but let me say this ?? and this is not aaddressed to Rob, this is aaddressed at the room ?? when we run out of IPv4 unallocated pool, the landscape changes. And we are not changing the landscape, but the landscape changes. And I think we should really realise that we will need a more radical approach of basically seeing what is the landscape like and what kind of policies do we really need and what do we really want to achieve. And this is not going to be solved by collecting the policies that were applicable to the previous landscape; this is going to be realised by looking at what is the landscape like and what do we want to achieve landscaping it, and so what are the goals? And then making policies that are achieving that goal. So I am arguing for kind of a fresh start, not by building on the existing system but a radical fresh start. And yes, we need an analysis then what is ?? what is changing and what expectation ?? previous expectations that might be there, are being violated, but I think we have to face it that the landscape is going to change. So building on the old ?? building on the conglomerate of stuff that we have that were applicable to a previous landscape is not going to be the best way to do this.

GERT DORING: I would like to stop the discussion here because we are taking away time from the next two discussion items, so last comment, please.

SPEAKER: Actually, I wanted to pass on a question to Daniel.

Daniel, did I understand you right, that you are saying, okay, Rob and your staff going out to collect the historic stuff is not addressing the problem?

DANIEL KARRENBERG: It can be a contribution, but I think I want to prepare us for the fact that this is not going to arrive at the solution. We shouldn't think about incrementally arriving at the solution. That is my whole point. And actually, I am hopping that some people will step up to the plate of actually creating something from ?? not from scratch, but something that is adopted to the new landscape without doing it in an evolutionary way because if we do it that way we will get derailed.

ROB BLOKZIJL: If I may have a last few sentences: My way of viewing this is very close to Daniel's and in my practical implementation is that I want to focus on the role of the registry because that will be the constant in the IPv4 landscape for many years to come. The registry should be well kept, well?documented, in order, because that will be used by operators, that will be used to generate certificates on demand, that will be used for a lot of other things.

The remaining policies like the last /8, the transfer policies, they are either of limited time relevance or they are, anyhow, of limited importance compared to the total of the IPv4 space and they are all ?? they all hang together with the registry, so I think an emphasis on the registry might be a way to have a fresh look at it and I agree with the Chairs, enough said. We have a mailing list.

GERT DORING: There is a last last comment.

NIALL O'REILLY: I just wanted to add that, yes, I agree the focus should be on the registry and the future of the registry, and also we have said enough for today. Over to the mailing list.

GERT DORING: What I keep hearing is there will be ? full in the spirit of this meeting and I also keep hearing that not all of you have actually read the document yet, so I would encourage you to read through the document, figure out what is good and what is not so good because there is stuff that is definitely controversial in there, and please bring your feedback to the mailing list and then we go to the next iteration of the document and if we are sort of happy with the shape, then it can become a formal policy proposal. Because, well, having a PDP we cannot just say all policies are gone, we are now using that. It has to be formal. Thank you. Thank you.

(Applause)

GERT DORING: Just two minutes for me because nothing much has happened on that topic. Two RIPE meetings ago, I came up with the idea of taking all the different colours of IPv6, blocks that we give out, and sort of a builder unified IPv6 policy that takes PI, PA and whatever they might be, into account. I presented that and got positive feedback from the room. Rolled the ?? wrote the draft document together with Sander, got positive feedback for some discussions about the charging scheme unsurprisingly, and a promise at the last RIPE meeting that I would make more formal policy proposal out that have and that hasn't happened yet.

We have started work on the formal document with the help of the technical writers at the NCC, and then it sort of sat on my desk and rested well. One of the reasons for dragging my feet was that we had active policy proposals that affected the IPv6 policies so having competing proposals affecting the same bits of policy is never a really good idea. So I wanted to wait for those those to get out of the system, either withdrawn or accepted. This seems to be happening now, and, yes, I plan to resume work on this after the meeting. Any time soon. So I am not specifying a time?line but that is what we have, that is what has happened, and it's not forgotten.

So much for from me. Now, we have a volunteer to lead some other policy discussion.

On the 2011?04 policy proposal, we received a couple of comments that said, yes, this policy proposal is fine but the additionalicalication policy sucks, and since 2011?04 was not meant to be solving additional allocation policy issues with HT ratio and whatnot, we considered these to be out of scope of that policy proposal, but promise to take up the subject and try to figure out whether there needs to be something done and whether we can do something, and Jan volunteered to lead that. Thank you, Jan.

JAN ZORZ: Good morning. So, I am here as a volunteer, not against my will, obviously. When we discussed the /29 extension of initial IPv6 policy, we encountered some comments on the mailing list that were at the same time irrelevant and at the same time relevant. They were relevant because they were real and irrelevant to the current proposal. So, my question is, is the HD ratio mechanism too complex?

So, I was particularly concerned about this comment, that: Still having the "initial request" policy being severely more relaxed than the additional request policy poses looming problems for those who will have to request more address space later on but is a step into the right direction." And this one coming from the same author "the problem is that the additional allocation policy is far more draconian than the initial allocation policy." HD doesn't matter to the original. That is clear. We declared this not to be relevant to 2011?04. But I would like to ask you: Who of you actually understands the HD ratio mechanism? Show of hands. And I did not see even the Chairs raising their hands.

GERT DORING: I thought I understood it and I looked at it again and I am not so sure any longer so I didn't raise my hand.

RUEDIGER VOLK: Does it really matter to understand the strange ideas behind the formula? There is this formula and that gives the criterium and selecting this is arbitrarily to some extent.

JAN ZORZ: I don't know. Let's discuss that. Here is a possible question. I thought first to set this as hypothetical question but then after some discussion, we realised that is possible question so in the spirit of the 2011?04 the first understanding with 6 RD and transition mechanisms, if I get /29 and I use /30 for some reason, for some transition mechanism, that that part, the first 30 cannot be assigned because it's not actually used, just tiny fractions of the /30 I used because the 6 RD is so heavily inefficient addressing but it is like it is and we are stuck with it.

Up to what percentage do I need to fill up the remaining /30? So because I either don't understand the HD ratio, I went for the cheat sheet, and I found that well if you have /29, you have to fill it up until 32%, but half of it is still heavily not used, and it will, nil get rid of 6 RD, it will not be used. So the answer is, 65% of the remaining /30 that is not wasted by the weird transition protocol, must be used. So my question is IPv6 is going us really relaxed way of doing the addressing planning and addressing schemes and we can play with bits and we can mark whatever we want within the network portion of the addresses, so how tight must my address planning be to achieve that? And this was just one example, and I am sure other situations are ?? might be no better. So, I would like to open a discussion, because I was volunteered, and do we want less restrict HD ratio? Do we want agree with HD ratio at all, do we need any more mechanism to understand when we need additional IPv6 allocations, right, and who will work on this? Do we need to work on this at all? So, please, some feedback from the room.

GERT DORING: I see one of the original culprits come up.

GEOFF HUSTON: APNIC, certainly I was the Co. author with a number of other conspirators about revising the original HD ratio setting from .8 to .94, and there is certainly a wealth of good thinking behind that in comparison to what we were doing with v4, because what we were doing with v4 was, you have to fill it to 80% and we were finding that was extremely problematical for many but we said it's scarce, knock yourself out, spend more money, work harder. But v6 wasn't meant to replicate the pain but we also weren't willing to say new efficiency ratio.001% so we kind of adopted a thing that said if you are large it's hard to get a high density. If you are a smaller it's a little bit easier, the HD ratio actually works. However, your line of argumentation here, I would would say is logically fallacious. You have said I have got a /29 and I am using half of it for transition. That half is 100 percent utilised because it's being used for transition so. The answer is, what is the other half being used for, one half is already at 100 percent used. Not zero, as you are positing here. To then go I have misunderstood that and say the HD ratio is all wrong, doesn't strike me as a logical chain of thought. So I am not sure the example leads to you this conclusion. What this conclusion is kind of saying; I am not sure I understand the HD ratio but I think it's wrong. What is the HD ratio? What it's really saying is that a really simple network is probably one tier, one LAN, one switch, and it's probably pretty easy to say, it's full when it's about 80% full. But a regional network with a number of points of presence has a number of levels of structure? Two? Three? Four?. What is the efficient fill ratio at each level of structure? 50? 60? 70%? But if it's three levels of structure, what is the result and fill ratio? Well, it's .7 times .7, that is point 7 cubed, it's a logarithmic function, that is an HD ratio. In other words, there is some relatively clear thinking about this that actually exhibits some understanding that larger networks have more structure. But as you put more structure in, it's harder to be as efficient as a small structured network. Do we agree with that thinking? Have we experienced this not only in the Internet but in telephony and many other kinds of systems that have structure and addressing. Our experience says yes. I don't understand logs, neither do you. There are people who do and that is wonderful, and they have said we are able to model this world using exponentiation of logs and I go, cool, let's use their knowledge and apply it here. That was the reasoning behind last time; I am not sure anything has changed. Thank you.

SANDER STEFFANN: One comment to Geoff, you said if you are using half of the address space for 6 RD then it's in use. The policy says that what is in use is only what is given to end sites. So if you have whole /30 of 6 RD and only ten end sites.

GEOFF HUSTON: Think hard ?? quite frankly, if I am using that prefix for transition I can't use it for something else. Look at 6 RD. What you are saying is part of the policy is broken, it's not an HD ratio issue honestly.

GERT DORING: It's an example where people come up with numbers that might not suit them. It's not actually a real word example where somebody came up and said this is causing me pains but something that is there to get the discussion out of. We are not having that specific problem; we are just figuring out whether we have a problem and whether we need to fix it.

JAN ZORZ: That was just an example that first dime my mind, OK. Let's not stick to the 6 RD.

RANDY BUSH: Randy Bush, IIJ. I will show my age. I really appreciate the socks that the communication people gave us. In Amsterdam could they give away slide rules.

JAN ZORZ: Note taken.

AUDIENCE SPEAKER: Aaron Hughes from 6connect. An issue has come up in the ARIN region as well, and not because math is hard, let's go shopping, I have to fully agree with Geoff's statement earlier but rather because we are promoting early adoption and so many organisations checked the box to say I will take my default /32 and are coming back for subsequent allocations without being properly utilised. I do think we should make it easy on them to get subsequent allocations just because they happen to fail to plan properly, not having the experience. One of the things that I have suggested on the ARIN region is that we simply say once you have tied down a block for whatever definition of tie down you are using, as soon as you assign the first customer assignment, consider it utilised. Long?term I think HD ratio makes perfect sense, but for the short?term, for the early adopt erstwhile we are continuing to promote v6 adoption, we should not make it difficult to get an additional v6 allocation if we made a mistake having only planned for the first time writing a ten?year allocation of an assignment plan.

JAN ZORZ: Yes, I fully agree. Do I hear from the room that we don't have to work on this? That there are no concerns, that there are only individual people randomly speaking on the mailing list and just trying to make it at problem?

GERT DORING: To address that comment from the ARIN side, with 2011?04, any /32 holder can now just come up and say, when that policy is in effect, can just say, I want a 31, 29 now, without anything to show, so those that have not done their homework are taken into account now. It's really if you come back and say my 29 is full and I need a 22, what do you need to have to show?

AUDIENCE SPEAKER: Norway. Just want to kind of support the things that Geoff and ARIN said because I have been working a long time with IPv6 planning in my own company and did I the common mistake of getting a /32 before I thought of it but now when I started to think of it, I see that the /32 I got is too small, so I now need to find a way to make that sensible for me in my selling and the HD ratio by that means is good but also I wish to have some early adopter stuff and maybe should also visit 6 RD utilised or not discussion, but I am just ?? it makes sense, everything, so thank you.

JAN ZORZ: Any other comments?

GERT DORING: From what I keep hearing, this sort of reflects the feeling that I personally had, that why the math is sort of complex, there is a table that will show you the answer coming out of the math in the appendix of the policy and the extension of the initial size. And for additional allocations to a 29 would actually solve half of the problem being mentioned, and I don't see anybody really standing at the microphone and saying, HD ratio needs to go, or the number needs to be .6, otherwise I cannot run my network. So I am closing this. I thank you for bringing it up but I don't see any need to do more detailed policy proposal on that since nobody actually described the problem to me, except stating that it's all rubbish without going into details. So, of course, if you disagree, come up on the mailing list, state ?? explain why it's not working for you and we will find a way to handle that, but unless we see some specifics of why it's not working, there is not so much we can do. Thanks for standing up there waiting for the tomatoes.

(Applause)

GERT DORING: We are sort of in time, we have one last presentation from Nick Hilliard. I have seen him before, he is hiding in the corner. Could we jump directly to Nick's presentation, please. We might overrun a bit into the coffee break, but I think we should be fine.

SANDER STEFFANN: I just heard there are no slides.


NICK HILLIARD: Hello, Nick Hilliard from INEX. I have no slides on this. But I thought I'd open a can of worms, and here it is. PI assignments from the last /8. Now, the situation is, as it stands, that we have a policy regarding the last /8, which allows allocations to local Internet registries, and while this works quite well for the large number of LIRs who are present in this room and who are possibly present on the address policy Working Group mailing list, it doesn't necessarily work well for the very large number of businesses who depend on provider independent assignments for their businesses, so there is essentially a bias in favour of RIPE members and LIRs with regard to the resources in the last /8s. So this policy attempts to redress this imbalance.

I don't have a copy of the text here. It's been sent to the address policy Working Group Chairs, and hopefully we are going to get it floated on the mailing list fairly shortly. But the text is essentially very simple; it says maximum of /24 per end user and otherwise it's the same in principle as the policy for the single allocation to LIRs.

There are concerns with it. It's a first draft of the text and I am sure a lot of people are going to have a lot of comments on it because PI tends to be one of those issues that really gets people quite excited, so hopefully we will see it on the mailing list fairly shortly and I welcome everybody's comments. Thank you.

GERT DORING: That was faster than I thought. Don't run away. We have eight more minutes until coffee and there is nothing else on the agenda so you get to entertain us.

(Applause)

GERT DORING: He is still running away. So, if one of you already has comment on the idea of having a PI in the last /8 policy and what we should do and not do, yes, we have five more minutes to go into that. If you all feel that, oh, yes, IPv4, do whatever you need, and let's go for coffee, then that is fine with me and yeah, well, I just go to the next slide that says thanks for your attention and enjoy your coffee. No any other business? Then, here we go. Thanks for being here, thanks for helping shaping the policies. Enjoy your coffee and see you in Amsterdam.

(Applause)