Archives

These are unedited transcripts and may contain errors.

Address Policy Working Group

Wednesday, 16th of October, 2013, at 11 a.m. :

GERT DOERING: Welcome back to the Address Policy Working Group. I am not making any more jokes about no more addresses because we are focusing on IPv6, because there is plenty of addresses.

First thing, one minor administrative thing, there will be an AC /NC election at the Friday morning Plenary, so that's the address Council, number Council of the NRO that then goes to the IANA, or ICANN. Since these folks are representing, well, you, it makes sense to be there and cast your vote. I'm actually saying vote because well there will be voting, which is unusual, but that's the way what we do for the AC /NC representative.

KURTIS LINDQVIST: Can I ask you a quick question. If I can't make Friday morning and I still want to vote, can I vote beforehand?

GERT DOERING: I'm not sure beforehand. I think it's people in the room on the Friday morning Plenary. You would have to ask Rob Blokzijl because he is the one actually running this, I just relay the message that it's there.

So, now we start the first regular agenda item. Since the proposer has, well, a role in the community and might not be seen as neutral if he came up with his association, he has been asking me to call him random Jan, no hats. So welcome random Jan, no hats, with some thoughts on our RC 2119 and RIPE policy documents.

JAN ZORZ: So, good morning good people of Address Policy Working Group, I'm Jan. I'm completely random member of Internet community, no hats here and would I just like to share a story with you.

I had the privilege to go to Zambian this year. There was AfriNIC meeting. I was sitting in the Address Policy Working Group and there was the text that provoked me a bit. They were talking about the LIR should also plan to announce the allocation as a single aggregated block and so on and so forth. And they said, oh, this must be removed because it's too prescriptive and so on and we should be able to split the allegations for traffic engineering and so on and so forth. I couldn't keep my mouth shut. Hang on, hang on. Read this again. It says an LIR "Should." Should means that you do it unless you have the good reason not to. And I said so this sentence is perfectly fine. You just need to tell the AfriNIC stuff to interpret it as a should not as a must. And I said there is RFC 2119 that defines the language for the RFCs what should means and what must means and then later on...

So later on I had a discussion with some RIPE NCC staff and I heard that the policy should be black and white. And I said no the policy must be black and white. And then we came to a conclusion that maybe the fraction of community understands "Should" in a policy in a different way from the other fraction of community that understands "Should" as a "Must" because policy ?? I think that "Should" used in a policy that means "Must" was used there just for politeness, not saying "Must" but you should. But is this good? So, how can we define the interpretation of a "Should" and a "Must." So RFC 2119 that is used in most RFCs says that "Must" is a nonconditional. "Should" is a conditional. So what is RFC practice? We put this sentence in every RFC. The key words "must," "must not," "require," "shall," "shall not," "should," "should not," "recommend," "may" and "optional" in this document are to be interpreted as described in RFC 2119. There is a really good description of how these words are used. We did not define what was the end user, we did not define what is the end site. These are all the words that we are using in the policy language.

So my question so the community is: Do you see this as not a problem and we go home, we do nothing? Or, should we interpret "Should" as a "Must" because this is how it is being used today? But this still fractions the community understanding. Should we adapt RFC 2119 specification for the future policies say that these words are to be used as in RFC 2119? Or should we include the other recurring terms and words? So, these are my questions to this community. And I will ask you to go to the mikes and tell us what to do. Thank you.

AUDIENCE SPEAKER: I think if there is an RFC about it, we should really go to arguments not to use the RFC.

JAN ZORZ: Anyone else?

HANS PETTER HOLEN: I think we must use the RFC.

LEE HOWARD: I think we may use the RFC. To be specific, I think that before incorporating a redefinition of language used in the policies, we should do a review ?? sorry, we must do a review of the language in the currents policies to make sure that we don't accidentally reinterpret any of them by redefining the words currently in them.

JEN LINKOVA: Jen Linkova from Google: I think it makes sense to use that language for new policy and explicitly say in the beginning of the policy. The policy is used the language as defined in RFC. And then we can review the existing policy, but because the policy don't say this or that, it might be an open point of interpretation.

JAN ZORZ: So this may be the shortest policy ever.

GERT DOERING: No, I don't think we can just reput it on existing policy. What I would take the opportunity is put some attacks on the NCC. I see Andrea already nodding so I think he knows what's coming. If you find time to go through the existing text and look for occurrences of "Should" that you are interpreting as a must, and that make a significant difference and sort of like report it to the Working Group as, okay, these are bits in the policies that are ambiguous as far as our interpretation and RFC 2119 interpretation is concerned. So, you might want top consider cleaning this up. That would be nice. Okay. I see him nodding. Thank you. Wilfried.

AUDIENCE SPEAKER: Wilfried: Cosmetic surgery? Is this a topic for cosmetic surgery?

GERT DOERING: The interesting bit about cosmetic surgery is that the cosmetic surgery programme is formally over because all the documents that were considered for cosmetic surgery have been processed, so maybe it's time to restart that.

WILIFRIED WOEBER: But we may subject them to just another face lift.

GERT DOERING: It's the gist of the cosmetic surgery programme which was look at documents that have been patched so often that the text is completely unreadable and keep the spirit of the policy but change the text in a way to make it more readable. So, that would then be sort of the next step if we know which bits are relevant.

JAN ZORZ: But what do we do for the future policy and the changes? I heard must not, must and may.

GERT DOERING: I think it's a good thing for future documents we ?? I now say "Should" include a reference to 2119, unless there is specific reasons to not do so in whiches case I invite to you tell me about. So that should works was on purpose. So it's something to check with the PDO to sort of like bring it in for new documents. It's a bit difficult because it a policy change like what we had about the transfers just removes one single sentence, to change that document at the same time to say this is 2119 compliant, this is a bigger change ??

JAN ZORZ: We need to work on the rest of the text and clean it up also?

GERT DOERING: So it's larger than look at the single policy proposal. If a completely new text is brought up, that's fine. But if an existing text is just slightly changed, introducing 2119 reference at that point in time is too big.

JAN ZORZ: Okay.

GERT DOERING: But, yeah, I think the NCC is listening, the PDO is listening and we will take it into account. Thank you.

AUDIENCE SPEAKER: Raymond from Finland. I think we should /HRAOUL stick to the RFC 2119 since we are trying to make things easier area we making this more complicated by interpreting it in a different way? It's a bit strange.

JAN ZORZ: So absolutely should means must.

AUDIENCE SPEAKER: Maybe...

AUDIENCE SPEAKER: Kurtis: I'm not so sure. I think we should link to RFC 2119. I am going to echo another discussion on a totally different topic on another mailing list.

RFC 2119 and the text there is done for interim specs as a protocol definition where you can have sliding level of compliance. When it comes to Address Policy, you should not comply, it's very black and white to me. I don't think we need to have shoulds or maybes or perhaps. I think a policy document that outlines how resource new resources should be very clear and CRISP. I don't think we need to have the sliding text. It's either yes or no to me.

SANDER STEFFANN: In that case, the word "Should" is rarely used in policy text, if at all.

AUDIENCE SPEAKER: I don't think we should have shoulds, if we have a should it's a must. I think it's very black and white because a policy should be clear.

JAN ZORZ: Must be clear.

AUDIENCE SPEAKER: We shouldn't have ?? you may be get addresses depending on who the Hostmaster feels like.

GERT DOERING: In theory the policy must be clear so, that's clear.

HANS PETTER HOLEN: I understand what you are saying Kurtis, but if we are going to have a different interpretation of "Should" than the RFC texts have and from the way I seek English I can understand what you are coming from, that's the natural word for me as well when I use must, then we need to clearly define this to avoid confusion. So, it's sort of ?? we can't keep on using "Should" and think that the whole world picks the right meaning into that word if we don't explicitly define it and personally I sort of don't really care which way we go but I think there is some merit in keeping the same language as in the RFC text because it's sort of the same community reading the two texts.

JAN ZORZ: Because one part of community understands this already as defined there.

KURTIS LINDQVIST: My point is that we are now spending time on how to use the English language and I am sure there is people who know this better than me, but, again, the text in 2119 is deliberately there to leave an interpretation, and in the Address Policy we shouldn't have that. So I think it's fine use 2119 but limits it to the word "Must" or "Must not" and...

GERT DOERING: Anyway, I think the point is we need a review of the existing policy to see where it is ambiguous.

AUDIENCE SPEAKER: Right, then we should clean it up and make it less ambiguous. And by using should is not going to make it less ambiguous.

SANDER STEFFANN: I think we're clear on that, the language must be defined and indeed, when a new policy is being discussed it uses the word "Should" Kurtis please speak up if you don't agree with the word then.

AUDIENCE SPEAKER: Malcolm: I was just going to say that I like what you said a moment ago. Use language that is consistent with RFC 2119, and if that means that it generally says "Must" and the word "Should" rarely appears in policy text, so be it, that sounds good to me.

SANDER STEFFANN: So one more question, because Jan proposed RFC 2119, at about the same time I got a question from somebody else saying where are terms by end sign and end user defined and they are now spread over different documents. So should we focus this only on the RFC 2119 part, or is it a good idea to also include other terms and definitions in that document? So ?? or should it be a different process?

RANDY BUSH: By the way, I wish other people would announce their names and affiliations. It says so right here. I love how much time we can spend discussing definitions of my mother tongue, and I do have sympathies for other people who are not native English speakers, but taking on something difficult like defining end user, that probably would take on the other order of ten years considering how much time we are spending discussing this.

SANDER STEFFANN: Point taken.

GERT DOERING: I think we start with focusing on 2119, and if someone steps forward and proposes to write a document on End Users and so on, I'm happy. But we must consider this as two different projects because otherwise 2119 thing will not go anywhere. It's big enough.

JAN ZORZ: Let's make the shortest policy in the world?

GERT DOERING: Let's wait for the review...

So, next one, IPv6 PA /PI unification policy.

That slide has been year at the last meeting which basically explained what the idea was and why it didn't get anywhere because lots of excuses. Then a new idea at RIPE 66 was to find to help and that actually was a good idea because three people came forward and said yes, we would like to work on that. We see the need to work it and we are willing to spend quite a significant amount of time on it. And that's what ended in the policy proposal 2013?06, unification of IPv6 address space for PA and PI. The idea sounds very simple, abandon the different colours of IPv6 addresses and just have addresses. I have set aside about an hour to discuss the implications because that's where it gets interesting. Two members of the editorial committee are here. The third one couldn't make it and I just hand over to you.

SPEAKER: Hi, Elvis. And Daniel.

Olaf is not here but he's been active before.

Well, this has been going on for quite sometime. Why there is a difference between PA and PI? And I think IPv6 is very ambitious project trying to save the world and solve every possible problem at the same time. I mean we could have done like with AS numbers just get more of the same but that's not the case and I don't think Address Policy has some catching up to do, and this is a rare occasion to have a fresh start and not just go with the sort of IPv4 policies.

And I remember when we had to sort of make up this list with 200 IPv6 customers in order to get this is there 35 used for anything else, and well now we have PI, but I think Gert had this idea a couple of years ago, and ?? well, I'm not going to go through all the bullet points here.

So why don't you sort of start fresh and have addresses. Small blocks and big blocks and ?? it's a tricky detail. We better get it right. So who? How big? And the special cases. And the costs. That's the sort of the points we have to make clear. And this is...

ELVIS VELEA: Hello everyone. We asked for volunteers and the three of us just offered to join the editorial team and we did work for quite a few revisions. We initially started with the current policy text and we said okay, let's update this text. Then we found out about the work being done on the the cosmetic surgery and just restarted the process, including the cosmetic surgery. And after that, we said oh, but there are still quite a lot of differences between blocks, between assignments, allocations, etc., etc. Let's make it even further, move a bit two more steps and make it even more simple.

So, as said, unfortunately Olaf could not be here but I'm sure he is watching the webcast. So what we thought to do is first tell you what we think wasn't working, then tell you what we thought should be done in the policy to make it work. And we have already sent this to the mailing list. We have already received some feedback so we want to discuss on that feedback and then if anyone else has other ideas, any other feedback, then we will move forward with that as well.

So, the major problems as we saw them were that the ISP was associated with the LIR, and that has been an association from many, many years ago, and now actually the idea of an ISP being an LIR is no longer very adequate. ISPs are using PI as well. And LIRs do not have to be ISPs only. They are hosting companies, they are just companies that want to have a relationship, a contractual relationship with the RIPE NCC and be independent from anyone else.

So, the distinction that we used to have many years ago is no longer that clear.

The second major problem with the current policy is that IPv6 PI, at this moment, can only be used to number an internal network of an organisation. It can not be used to offer any kind of services to customers of the organisations using PI except for service as a service where you would offer a shared service. So, for example, g?mail, when you number your servers for g?mail, you could use PI. But still various restrictions on PI that are, in our opinion, are slowing down the IPv6 adoption.

So we said okay, these are the major problems that we need to tackle.

Then we had a few minor problems. They have three documents for IPv6. One of them for the IPv6 address allocation and assignment policy. Another one for Internet exchange. Another one for route servers and actually there is another one I forgot to mention, which is telling us what should be the assignment size between aggregation. So we said let's unify all these in one document. Plus, the current policy prevents assignments ?? actually the registration of assignments ?? of anything smaller than a /64 and while the RIPE database did not enforce policy until a few years ago, now registering anything smaller than a /64 is no longer possible. So, we are now in the position where someone might be using a /96 for something, and they actually cannot register that in the RIPE database unless they actually register the whole /64 as one block, but the /64 may not all being used or it may being used but for different reasons. That's another minor problem.

Plus we had the problem where LIRs could only request one PA allocation. If you have two networks which are separate, then you can request a PA allocation for your main network and you could examine a PI assignment for the second network, but wait, you can only use this for your internal, so if you have any customers on your secondary network, then you're stuck, you have to set up a second LIR.

So, these were the minor problems that we wanted to fix. And how did we try to fix them? First of all, we removed the differences between PI and PA. We no longer have colours. We have blocks. And that's it.

Then, we only have one single policy document, and everything is in it. So, all the others will be obsolete.

We have included a definition of the responding soaring LIR policy because up until now it was an operational thing from the RIPE NCC, but it was not actually included anywhere in v6 policy, and we thought it's a good idea to just include it in the policy as well. We removed the idea of assignment which actually says ?? okay, we have removed the assignment and we have introduced and defined the sub?allocation which actually documents the real structure of IP hierarchy that we can see now in the world. So, by removing the idea of an assignment, we have allowed anyone that has ?? that receives a sub allocation to further sub allocate, if they need to. So, maybe allow your cousin to use a /64 for their web server, or give your neighbour some addresses, or stuff like that.

And we have also allowed additional allocations for routing purposes, meaning that if you do have two separate networks, you can get two allocations. And this fixes the problem with having to use PI or having to just open a second LIR.

Furthermore, and this actually is not as it is in the current proposal. We have had a long discussion about everything that we have made in the first document and we have realised maybe some things still need to be changed, so right now, according to this proposal that we have on the mailing list, a /32 would be a default allocation. And we said no, actually our intention was that you can get small blocks or big blocks. If you want to make large sub allocations you can request a /32, but if you don't want to make large sub allocations you can just get a /48, just request it and get it. So we are no longer making the /32 default, or we are thinking of no longer making the /32 default. We are thinking of just giving the option to bold the LIR or non?LIR, to request either a /48 or a /32 or even larger if they can justify more than a /32. So this would apply to both members and non?members and the current proposal does not clearly show it so we know for sure that even after we have discussed now in this review phase, we will have a second review phase for a Version 2.

One more thing: Again, this is not mentioned right now, but are what we have done and we have realised it wasn't the intended change, was we have changed from the current policy saying if you need more than a /48 by end site you need to request approval from the RIPE NCC. We have actually changed the policy in the proposal to say: If you need more than a /48 for a customer, then you need to send a request to the RIPE NCC. And that was again not very ?? not our intention, but we did intend it to put some control mechanism in the policy because right now, we will allow both LIRs, knowledgeable or none, and End Users, to make sub allocations, and we do want to put a small control mechanism there to say if you need to sub allocate more than a /40, whether you are an LIR or not, then do request on approval from the RIPE NCC because ?? and the main reason behind this is if if you have, for example, a /32 allocation, and you need to make a sub allocation to one of your customers and they will say we want a /36 and you actually give it to them, and from that /36 they only use a /48, does that make the whole 36 used or not? And that would have been a bit complicated for the one that had made the sub allocation and the RIPE NCC to judge.

So we said, let's put an arbitrary number and this is still something that can be changed, we just came up with this number, but if you guys have another opinion whether this number should be lower or higher, do tell us. But we came up with this arbitrary number of a /40 where we say anything larger than a /40 should be approved by the RIPE NCC, and then this is not in the current policy. This is going to be updated in Version 2.

One more thing the HD ratio calculation was not very clear in the current policy. So the HD ratio was saying we calculate at the level of 56s. But you can make assignments or sub allocations down to a /64, and it was impossible to actually ?? it was not clear whether when you make a /64 assignment of sub allocation, whether the /56 that includes that /64 is in use or not. Is it just partially used? Is it considered completely used?

So, we thought let's make this clear as well in Version 2. Let's say that if anything within a /56 is edge registered, then that /56 is considered to be used. Period. And if there is nothing registered within a /48, so you have made a /48 sub allocation to your end site, your customer, your cousin, whatever, then consider the whole /48 as being in use. So 256 /56s, because the policy still allows you to sub allocate ?? well, the previous policy was saying assign ?? up to a /48 and we're not changing that, right. Anything that is /48 or smaller will be considered when we come ?? when the RIPE NCC will count the HD ratio. So, if you do make a /36 sub allocation, then only if you do register the sub allocations within it that are actually in use, will they be counted in the HD ratio so that it makes it very simple to say this is what is used, this is what should be calculated in the HD ratio calculation and actually the HD ratio is used only for when you make ?? sorry, when you want a second additional allocation. Or an additional allocation.

Oh, one thing that I forgot to mention is that if anyone has any questions at any moment, just stand up, go to the mike, interrupt me and let's have a discussion about that particular thing. So, do let us know if anything that I say here is not very clear or should be ?? and I see Tore already saying something.

AUDIENCE SPEAKER: Tore. Can you go back a few slides. Tore Anderson. The one where you are saying that you can get several allocation ifs you have different routing requirements.

And I'm not so sure if that's such a good idea. Because that is up to a /29, is that correct per allocation.

ELVIS VELEA: Correct.

AUDIENCE SPEAKER: Tore: And I know there are for instance CDN operators who have like thousands of sites all around the world that are not handle backbone, they are independently routed and the way they are currently doing this is that they get one /32 or /39 or whatever and they just insert different route objects for deaggregates of that single allocation, which converts. But under this policy, they can potentially request space up to something like a /18 in total because they could get a /29 for each of their sites. I'm not saying that that operator necessarily would do that, but that's actually a sizable chunk of the address space and do you want to open that door for potential...

ELVIS VELEA: It's a can and not a must. But, yeah, it is a good question and right now those operators cannot do anything except deaggregate or splice their allocation into multiple chunks.

TORE ANDERSON: Is that a problem? Why doesn't that solve their problem?

ELVIS VELEA: Deaggregating a /32 might lead to filtering or unusability of those blocks ?? may.

TORE ANDERSON: It doesn't because the route object is separate from the Inet6num object and if people are filtering deaggregates out of allocations right now, then Facebook doesn't work and pretty much all of the IPv6 doesn't work because that's what I think the largest CDN provider in the world is doing right now.

ELVIS VELEA: Right. What I'm thinking of if we are going to do that we are going to have to maybe update the Routing Working Group recommendation where they actually say filter on the INETum and not on the route object, so filter on the size of the allocation. But this is something that we will have to discuss on the mailing list.

SPEAKER: This goes back to the should aggregate or must aggregate, where you are allowed to deaggregate or not.

TORE ANDERSON: I don't think that it's ?? I'm not convinced it's a good idea to say okay you are not allowed to deaggregate but instead you can get a bunch of big blocks where you would use instead normally use deaggregates, because in terms of routing table slots, it doesn't save you anything.

ELVIS VELEA: We could as well just say if you do have a separate network somewhere, you can request a /48 for that network or you can request a /32 and not up to a /29. But I'm not very happy of putting limits again in this policy. We have worked a lot to remove all the limits. You get a block, you use it, and that's it. You don't have limits in it. So, adding more limits just because maybe a CGN will get a lot of space... I don't know... we'll take it back to the discussion and see.

Hans Petter Holen: From Visma. A couple of points, take the easy ones first. I wasn't aware that the HD ratio calculation problem was a problem. Your interpretation was what I would expect it to be. So, if it's a problem, then it would be interesting to track down where that came up and why.

Secondly you said something about needing approval from the RIPE NCC for something. You didn't really state what the criteria was, so I would guess it would be difficult or impossible for the RIPE NCC to evaluate such a request. It creates bureaucracy, so I'm not really sure that's a good plan anyway, to introduce new search mechanisms.

Then the overall and perhaps most difficult thing is this is actually reversing the policy proposal from the beginning of 2006 when PI was introduced in the first place. So, we used to have just one kind of v6 addresses, and we had PI introduced for a reason. And that reason was for companies to become multihomed.

Now solution of reading of policy proposal text from that time and we spent three years agreeing on that proposal I think.

My solution personally to this advice that I have given to all the companies I have worked for through times is that if you want to be multihomed, the only way to really secure that and to live overall policy changes and times is to become an LIR. You become your own registry so that you control your own addresses, have a relationship to the RIPE NCC, and participate in the policy processes. If you just get PI space, the changes over time and whether you need a direct relation or go through an LIR also one, is complicated. That's been my personal recommendation. Of course it costs more on the administrative level and it costs more on the money side. But on the other hand, we get the direct contact with the RIPE NCC.

So, yes, please remove provider independent, I don't think that's needed. But the problem here is probably not on the policy side but on the you then need a direct relation to the RIPE NCC and all the consequences on that. I think the policy thing here is really simple. The problem with your proposal is probably that you are trying to do too much at once, but I think the most difficult thing is the consequences has on the sort of contractual and financial side. Thank you.

GERT DOERING: I'm actually going to tackle that and answer the last bit. What we're trying to do is not to take away PI from people, but to solve the needs of people that are currently using PI and the needs of people that are currently using PA by having addresses. So, we're not reversing 2006?05 I think it was, we are just doing away with the distinction, which sort of like smells like getting rid of PI, but leaving the option of non?members receiving addresses for their needs, and at the same time, removing the current hurdle of if you have a PI and you want to give your neighbour an SSL host on your machine you can't because that's a sub?assignment and you are not permitted to do so. So we hope to, in the end, make the whole thing simpler and easier to understand. While the consequences of this are actually quite complicated to get there, so, this is why it's so complicated.

Do you want to answer any of the other points? Sorry, Hans Petter raised more than one point so maybe...

ELVIS VELEA: Actually I think you answered all of them, right?

GERT DOERING: I think the next one in line is Randy.

AUDIENCE SPEAKER: Randy Bush, IIJ. The point Tore raised is existing practice. It does work. And there is no serious suggestion for a better practice. So, separately announcing deaggregations of your allocation forceps receipt routing areas is a fact of life today. It's not a bad fact of life. I mean, it's one of the 93 disgusting things we do and please don't shoot it.

ELVIS VELEA: The idea is not to block or not allow people to deaggregate. If they want to deaggregate, no one can stop them. The idea is that if one does want another allocation for his second network or third or hundred, then he can actually get an allocation based op the idea that this allocation will have a different ?? will be in a different place of the world and will have a different routing requirement than this one. Anyway...

SANDER STEFFANN: I think it should be clear that the main goal of this policy is to make it more practical and give real world options and not make the policy restrict anything. So, yes, of course everything you can do today, you can still do with the new policy. It just tries to fit the real world better.

ELVIS VELEA: And basically remove restrictions.

AUDIENCE SPEAKER: Rob Evans from JAnet. I just want to correct possibly a misinterpretation you have and agree with Randy really. The Routing Working Group recommendations on route aggregation do not suggest you filter eye net numbs, they suggest within v6 you should be able to deaggregate your /32 block. But you should have root objects for everything that you want to root.

ELVIS VELEA: I stand corrected.

WILIFRIED WOEBER: I do appreciate that in Address Policy we usually do not care about money. But, if you think to the bottom of this proposal ??

ELVIS VELEA: We'll get there in just a few slides. Let's go ahead.

So, now, okay, we discussed about this one. Questions on the mailing list, and that was feedback that we have already received and we would still like to discuss. And each of these slides will get a Q&A, so for each of these slides please just again stand forth microphone and let us know if you want to add something, if you think this is okay or not.

First question was: Why limit Anycast ENUM, IXP and I think ?? well, route servers was as well was limited to a /32, why limit them to a /48, if anyone else can get a /32? And our idea was let's not really change everything. Let's not complicate the whole proposal so that if someone disagrees with the idea of an IXP getting a /32, the proposal doesn't get through. We tried, and these were the limits in current policy and this is working in current policy. So, if you think that we should just remove these limits as well, I agree, we should remove all the limits if possible from the policy and make it as clear and simple as possible, but with this one we just said let's not touch them yet because maybe that would open an can of worms and that was our initial intention and ?? what do you guys think?

AUDIENCE SPEAKER: Eric Bais. I have a question about the changing of the allocation size. Why change it to, you know, stretch it up to a /40 or even beyond that a /32, a /29, and make that similar for non?members as what you would get as a member. Specifically ?? because for the end customers for PI, anything larger than a /48 needs to be documented on justification, and also, if you need to do sub allocations, as you call, it to a customer or an entity larger than a /48, you also need to go back to RIPE for the obvious reasons, because you know, you don't want to give out a /36 or a /40 to a customer, so you need to provide you know ?? there needs to be a sanity check somewhere.

Do I agree that we need to have an arbitrary level at some point and say well whether it's going to be a /40 or a /48 or whatever, but I would like to have that the same for regular end user assignments that we use currently for PI in v6. But also what an LIR can do in assignment to an entity because it will actually make it easier and have that for God's sake the same number, and I think personally, /48 works perfectly, but you know, if somebody else says well, I need to go back 20 times a week because I assigned so much to customers and are more than /48s that I need to provide, then let's hear it.

GERT DOERING: Actually, the thing is that as soon as ?? if you remove the distinction between the PI and PA, why are you keeping the option for non?members to get space who are sponsoring LIR? It's sort of like ?? it's inevitable that a non?member can also get a non 32. So the question in bullet point 2 here is really: Are you fine with it or do you want an arbitrary limit in here? My gut feeling is that if we really want to do away with the distinction, then there should not be a special limit for non?members because then it's just a block of addresses and the distinction about the size of the Address Block is do I want to do sub allocation to, say, customers or not? If not, 48 is good. If I want, 32 or up to /29, because then I need the space to work with and looking at the 32 isn't that big as seen on the whole IPv6 address space.

ELVIS VELEA: I think actually what Eric is talking about is this, right? So, our intention here is not to limit how much a non?member would get. It's to limit how much a non?member can suballocate. And even a member. So, the limit would be right now the limit says up to a /48 per end site can be done without approval. If you do need more than a /48 per end site, then you really need an approval from the RIPE NCC because the RIPE NCC would like to know why do you need more than 65,000 networks for one site. There is no limit for how much you can suballocate to an organisation, or to a customer. Suballocate. But anything above a /48 per site must be approved. What we are doing now is we are saying okay, let's keep the /48 for the site but if you want to suballocate to an organisation more than a /40, then maybe it's a good idea to ask the NCC whether that is okay or not. And that is because we are trying to add this artificial limit on how much you can suballocate, whether you are an LIR or not, similar to the assignment window in IPv4, but we don't want to actually call it an assignment window, and it's not an assignment window. But it's a limit of how much you can suballocate to anyone, any customer of yours, without having to request an approval.

AUDIENCE SPEAKER: Okay, so that might be the difference ?? I always read the /48 as what you would assign to an entity.

ELVIS VELEA: No, it's to an end site.

AUDIENCE SPEAKER: That's why the confusion. Okay.

ELVIS VELEA: Right. And then we do have Point 2 here where some people on the mailing list have said let's limit how much current PI user can actually get. So, the LIR can get /32s or up to /29, but let's limit the non?LIR to a maximum /40 and if they need more they have to become an LIR, or a maximum /32 and if they need more than a /32 then they have to become an LIR, and it's like imposing a limit on how much a non?LIR can receive from the RIPE NCC. And the question here is: Is that a good idea? What would be the correct limit? And isn't this whole thing about removing any kind of limits?

AUDIENCE SPEAKER: Hans Petter Holen again. Can you bring up the side are the suballocation. I am utterly confused. If I go back to the original IPv6 policy that we had prior to 2006, or 2009, if you wanted addresses, you became an LIR or you went to the RIPE NCC. Or, you became a customer of an LIR and got addresses from the LIR. Okay.

ELVIS VELEA: Correct.

AUDIENCE SPEAKER: Hans Petter Holen. Of course there is often, but not necessarily a link between becoming a customer of an LIR and receiving IP transit service from the same LIR. But that doesn't ?? that's not stated in the policy. That's just common business practice, okay.

So then we introduced PI so that instead of getting addresses from an LIR, you could get your own block through an LIR.

ELVIS VELEA: Right.

AUDIENCE SPEAKER: A sponsoring LIR. So what you are now proposing is that in addition, or if you are an LIR you can still chop up your block and give it to your customers. You can now, as what used to be an end site or an end user where you get addresses through a sponsoring LIR, you can also chop up your block and hand it out to your customers and we had that with v4 with the suballocation stuff there many years ago as well. Similarly constructed. So actually we are creating LIRs with a direct relation to the RIPE NCC and we are connecting sub LIRs with an indirect relationship to the RIPE NCC.

ELVIS VELEA: And we're getting there as well.

AUDIENCE SPEAKER: If you want to take this further you can do this curve list ??

GERT DOERING: We have a slide coming up that shows that.

AUDIENCE SPEAKER: Aren't we making this too complicated? I mean, I don't really get what benefit this brings us. I mean yes, I understand that we can make this work, but isn't it just adding new stuff that can be solved with the existing construct. It's my thinking.

GERT DOERING: I think what we could do is ?? okay, if we are operating under the assumption that some people want independently routed IPv6 address space formerly called PI and do not want to become a RIPE member or cannot become for whatever reason, some just can't due to ?? well contracts. Then we currently have the problem that there is stuff with PI that cannot do, like run your hosting business on it because the policy says that you should ?? you must not do sub assignments from PI space. So, there is two ways to solve this. Either is sort of like loosening up PI, or people have brought up the idea of just abandon the difference and this is the attempt at abandoning the difference and figure out what the consequences have to be. And indeed the consequence would have to be that there is entities operating like an LIR that are proper members of the NCC and entities do exactly the same thing not being members of the RIPE NCC, not being entitled to vote, but still receiving a large block of addresses giving that to a hierarchy of customers. So, yes, the underlying question is which way do we want to go? If we want to go that way, how do we solve the problems that we have identified?

AUDIENCE SPEAKER: The original idea for PI was to actually provide specific End Users with an option for their own space and there were some limitations on how to use that. Otherwise, you know, everybody can become a PI end user and start suballocating to everybody. That was the original idea. I think abandoning that by actually allowing in this policy further suballocations on that particular space will actually remove the distinction between members space and non?members space, and I don't think that's a very good idea because it actually went against the reason why yes actually got PI space in the first place. It actually has a purpose ?? PI ?? as it is. And if people have the requirement to actually do hosting services or suballocations to others, basically they are a commercial entity that need to do ?? that are within the role that we have set for LIR members.

GERT DOERING: So just to be clear. I fully understand what you say. You say abandon this, keep PI with the restrictions it has and it's good as it is?

AUDIENCE SPEAKER: I haven't seen the problem explaining to my customers, and I have actually the writer and author for removing multi?homing PI for v6. I haven't seen the issue explaining to my customers saying if you want to have your own v6 block, it's four your infrastructure, it's not to suballocate to others. And by actually if customers actually say well this is what we want to do and if you see how easy it is these days to actually set up a new LIR, you know, we do it all the time, and you get the space that you want, it basically it's a non?issue to actually stretch this towards a point where I think we actually open up a can of worms. So, stretching the space, what you can actually request or say, well, if you go beyond this you need to go back to the RIPE NCC for documentation purposes, those kind of things, perfectly fine with that. But, the suballocation in there is basically what makes the difference and the second ?? you know, the indirect relationship is basically what makes the difference between being an LIR and being an end user. And there are contractual reasons for some entities that actually allow them to actually still request their space without being an LIR. And I think there are good reasons for that. But I think this is going a step too far. I think you are trying to solve too much in this policy.

ELVIS VELEA: That's correct. We are trying to basically remove all the differences between members and non?members and allow both members and non?members to get small blocks or big blocks.

AUDIENCE SPEAKER: But even for PI users, you can request a /32.

ELVIS VELEA: No, not right now. Well, you can request a /32.

AUDIENCE SPEAKER: Elvis, you can request a /32 on PI if you provide documented requirements.

ELVIS VELEA: But you can only use it for your internal network and cannot offer any kind of service to say your customers. Any kind of services. So you can ??

AUDIENCE SPEAKER: It's for End Users.

GERT DOERING: Let's stop that particular thread because there are more important things.

WILIFRIED WOEBER: That's the use of any services, this is just wrong. You can offer any type of services on that address space that you like. The only thing cannot do is transfer subsectionings of this address space for the management by your customer, that's the only thing cannot do.

GERT DOERING: No, that's not the interpretation by the NCC. The interpretation by the NCC is if you run an SSL virtual website with ten different customers on a box that use ten different IPv6 addresses, these addresses are subassigned to that customer and you are not allowed to do that. The interpretation is very, very strict. And so, as long as you start sort of like tagging individual IPv6 addresses to individual customers, you are not allowed to do that. That is actually ?? people bring it up eventually.

WILIFRIED WOEBER: Then that solves that problem. But I wanted to come back to first of all to what Eric said, that we are actually reducing the thing to everyone can get as many addresses as they want and they can roll the dies whether they want to become members of the NCC or get a free ride. That's exaggerating on purpose, but that's exactly where this is moving to. And this sort of gets back to my more detailed thing. Up till now, the longer you are continuing your presentation, the more weird the whole thing gets for me. Because if there is any provisions about size limits which require double checking by the RIPE NCC, you have at some point in time do away with the consequence that you can suballocate down to a /127. It simply doesn't make sense and it simply doesn't work in my mind. You have to have solve point in the food chain where you switch from suballocation to assignment, and if you do an assignment, and this is a block that can not be split up in smaller pieces. And then from that minimum size you can walk up the tree and say okay the RIPE NCC allows you to suballocate N times this monolithic minimal size block and then it Saturdays to make sense about talking about /40, /44, whatever, but I cannot see the logical consistency on one hand requesting the right to chop it down to 127 or to 128 even, and at the same time, asking for some funny limits where you want want to have a second opinion. I don't see how this would ever work. And in particular, with this structure that Eric has pointed out that we would need multiple level contractual relationships for these suballocations. I simply ?? and then think about the mess with RPKI. I think it's completely broken.

SANDER STEFFANN: I think ?? so about the contractual relationship. There are now only ?? everybody who gets address space from the RIPE NCC, either directly or through a sponsoring LIR needs a contractual relationship. If you are suballocating to your customer, you are still how long the address space, so that's like a normal LIR operates today so you wouldn't force a contractual relationships at those levels.

GERT DOERING: Anyway, I think I'm hearing you, we are hearing you. We have a couple of more slides, or Elvis has a couple of more slides with things that might be considered, and I think the whole point of the exercise today is bring up things that, if we go that way, need thought. If you all decide that no we are not going to go there because this is against the principles that we have been operating on and we don't like, it it's too complicated, then I think that's good feedback. So, after Hans Petter, I would say we go through the remaining items, so they have been at least sort of like presented to get you thinking and then we need to take it to the mailing list anyway.

AUDIENCE SPEAKER: Hans Petter: Two points. I fully agree with the arguments from the gentleman at the back. I think he put that very elegantly. And a comment on your reply to me Gert. I think your mixing allocation assignments and routing and I don't think we should start to mix that because I don't understand the argument that was presented earlier, much in agreement with Tore and Randy F you have a 100 data centres as you expected I don't understand why you should have 100 blocks from the RIPE NCC. It doesn't make sense. You need one big block to assign to your hundred data centres who is going to grow to 200 data centre, that is much simpler to manage and add trait and it will be 100 or two hundred routes in the global table whether these are small or big blocks. So that argument is kind of not going. So, we need to have the routing considerations out of this and then look at address management I think.

GERT DOERING: Let's go on and present the remaining issues and then decide how to wrap it up.

ELVIS VELEA: Okay. Question number 3 was remove all the definitions from the policy text and just create a procedural document or just create a document defining all special terms and as far as I saw, Richard Hartman has already taken this on board and he has already said on the mailing list this they have started working something off list and our idea is once his proposal goes through, then all the policies will have to be updated anyway to follow the definitions in that document.

SANDER STEFFANN: When we were discussing the, combining those definitions with the RFC 2119 part, after it was clear that that combination was not going to happen, rich art heart man already sent me a message that he was volunteering to take this on as an action item. So...

ELVIS VELEA: Okay. Well.

Next one. Now, there was another proposal to just remove the PI in the responding soaring LIR concepts and everyone that needs addresses becomes an LIR and ?? or you get addresss from your LIR. But the problem here is that if you have a problem with your LIR, then you must re?number. Otherwise, you have to become an LIR. So it's basically removing the PI completely, and we think that the sponsoring LIR concept in 2007?01 have solved more problems than this would cause, and removing this might require the NCC to hire an army for different departments, and we have made some calculation and right now in the whole region, we have about 30,000 users of addresses whether they are LIRs or not. So, if we would require everyone to become an LIR, then registration services will have to increase their team. Again, there were some discussions that maybe the legal team may need to start looking at it because we would be restricting organisations on how to get addresses and we would make it ?? you can either get it from the NCC or that's it, become an LIR or just become an LIR. And I see Tore there, but let's go through all the slides and then the questions, thank you.

Now, there was another question, because by mistake we removed, during the editing of the policy we removed one sentence that was saying that all bits to the left of /64 should be out of scope. ?? sorry in scope ?? no, out of scope of the policy and our question is if we do go through with this, should we care what happens with each /64 or not? What if someone wants to use a /112 for peering or for his customer? What if someone wants to use a /128 to number his customers? Should we care about it and if we do care about it, should we allow them to register these in the RIPE database or not? Currently the RIPE Anti?Abuse enforces policy saying cannot register anything below a /64. So, should we allow this? Plus, we have already discussed and decided that we will change the sentence to "There is no limit on how great the registration in the RIPE database can be." So, this, plus the fact that the ratio would be calculated at the level of a /56, would say that even if you have registered one /128 in the RIPE database pointing to customer, a service, whatever, the /56 comprising that address or that sub?net would be considered to be in use. And this again will be added in Version 2 if we do make it there.

Then the last ?? actually the most discussed question is End Users. And when we actually wrote this, we had no idea that there is a link on the website where the end user is defined. Now, I'm not going to go into the definition because it's a long definition but it says that the End Users are not part of the Internet registry system. However, they do get addresses and they can use them, but just for their internal network. Just like Eric was saying.

And then we realised, wait, so, what we proposed will not work, because this will not be End Users allowing them to suballocate and I'm going to the left side of the diagram for now. Allowing these to suballocate would no longer make them an end user. So, the question is: Is that an end user? But, they can suballocate, so, if you're confused ?? if you're not confused you are not paying attention and I saw everyone talking about it earlier. What should we call it if we do allow it? Will it still be an end user? Will it be a sub LIR? Will it be ?? what should we call it? And then we can always of course use the Greek alphabet and call it something.

But then we are moving to the right side where this is the current PI user and we are the sponsoring LIR they could get addresses from the RIPE NCC and according to current proposal, we would actually allow them to suballocate or even give address space to an end site. So this one is complicated. The entity receiving the allocation from the RIPE NCC can make suballocation, can use it for their infrastructure or their customers, must register of course, must keep a record, so it acts as an LIR but it's not an LIR. What can we call it? What do we name this one? And what do we name this one? Right.

So, these were questions that we still don't have an answer for. And I see that the feedback, although on the mailing list was very, very positive, I see that the feedback now in the room is saying maybe let's not go there. So, we'll continue discussing on the mailing list for the review period and see whether this is a good idea and whether we could actually find some names for these entities.

So, we initially had the idea of portable Internet registry. It would be the current PI user that could move with his /32 or 48 from an LIR to another, and someone else came with the idea of sponsored Internet registry because this was going through a sponsoring LIR. Other ideas on the mailing list was sub LIR, child LIR, associate member, what about sub IR. And do you have any other ideas about what we could call them? And should we move to the bidding part or should we open the floor?

GERT DOERING: Go to the billing part.

ELVIS VELEA: Okay. Another question was how do you convince the current PI users to pay more? And our answers would be we have a few options actually. One, you don't, you keep the /48 as at €50 or whatever the limit will be decided in the AGM. We had an idea of everyone paying the same as well, and some other options.

So, skipping the first one. If everyone would pay the same, there are more than 20,000 organisations using independent resources right now and I'm counting both PI v4 and v6. There are almost 10,000 LIRs with about 1600 overlaps, so there are about 1600 LIRs that use PI as well. And currently, the payment is made per independent resource and not per organisation, and for the first few options, for this one in particular, the payment would be made per organisation and not per resource. So if everyone pays the same and we consider that current users of independent resources would pay at least €100 at this moment because they want to use one PI v4 and one PI v6, then the increase for them would be from 100 to 6 or €700 and the LIR fee would bedecreased from 1800 or 1750 in 2014 to 6 or 7 hundred. So no matter how many resources you have, you pay the same. And if you do want to sign a membership contract, then you get all the services. If you don't, then you have your sponsoring LIR acting for you and ?? well, helping you with the registration and everything. However, this would only work essentially at the end if it applies to all the current users of independent resources. So all the current users of IPv4 as well.

Other suggestions. So the first suggestion is we change nothing. Right. We have €100 for non LIRs. 1750 per LIR, and that's the current scheme. We could keep that. We have suggestion 2 where everyone pays the same and it would be somewhere between 6 and €700. And this would be per organisation, no longer per resource.
The suggestion 3 would be for 80% of the budget to be paid by members and only 20% by non?members. So we give the RIPE NCC a bit of stability in the budget. And then that would be a decrease from 1750 to €1,400 for the membership fee and an increase ?? so it's a decrease from €1,750 to €1,400 for members and an increase from €100 to €200 to non?members. But again this would imply payment for organisation and no longer per independent resource. And there is also the suggestion that we keep the /50 per PI as we keep it right now. We keep the fee for the member which might be decreased in the future if other organisations will decide we'll get a /32 and we propose to the AGM to define another layer where the non?member receiving a large allocation would pay more than the non?member receiving a /48. And then again, this then would imply that we have to have payment per resource and no longer per organisation.

Unforeseen circumstances of this whole change would be that about 20 documents would be affected. Quite a few would be just updated. Quite a few would become obsolete. And well... there we go. That's it.

GERT DOERING: I am just grabbing the microphone, that's the advantage of being the Chair.

I'm not exactly sure what to do now. The idea has been presented to the room I think five or six times I have written a concept document that started to detail this and the question of that, sent that to the mailing list, got positive feedback for it, so these people have invested a lot of work, and now all I'm hearing is no, no, no, let's not go there. So, this is valid feedback, and maybe it's time to actually step back from the complicated consequences that needs to be solved and ask yourself the questions: Where do we want to go? Do we want this or do we want this not? And if we don't want this, then abandon it for good. Remove it from nigh agenda slides. And I think this is a question I'm going to ask the room now and I will have to ask the mailing list as well, do we want the principle of the abandoning PI and PA with the consequence of having members and non?members basically doing the same thing except for the voting rights, or whatever you might want to call it? Or do we keep what we have and fine tune it? So, I think Jan was first and then you and then Eric.

JAN ZORZ: Okay. Jan Zors, currently happy PI holder. Can you go back to slides, two slides, with the suggestions. Okay. Currently I'm paying €50 per year. Don't make me unhappy.

ELVIS VELEA: You are paying €50 because you have only one PI.

JAN ZORZ: It doesn't matter. I'm a PI holder I pay €50 per year for one PI and I am happy with this.

ELVIS VELEA: And you don't want to use PI v6, then you would pay €100 at least.

JAN ZORZ: I have PI v4, v6 and all that. Currently I'm happy with this. So I would say suggestion number 4 makes sense for me.

ELVIS VELEA: Okay.

GERT DOERING: That's actually a question we ask when we are sure we want to go there. Right now I'm not exactly sure that we have enough support to even ask the question. We really need to take a step back. I'm not exactly sure who was first.

HANS PETTER HOLEN: Let me see if I understand this. We have a proposal here that's so complicated that I don't understand it. It's introducing new constructs that don't have any names and we must have definitions for and we also have to change the contractual model and the building model for the RIPE NCC. This seems like a large task. On the payment structure, this is for the RIPE NCC association to decide upon. And there was a discussion over the last two years on the payment structure and it was last year changed into having one fee per member no matter of size with the exception of the provider independent end resource. So that's what the members voted on and decided two years ago.

Of course, it can be changed back to what it was or into something more differentiated but if that was on the basis of a complex proposal that where we don't really have the definitions for all the constructs that we are making I'm really worried that this will not bring us anywhere.

GERT DOERING: We will not go to the AGM before we are sure that we want to go there. This is just a consequence that needs to be cleared.

ERIC BAIS: I have similar remarks as Wilfried has. On the whole billing structure, please let us not go back to where we were. I do not want to have, you know, go through a math degree to actually figure out the invoicing for the NCC. Make it as simple as possible. And I think that the current process of having a charge for €50 per independent resource regardless of size is a very adequate thing. If budget is not covering the coarse for dealing with PI or independent resources, then that is something that the NCC will come back to the AGM for. I don't think that we should go to a model where we pay per size.

ELVIS VELEA: Okay. Duly noted. This is not proposing only that. This is saying there are quite ?? but the question that Gert asked was is this a good idea? Do we want to go away with all the differences between PI and PA? Do we still want the unification, because for the past five years we have been saying yes, let's do it. And now people have actually worked on it and we could work again on it to change it if this is not the right way. But we do need to receive from the room some pointers go that way or that way or just abandon everything and we just want to keep PI and PA.

AUDIENCE SPEAKER: Hans Petter: My strong suggestion would be the latter. Just keep it as it is both for the billing part but also for the contractual reasoning part. It's PI space is for an end user. Please let us not go into the trap of allowing them to suballocate. Period, full stop.

ELVIS VELEA: But they do it now. Just that the NCC cannot actually track it. Right now PI users ??

GERT DOERING: Let's not cover the line to the NCC part. Let's just stick to what's possible by policy.

ELVIS VELEA: Right now in real world IPv4 PI users offer services of hosting and even connection, even ISP services like, with IPv4 PI. With IPv6 PI, according to their current policy, that is not allowed. So, this was trying to fix this as well, this problem. Well, okay...

WILIFRIED WOEBER: If you, sort of coming back to your most recent sentence is asking the question do you think this is a good idea or not? If you would ask me on the spot I would say it's a very bad idea. Given the information I got today about all the loose ends and all the potential impacts on pretty fundamental and pretty stable assumptions regarding the operation of the whole system. I think it is just too dangerous and gives too little in return. And the most basic reason for this opinion is that in the recent past, I think we had a very good and very stable understanding that we want to have members of the NCC in order to keep these members involved in policy discussions in operating the whole system, and if someone as an end user or an end site or a portable LIR as you call, it just wants to have address space and not doing anything more than just using the address space and not being involved in all this crazy stuff that we are doing here this week, then give them a cheap dedicated well defined piece of resource to work with. That was my assumption and I was always taking the sort of my mental model when I had to answer the question what is an end site, and what is a service provider for any definition of service provider and I was talking the piece does not do any address management outside of their shop. So this is an end user and if they do address management for just their shop they are not supposed to suballocate, sub assign, transfer the addresses, whatever you call it and everything which is on top of that in the food chain towards the root, should become a member, should become involved, should become responsible and should talk to the RIPE NCC if the transactions with addresses they are doing it bigger than the pretty well established boundaries, like whether this is an address window, address assignment window in the v4 world or whether this is a /48 concept in the v6 world, and I think this is very useful, this is very essential to keep this system and everything which sort of makes a bad noise by grinding around the edges which not being able to register service end points for SSL, DSL or something like that, if this is a problem, then just go back to this particular problem and find the proper way to tell the RIPE NCC to do the right thing. But don't try to top he'll over the whole infrastructure, the whole system of the RIPE NCC and the registriesment thank you.

SANDER STEFFANN: I just want to come in on this. The reason why we started this was because of these points with PI and the hosting servers on there and in the past we had discussions about the world is not as black and white as it used to be with service providers and users. There are companies running hosting centres, VPN services thing like that. So the reason for loosening it up like this is because it's very hard to make policy in a fixed structure for a very flexible world. But I hear you.

GERT DOERING: I heard what was said and I will bring it to the mailing list and ask the very basic question do weigh want to go ahead with this or not? And if not, there is no need to discuss the fine print details. If yes, we will be happy to work on it. Tore, last word and then a few words from the Chair and then we overrun a bit into the lunch break.

TORE ANDERSON: I am broadly supportive of the ambition of this proposal. Clearly there are some devils in the details, but I would support working on exercising those dedevils so that we can actually get something that everybody can agree upon.

Also, I'd like to, if you can go back to the slide with the two trees, and this was my suggestion to the list that everybody becomes an LIR. And I want to clarify that when I said that, I didn't mean for everybody to become a member of the RIPE NCC as in a full paying member of the RIPE NCC. Because when you look at that graph there, the end user next to the sponsoring LIR which is the previous PI user, they are receiving their addresses straight from the RIPE NCC. Same as an LIR received their addresses straight from the RIPE NCC. The role of the sponsoring LIR is contractual and it's billing. The address DOS not pass through the sponsoring LIR and route to the end user. So what I am thinking is that this graph can be simplified and the policy can be simplified by basically not mentioning the sponsoring LIR concept in the policy itself because that's all business. Instead you can say in order to receive addresses straight from the RIPE NCC as an LIR or a state, then you have some sort of procedural document saying either you become a member and you pay the full price or you find some response sponsored membership. So those are the options you have. But I don't think that we need to actually put that in the policy, and if you do not do that, then the whole scheme becomes much easier to understand. So, whether on that we just mean that an LIR, if indeed we are calling it an LIR, the ones that are straight under the RIPE NCC, is no longer equal to being members. Thus the idea of associate member or something like that. Thank you.

GERT DOERING: Okay. Thank you. I think with that we can conclude that proposal for the time being, or that discussion. And the action is on me to take it to the mailing list and ask the underlying question go forward or not. In any case, thank you for the enormous amount of work you did in prepping and presenting this because it's ?? even if we don't go there recollect it was good to help make us, make up our minds what we really want. In that case it wasn't a lost exercise. Thank you. Give them an applause, it was really lots of work.

(Applause)

GERT DOERING: Then it's a few closing words from the chairs, actually from Sander at this time.

SANDER STEFFANN: As RIPE Working Group Chairs, I'm not just talking about address space Address Policy but about all the different Working Groups, we have been discussing on how Working Group Chairs get appointed, get replaced and so on.

At some point during the discussion it came up, do we actually need something here? Do we need like terms for Working Group Chairs? Do we need appointment procedure? So, basically this is just me asking what the Working Group actually thinks about this. There have been suggestions like a Chair gets, say, a three?year term, there is a kind of election after each three years. If nobody comes up, the Chair can just be reappointed and move on as usual. Do we want something like this? Or is everybody happy with the way things are going now and shouldn't we change it? There have been lots of discussions about too much bureacracy or not enough proud users, so, I'm actually asking the room do you think we need to improve this? Do we need a procedure for Working Group Chair appointments and terms and things like that or are you just happy with the way things are going now. I think they are hungry.

WILIFRIED WOEBER: I am pretty happy with the way we are doing business these days without any bureacracy.

AUDIENCE SPEAKER: Eric Bais. I think it would make sense to actually assign chairs with a specific term and have a silent renewal, unless you know objections from within the group or something. On the other side, history already has proven a case where a Chair was actually asked to be removed. That was done through the GM, if I recall correctly. But I think it's ?? if a Chair is actually working as a, you know, we like to work with the chairs, then there should be no reason not to reelect him for next term. But I think it does actually make sense to have a term on Chair elections. But that's my personal opinion.

JAN ZORZ: I am currently happy with the chairs of this Working Group. But I still think we need some process of re?election because this is how the chairs can get the credibility when they have to make a difficult decision.

AUDIENCE SPEAKER: I just happy with definitely but I would agree that if we can have election that it's not necessarily like we are not happy with the other Chair but you know just give young people or the newcomers a chance to be more active and participate in the Working Group like being Chair is one of the ways of course, when somebody wants to contribute to the Working Group or contribute to the policy process or whatever, it's actually a chance for people to be more actively participate in the process, which I say is good, why not?

SANDER STEFFANN: Thank you for your feedback. We'll take this back ?? Hans Petter, sorry.

HANS PETTER HOLEN: I was thinking how have we done this in the past? Agree it's not written down. On the the second point, in the past what we have done is to recruit more co?chairs so that whoever isn't pulling his load, at least there is at least two that pulls the load. That seems to work. What we could do to give you more credibility is to sort of select you for term of two years and do that every year so that it's overlapping. We won't every we place both in a single year so that means it could be done as simple as are there any volunteer to challenge any of the chairs, if not, shall be sort of a ?? is the Working Group happy with having the Chair in question for another two years?

SANDER STEFFANN: That's exactly the level of bureacracy that I had in mind because really doing big elections with voting slips and such at every meeting is not what I want to spend my time on. So thank you. Elvis.

ELVIS VELEA: One last thing. I do agree with the previous speaker. I think it's a good idea to do have elections every two or maybe four years or whatever, something there. And there is right now a document saying what attributions and what the Working Group share should do. Maybe we should look at updating that document. It states what the chairs do at the RIPE meetings and on the mailing list and what are their responsibilities. So maybe that document should just be updated.

SANDER STEFFANN: We'll work on the details. Because as a Working Group Chairs collective, we have discussions about this so I was just looking for feedback from the room. So thank you all for that. So that concludes this part.

GERT DOERING: I'm just skipping AOB, as I think the most important thing right now is lunch I'd say. So, thanks for bearing with me taking ten minutes of your lurch time and thanks for your feedback, thanks for being here and listening and I will bring the questions to the mailing list and hope to see you all in Warsaw. Thank you for being here.

(Lunch break)