RIPE 86
Address Policy Working Group session
24 May 2023
ERIK BAIS: Thank you everybody. Please find a seat. We will start with the second session for Address Policy.
So, we pushed the presentation of Jeroen for his new proposal to this session. We'll take up some time at the end.
JERON LAUWERS: Good morning everyone. I am a network engineer of ATP Internet in Amsterdam. I'd like to give a short presentation today about a subject for starting discussion in the community where we think we can improve the IPv4 policy towards ‑‑ he is not here because he had to do other obligations with work.
So today we're going to talk shortly about where we come from with this policy. What we think can be improved with IPv4 assignment, what our goal is, and the idea, what we have to improve it, and then after that we can have a discussion.
We did a RIPE proposal in RIPE 84 in Berlin, there we did a constant proposal for it. After that, we made the IPv4 assignment not mandatory, that was our proposal for it. Between RIPE 84 and RIPE 85, we made a proposal officially. And at RIPE 85 there was some further discussion about it with the community. We got like a lot of positive but also negative feedback from it so we decided to withdraw the policy and make a new version of it. And with the lessons learnt from the past, we want to first now discuss what should we improve it and how we should do it instead of already proposing a new policy proposal.
.
So, at the moment we have some challenges with IPv4 policy whereby either 16,000 PA assignments that have now D PA allocations that have no child assignments. 40% of the LIRs they have at least one PA allocation, whereas with no assignments in it so that means 42% of the LIR, they don't comply with the current policy. And we think that's quite a lot. So I think it's quite necessary if almost half of the LIRs don't comply with the policy, that we should do something about it.
.
The major feedback we got is that there is too much repetitive work at the moment. So all making all the assignments there is too much stuff that is like repetitive. And also we noted that paragraph 6.2 "network infrastructure and end user N" it's like a little bit fake Tor what function it has. So is a fee impossible fits in that or someone that has a server, like, as a broadband customer.
So our goal is with it like to make better coverage in the IPv4 space in the database. And also, then that the LIRs are more in line with the current policy.
We want to do this by making it less repetitive. Make it more easy and making it more clear.
So, Tor and I have an idea to introduce the arregate by LIR and replacing the status with the 6.2 paragraph and replacing it with this status.
There is going to be almost the same as in the IPv6 policy where it's a really popular and well used IPv6 status, and because it's so well used, we don't put the IPv4 in an unknown train and also as an extra benefit we would have a unification of both IP policies.
So, are there any questions or discussions for it?
ERIK BAIS: Any questions from the room? No. Nothing online. Then, thank you, Jeroen. We'll take this back to the mailing list.
(Applause) We'll take the discussion back to the mailing list.
LEO VEGODA: There is one question, Robert Scheck from Etis GMBH says "I like this proposal because there are multiple large German LIRs which do not create any assignments, thus it's not clear in abuse cases what ranges to block."
ERIK BAIS: Okay. Definitely also express your support for the policy, Robert, on the mailing list please.
Thank you Jeroen.
So now we have Matthias in regards to reducing IXP IPv4 assignment default size to a /26.
MATTHIAS WICHTLHUBER: Hi everyone, this is a proposal that we are doing together with two appreciated colleagues, Remco and Wolfgang, and well as the title says, the idea is to reduce the default size of assignments for IXPs to a /26.
So let me give you a bit of background here. So if you are working in the IXP business, you are probably aware that there is an IXP IPv4 pool that is intended to provide IP space explicitly for peering lance for Internet Exchange points, and the pool was propped up with a /16 in 2019 I think, because it was pretty clear that it would run out by 2002. Now we are in 2023, and at the last RIPE meeting in Belgrade, Marco Schmidt presented a forecast on the depletion of the current IPv4 IXP pool, and RIPE is predicting that the current pool will be depleted in 2029. There is still a bit of time but not too much. But I think we have to do something now at this point in order to prevent a complete depletion because a depletion will definitely create problems, so there are obviously two choices here: Either we are adding new space to the IXP pool, which would probably be another /16, I'm not sure if this is possible. If you are thinking about 2029, the situation might even be more cumbersome than it is today, and the other alternative is that you accept that the IXP pool is drained. But that will mean that new peering projects will have to probably buy space on the open market. So at the time of writing the proposal, I looked up the numbers and the a /24 was at 11 K US dollars, even if you think you can split that amongst several smaller IXPs, that is still several thousand US dollars per Internet Exchange point and if you know the IXP landscape you know that many peering projects are very small and live from donated hardware, so, it's pretty obvious that this is would be a showstopper for them.
.
So, what are we proposing? We are proposing to reduce the default assignments from the IXP pool simply to increase the overall lifetime of the pool well into the 2030s.
So, how does the current policy work? In a nutshell, obviously you see there only a few bullets on that slide so it's a bit more complicated but in a nutshell it works like this:
If you are an IXP and you go to RIPE, RIPE checks whether you qualify as an IXP, and we'll give you a /24 by default, no questions asked. In you are outgrowing the /24 because you are getting more than like 250 customers, you can go to RIPE and ask for a larger assignment; in this case you have to return your initial /24. You receive up to a /22, and RIPE asks you to ‑‑ or the utilisation of the new assignment must be 50% after one year.
So that's how it works currently.
And this policy creates a number of problems. And the first is the average IXP is much smaller than 254 peers. I have a measurement on this in the next slide to we can look a bit more into datasets how the distribution of IXP sizes actually looks like in PeeringDB, but it's pretty obvious that there is a mismatch between the /24 and the average size of IXPs and this mismatch waste as large amount of precious space that we could preserve to extend the lifetime of the pool well into the 2030s.
Another factor that I also draw from PeeringDB is that the number of IXPs grows with the high velocity. So the interpolation of RIPE is based on a linear growth, but in in fact if you look at PeeringDBs, since 2019, there have been more than 40% more registered IXP in PeeringDB, so my personal opinion on that is that the growth it faster than linear at the moment and that the pool might be depleted earlier than 20209.
.
So, this is actually a measurement that I did with PeeringDB data. So what you are seeing on the X axis are different peering LAN sizes. I drew the AS‑SETs of all IXPs from PeeringDB, assumed that they need twice the number of IPs for their peering LAN than they have ASes in order to have room for growth, and in order to account for things that are not directly ‑‑ are not really entered correctly into PeeringDBs, so in fact the numbers that I'm prepping here are already including 100% over‑provisioning.
What you see on the Y axis is which fraction of the ISP would fit actually into a certain peering LAN size. So we are currently with the default at /24. And you see that this satisfies about 90% of the IXPs, or 90% of the IXPs would fit easily into a /24 and what we are proposing is to move down to two prefix sizes to/26 which would still be enough for a 70% of all IXPs in PeeringDB.
.
So, the idea is to move down here a bit at the curve but have the effect of extending the lifetime of the pool.
.
By the way, this analysis is also open source, if you look into the actual proposal on the RIPE site, there is a link to GitHub that will, that conInns at that the source code for this analysis. So you can even rerun it yourself if you want.
.
So, what is the policy proposal? So what we are essentially doing is we're planning to introduce a speed bump. The idea is that we are reducing the default policy ‑‑ the default assignment size to a /26, and once an IXP utilises more than 50% of the/26, they can go to RIPE and ask to be fast tracked to a /24. In return for the current assignments. So the current assignment would go back to the pool.
That's the only effective change in the policy proposal. There are a number of other different editorial changes but they are essentially not changing how the policy works. So, the other stuff essentially remains the same, so still if you require afterwards a peering LAN that is larger than a /24, you can return the /24 and receive up to a /22 in exchange with the same requirement of utilising 50% of the new assignment after one year.
.
Of course, as usual in computer science, there is no free lunch, right. So there are also drawbacks of this, and what we are essentially doing with this proposal is we are trading space utilisation for the increased likelihood of an IXP to re‑number its peering LAN. So, what does this mean? If you return your peering LAN prefix to RIPE and get a new one, you have to re‑number the whole peering LAN that means all of the routers need to configure a new IP on the interface configurations, customer or member routers are usually not controlled by the IXP operator and that's why numbering is pretty painful, so usually this results in chasing IXP members for months to adapt their configuration. Writing e‑mails, writing shady ICMP scripts to find out who has changed this configuration and who didn't. That's the downside of that.
There was quite a lively discussion on the mailing list on the size of this initial assignment because it exactly touches the trade‑off, if you are touching over you are renumbering more often, if you put it higher you are assigning ‑‑ you are renumbering less often, and the/26 has emerged as some sort of compromise from the discussions on the mailing list.
.
That brings me to the end. And I'm open for questions.
ERIK BAIS: So, we have one question online from Elvis.
"To sweeten the proposal what if the NCC assigns a /26 and reserves up to a /24 where possible?"
.
That is something that has to do with how registration is setting up and I'm not sure if that's possible or that we look at a 15 in 26 with reserves.
AUDIENCE SPEAKER: I am Wolfgang from DE‑CIX and I have been renumbering and reassigning IXPs for fun. I have been running customer support, well it's been years ago, but the pain of renumbering for the IXP is way less than the pain for changing the net mask. Because customers it still works if the net mask is wrong somehow and they forget even more than if it doesn't work at all if you have to change the IP address. So, not a good idea.
ERIK BAIS: All right. Thanks for the feedback.
MARCO SCHMIDT: Just quickly answering to the question, Marco Schmidt, it would be, in theory, possible to withdraw from the space but I'm not sure if would defeat the purpose of this proposal because it's in order to spread the address space as much as possible. But technically it would be possible.
ERIK BAIS: Okay.
AUDIENCE SPEAKER: Maria developer of Bird, you are running us. I'd like to ask you have you considered running IPv4 packets and traffic over IPv6 next hops? Because this would completely remove the need of IPv4 addresses in IXPs. So maybe the question is how many of your peers really has such old routers which don't accept IPv6 next hops for v4 prefixes?
MATTHIAS WICHTLHUBER: That's an excellent question and we had a discussion on that on the mailing list. Obviously RFC 89‑50 is the solution to this problem, what we are proposing here is just a fix to get RFC 89‑50 implemented. The consensus on the mailing list was more or less don't force the adoption of RFC 89‑50 somehow in the policy because we're not sure how well this will work and rather wait for the implementation of the RFC, get ready before the depletion of the pool. That was the rough consensus.
AUDIENCE SPEAKER: Okay. Isn't that better to maybe try to deboganize the tools 240/4 just for the purpose of IXPs and such things?
MATTHIAS WICHTLHUBER: I have no real answer to that.
ERIK BAIS: Okay. I have Will, Peter.
AUDIENCE SPEAKER: Will, running one of those IXP with less than a /26. I was going to say yeah, I could reduce my sub‑net mask and then Wolfgang you mentioned that it's a pain, and I agree. So I would be in favour of that and I will be happy to ask my members to re‑number for the sake of duration and long evident of the IXP pool.
MATTHIAS WICHTLHUBER: Thank you, I appreciate that.
AUDIENCE SPEAKER: Peter Hessler. I want to echo Wolfgang's comment but as an IXP member and user, it's incredibly difficult for us to debug why we can't reach a neighbour, because we have no visibility on what the neighbour's net mask is, and it happens too often on so‑called medium sized IXPs or a/23 and not a /24. Where they were often some neighbours will figure a /24 if you're in the wrong segment of that 23, you can't send them any traffic. And in extremely worse cases, if you are getting it via the route server, sometimes your traffic gets blackholed.
ERIK BAIS: Yeah, basic networking, I hear. Okay. Thank you. So.
MATTHIAS WICHTLHUBER: If you are in support of this proposal, then make your voice heard, please.
ERIK BAIS: Thank you Matthias.
(Applause)
Edwin, you are up next.
EDWIN VERHEUL: Good afternoon. My name is Edwin, I work at Surf as a network engineering running the Dutch NREN. Previous meeting in Belgrade it was in short discussion in this Working Group about the temporary assignments, that it's actually a problem to get assignments actually for /24 because everything is in routing purposes best practice to filter out anything lesser than a /24. And you have ‑‑ you actually have to really have to get a really good proposal to get a big enough space and make it nice so it's big enough and you have actually a routable space.
.
So, let's see how this works.
All right. I see the previous deck is installed. I had some small statistics on the first page. Actually about the temporary assignments. It's, as a LIR you can request IP resources from the RIPE for a purpose for an event to get a temporary address space. Also, it's used for researchers, specifically on the IPv4 or IPv6. It was shown that around, it's a niche use case, there are around 20 it's a sites each here and you can find those in the annual reports of the RIPE. As I said currently policy is that you have to, at peak moments, you have to use 50% of the allocated address space, so, if you only can declare for 127 IP addresses at peak moments, you actually can't get any routable space because it's probably filtered out.
So, it was discussed and I worked with Elvis on a proposal just to have a /24 as a minimal requirement ‑‑ a minimal assignments if you want to have temporary address space.
So, we added this. It's actually a simple open door that should have probably done before but nobody proposed it, so here we are.
About the proposal itself, I think it's really simple so we tried to keep the proposal really simple. So, at the beginning of this year, we sent in the proposal and the discussion phase was started on the mailing list. We got several supports because it's actually an obvious proposal.
It could be that for some routing purposes, you need multiple /24s, and we actually justified this for research. So, there was some wording in a paragraph. We received some feedback in the mailing list and we actually created another document with a second version.
So, this is for ‑‑ this is only an addition, so this means that if you're a commercial company, you don't do any research, you just have a commercial event, the 50% will still apply. So that hasn't changed.
So, yeah, after the document was sent in, the second review phase started and it's still ongoing. We received seven supports of the proposal and that's because it's a kind of a niche use case in the RIPE community.
.
So it goes on till the 29th May, and also the impact analysis also may be made by the Chair, our co‑chairs of the address Working Group and it states that little impact. There could be of course that the address space, address for temporary assignments could run out, but with the 20 assignments each year, that's a little chance.
.
Well, so that's about the proposal. If there are any questions on this small proposal, you are welcome to ask.
JAMES KENNEDY: Online your co‑author Elvis had, "while this proposal does not affect a lot of people it has been a subject at several RIPE meetings. We have received a bit of support but it's not enough. I think this is a large community and while we do not have any negative feedback, we would love your positive or neutral comments."
EDWIN VERHEUL: I also agree on that because it's ‑‑ if everybody agrees. We have enough support this would help in the mailing list.
ERIK BAIS: It definitely helpings that there is no strong objection currently. One small remark in your slide you said on the impact analysis, the impact analysis is done by the RIPE NCC.
Not by the Chairs. But that's PDP.
Any questions from the room? Then I would strongly ask you to provide some support on the mailing list, and we can proceed with the topic for Leo
EDWIN VERHEUL: Thank you all.
(Applause)
ERIK BAIS: Leo will start with the discussion that we had on the v6 revamp. We had some intermediate sessions between the last RIPE meeting and this meeting, where some online sessions where we talked about the goals for the v6 policy, what we'd like to see in there, Leo is going to talk about it, Leo, take it away.
LEO VEGODA: Thank you very much. So, we have got about half an hour left in this session. So, we have got a good amount of time. So I'm going to quickly go through what's happened since RIPE 85; describe the text describing the policy objectives, and then maybe we can get some priorities agreed in here essentially that means someone volunteering to draft a proposal if there is an agreement that we're working towards the right kind of objectives.
So I'm just going to talk quickly about the process that we have gone through. After the last meeting, we held two interim sessions, there are bread crumbs in the screenshot here so you can navigate through all the different layers to get to this page. And we have also got a couple of blog posts on labs.ripe.net. So you have got the three minute version in the blog posts, you have got proper full minutes provided by the RIPE NCC, accessible from the links on this page, and of course there's a video recording. So if you are an enthusiast you can take all three or you can pick and choose whatever works for you but we had about 24 people joining one session and 20 joining another and we discussed four different topics.
.
And these were the issues:
.
Unclear guidance on documentation requirements for large allocations.
Complex language and implementation of the HD ratio.
IPv6 space not assigned/allocated on a nibble boundary.
Policy limitations for PI assignments.
.
Now, the discussion we had sometime back, there were some issues that were brought up about IPv6 that have gone to other Working Groups, so although there were issues brought up relating to routing, for instance, they have gone elsewhere but they haven't been forgotten, but we are focusing on the registration and the acquisition of resources issues here.
.
So, I'm going to read through what was the outcome of these sessions and this much larger group can comment on what this text is. People might go and say that is broadly okay. Or might want to adjust it in some way.
So, this is the first one on documentation. And the desired policy outcome was that the documentation requirement that the RIPE NCC imposes on people requesting IPv6 space should be published and predictable. It should be easy to implement. And renumbering should not be required to get more addresses although it must be an option.
.
Then, for the HD ratio, we need a tool that matches the way network engineers plan and think.
.
Essentially the outcome of this session was that people don't like the HD ratio. And we need something else. People here might say they agree, they might disagree. People might think actually what we need is a better user interface that explains the HD ratio more clearly. When we get to the end of this, if you have a thought, please stand up and make a comment.
.
Then, on the Nibble boundary, we talked about a desired policy outcome of initial and subsequent allocations or PI assignments always being on a Nibble boundary, essentially to make network management that much easier.
Of course this comes at the cost of larger assignments or allocations.
And then policy limitations for PI assignments:
We did discuss in the session why we have PI for IPv6, and one of the rationales given was that there are some organisations that can't become members of the RIPE NCC. Their constitution forbids them from becoming a member of another organisation, and being able to get PI IPv6 an address space by taking out a contract with an LIR is advantageous to them.
And the desired policy outcome: PI assignments should be based on the organisation managing the network and not the open source of the devices connected to it.
And we should eliminate the needs requirement up to a /44.
.
So, these are the policy outcomes that were the output of those two sessions with 20, 24 people working on them. This is a much larger audience. There might be different opinions. So, it would be very good to hear if people think that these are things that we should be working towards because if they are, we need someone to stand up and go and say yes, this is something that we should be working towards and I am willing to draft a policy proposal. And this is essentially the: Are we working towards a common objective part of the process? And then the next step is to start the policy development process.
.
So, is there anyone who wants to comment, to look at any of the text again? Is there sort of support for those desired policy outcomes or, for that matter, is there disagreement with them?
ERIK BAIS: Shall we see if we can get agreement in the room for the actual goals and the policy outcomes? And then we can see if there are volunteers?
LEO VEGODA: Sure, absolutely.
ERIK BAIS: So anybody want to make a remark about the four goals that Leo put forward as the outcome from the sessions?
JAMES KENNEDY: First up, we do ‑‑
ERIK BAIS: We do have someone online. Elvis has a question.
ELVIS VELEA: "I agree with the Nibble boundary allocation assignment limits. PI is a bit more complicated. Would you allow IPv6 to be sub‑assigned? Would you require/allow registration of sub‑assignments?"
ERIK BAIS: Okay, can you repeat the last?
JAMES KENNEDY: "Would you require or allow registration of sub‑assignments?"
ERIK BAIS: So, for PI space, there is already, you know, proper rules on how we did that in the past. Assignments is different. One of the goals that came out is that we're looking for PI specifically on who is owning the network and not whose device it is. Maybe that gives an answer to that.
Peter?
AUDIENCE SPEAKER: So a few things on here, the documentation clarification would be really beneficial. Some years ago I applied for a /47 PI space and that was a painful experience and I don't wish to repeat that again and I wish nobody else should have to deal with that. So I think having this documented and easily understandable would be fantastic. The HD ratio is a made up thing that nobody understands how it works. So yes we need something that's actually sensible. And the policy limitations, I really like the desired outcomes that you mention up here in your slide.
I think we can play around with the specific slash number on where the limitation is for needs requirement, but I like the concept of who should be able to ‑‑ who is managing the network and not oh, my phone connected to your /48, therefore it's no longer PI. Like, that's a bit silly in my mind.
ERIK BAIS: Not only in your mind. Yeah, so for specifically getting PI on various for a single organisation with multiple locations, you know, making it easier to get 48 per location, stuff like that, that should be very easy for companies to go through. You know, that should not be some book or essay of 60 pages that you need to submit to the NCC. So we hope to get, you know, those kind of requirements better in the policy. That was also thoroughly discussed during the sessions.
AUDIENCE SPEAKER: Or at least understanding what needs to be in that book of 60 pages. If it's 60 pages, that's fair but we need to understand what it is when we show up.
ERIK BAIS: Exactly.
AUDIENCE SPEAKER: Maximilian, speaking as a former resource holder I would like to add the fact that right now the RIPE NCC is more likely to hand out multiple /48 instead of a /47, so promoting aggregation should maybe be an option for the policy outcome.
ERIK BAIS: Yeah, we're trying to get if you do a single request for multiple locations, that you actually get instead of two 48s, you get a 47 or up to a 44.
AUDIENCE SPEAKER: But we need to explicitly in the policy and not implicit as it is right now.
ERIK BAIS: Thank you.
AUDIENCE SPEAKER: Dmitry. An LIR with a small space. I don't present my own point of view but rather the feedback I got from Ukrainian LIRs, operators some of them are not afford an LIR and have the upstream for the space. The typical worse practice was to hand those companies /48 and they say hey, then we are forced to give end user assignments of/60 for the companies and like well that's not the best practice, yeah, but we can't afford it, so I applaud the 44 without the needs requirement.
Now I have another question. You said it shouldn't new boundary, does it mean you fast forward/46 automatically round it up? I assume that is the case, right? Because if you want to be on a Nibble boundary, user still wants a small one.
ERIK BAIS: So for the Nibble boundaries specifically having a 29 is a pain for some. So, this will push up the 29 up to a 28, and for the 48, will, you know, for the larger assignments, it will go to a 44. Does that answer your question.
AUDIENCE SPEAKER: Yeah sure by the way the RIPE has reservation that that some... 28 is the reserve so this can one... that's another story. That's the NCC problem not ours.
ERIK BAIS: Well, it will be for the new allocations, yes. Mr. Doring.
GERT DÖRING: Speaking as myself, there is existing 29 holders that you cannot bump because they originally were 32 holders that got then the 29 and so ‑‑ but that's old stuff.
For the new stuff, I think it should be explicit that it's actually increasing the initial allocation size to a 28, which is perfectly fine. There is plenty of 28s. So, you always need to balance the numbers, routing table slots, v6 space, number of possible users of that space and 28 is perfectly fine. 24 would be perfectly fine.
The HD ratio thing is, I find is a sort of a surprising thing that it comes up again and again because if you don't understand HD ratio, just look at the table in the appendix of the policy, but if you come up with something better that takes into account aggregation losses and aggregation density and realistic how much should you fill this before coming back, well all the better. But I haven't been able to come up with something better.
.
Something else that I want to bring up, because it touched the NCC members charging scheme discussion, is: Please be very, very careful to always discourage anything where charging would influence address block size for LIRs. ARIN has this concept of you can have a 36 or a 40 or so as an ISP if you want to pay less. And I really, really dislike being tied on v6 allocations to network people just to save a few bucks. So seeing 36s given out in ARIN land is something that pains me.
We should be careful that whatever we do here will not then all of a sudden kick people in a different payment category, because that would backfire. We want to be liberal on the v6 allocations.
LEO VEGODA: Gert, on the HD ratio, one of the things that I think we should consider is maybe asking the RIPE NCC to take a look at this from a couple of perspectives.
There's the opportunity to creature interfaces that help people understand and maybe they have user interface experts who could help us do a better job. And there is another thing, which is that the HD ratio essentially came out of some academic research 20 plus years ago that at the time I think was looking at telephone number distribution, and we could go and ask the RIPE NCC to do an academic literature search to see if there's been more recent research about this kind of thing, and we could ask them if they have found something that is better, potentially, than the RIPE NCC, and they could report back to us
GERT DÖRING: On the other hand, we could just go for a fixed number, fill 10 and get a new block, because that is what the ‑‑ there is a huge table with lots of different sizes that are not realistic categories anyway. So in the end what matters is what the table says for 28 and 24, so if the table says for 28 you need to fulfil 10% utilisation, then just put that into the text line. It works for me.
ERIK BAIS: Any other remarks? Peter?
AUDIENCE SPEAKER: Peter Hessler. Gert hinted at this but I also want to remind the Working Group that changing the allocation from a /29 to /28 would move ISPs into a different charging bracket for the proposed charging seem, so that should be something that I want to echo that we need to pay attention to this even though we, as a working group, cannot make decisions on what the charging scheme is but being aware of what the potential financial impact would be is something that we should keep in mind.
ERIK BAIS: Yeah, do I agree, it also depends what kind of charging scheme we will end up with. There are some other options which do not have all the categories. So, if you don't like that, that's another option as well. If you have a 29, it's not always possible to expand it to a 28 if that becomes the policy, and then it's still your own choice to actually ask the NCC to do that or not. I know there are still LIRs that only have a /32.
.
Okay ‑‑
LEO VEGODA: One of the things the RIPE NCC mentioned, maybe a person who is employed by the RIPE NCC but wasn't necessarily representing them during these interim discussions was that, if our policy is reliant on the charging scheme to be an effective policy, then the policy can be made ineffective by a General Meeting, and that was an important point to consider. You know, we should have the right policy because it's the right policy.
ERIK BAIS: Totally agree. I didn't hear any strong objections on the goals that we presented here.
Anybody in favour for one of the topics to see and take a stab at it? Then, with all the enthusiastic people here in the room ‑‑ oh, we have a volunteer
GERT DÖRING: Since you pointedly looked at me, I did not volunteer. I am willing to help but I'm I am right now not willing to be the active proposer because I have been doing a bad job at this for the last two years so I know that my energies are sort of distributed to other projects. I am willing to help but I am not willing to have my name as the first on the list here.
ERIK BAIS: Okay. Then I would suggest that we take this to the mailing list.
LEO VEGODA: Yeah, that sounds like a good idea.
ERIK BAIS: And we'll recap there ‑‑
JAMES KENNEDY: Sorry, we do have Elvis in the queue, the mic queue. So, let me just grant the audio.
AUDIENCE SPEAKER:
ELVIS VELEA: Hi. Hi ‑ I have taken two stabs at the IPv6 policy. I wouldn't mind being on the team working on this. I think quite a few of these goals can be done quite simply by ‑‑ I mean the HR ratio could be simply taken from a formula to a table with three or four lines, but count on me if you need someone to work on writing a proposal.
ERIK BAIS: Okay. Thank you Elvis. We'll take that in mind. And we will take this back to the mailing list, do a recap there and then we'll also see where we think policy changes per topic could be workable instead of just do a whole revamp of the document in one go.
Which concludes this part of the session.
LEO VEGODA: Yes, we have just got AOB left.
Does anyone have any other business?
ERIK BAIS: Anybody have random ideas about new policies or things that need to be discussed?
.
I think it's going to be an early lunch, Leo.
LEO VEGODA: Everyone is hungry.
ERIK BAIS: All right. Thank you very much. This ends the Working Group session. And see you next time.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
