RIPE 82
.
Address Policy session
.
18 May 2021
.
10:30 a.m. (CEST)
.
GERT DÖRING: So, good morning, dear Working Group! This is the RIPE Address Policy Working Group. This virtual meeting, we meet on Tuesdays because with all the virtual stuff, the week layout had to be shuffled around a bit. I am Gert Döring, I start the session as the Chair. With me is Erik Bais, my current co‑chair. I saw him wave. Good morning, Erik. Let's go on.
ERIK BAIS: Morning.
GERT DÖRING: This is our agenda for today. We have quite a number of interesting topics to discuss today. I'm not going to read all of them for you. You have the slides, you can read yourself. Half of it is the standard stuff and reports and feedback from the database task force and some food for thought from Remco and about future work of the Working Group.
.
So, on virtual meetings.
.
As you have all noticed, this is not a regular RIPE meeting, once again, so we do all this on Meetecho. We have a very nice stenographer transcript which you can find in Meetecho or on the web page listed there.
.
This meeting, we actually tried to make this really interactive. At the last meeting, we have experimented a bit with Meetecho and noticed that it's actually quite nice to do interactive discussions with participants actually using audio/video to ask questions. So if you have questions, you can either type them in the questions and answers tab in Meetecho, or you can click on the 'request to speak' button on the top left, and we will then enable your microphone.
.
There is a chat function in Meetecho, but that chat is informal, so, if you put questions in there, it's possible that someone might answer them but we will not read them out for the group. Use the Q&A tab for that.
.
Of course, the session is recorded. What we have done this time is, we have pre‑republished the presentations, so we are not going to spend the agenda time with streaming the presentations because you can look at them yourself. We use the time for interactive discussions.
.
I should have Paul on ‑‑ no, I had hoped for Paul to show up here with ‑‑ who has seen the videos, who has looked at the slides, but that didn't work out so I think that Paul will appear soon‑ish.
.
Let's go on for the moment.
.
This is my standard agenda bashing slide. Due to the format, it's sort of hard to ask the room have I missed something on the agenda? Need we do some shuffling around? So, let's just stick to the agenda for the time being. If it turns out we need more time ‑‑ I see the problem; James cannot do the poll as he hasn't been promoted to Chair yet for the session. Marco, could you do that? Thank you.
.
So the poll will appear shortly, and, while we wait for that, we just go on to the next agenda item, which is again housekeeping. That's the minutes from RIPE 81 last October. The minutes have been sent to the mailing list and no comments received so far. The Chairs have looked at the minutes and found them very detailed and very good quality, so, thanks again to the NCC for the good work on that.
.
In a virtual meeting asking for live feedback is not very useful, so, please comment on the mailing list if you have something that needs to be corrected and the minutes will be declared final in four weeks from now. So there is time to to that on the mailing list.
.
So, we have a poll now. Please have a look at the poll and tell us whether you have looked at the slides or not.
.
I click on, I have seen all the videos. So has the poll ended now?
ERIK BAIS: The timer is still running.
MARCO VAN TOLL: You can see the results in poll results at the bottom.
GERT DÖRING: I can see the results but I'm not sure whether everybody has had the chance to click yet. I think the time should be up now.
.
So we have a few that have actually seen all the videos, about half have seen all or some of the videos, and about half say no. This comes as a surprise.
.
Randy sends via chat: "I cannot click".
.
So I thank all of you whom come prepared. For the rest, I would ask you just to click through the slides that have been uploaded as PDF because, due to timing constraints, we just cannot present all the slides.
.
This is an experiment. If it turns out that we are all unhappy with the result, we will do something else next meeting, or we have a real meeting with realtime again and then we need to change the format anyway.
.
My slides are already in section b: Working Group Chair selection procedure.
.
As I have announced on the mailing list, it's time again for some Working Group Chair rotation, and this time I am going to step down and I will not candidate again, So this is for the time being my last Working Group as Address Policy Working Group Chair. It's been a good time. Thank you all. It's been really good discussions, really good times, really good beer with lots of very friendly people. It would be really nice to do this in a big room with a proper amount of applause and waving and so, but we will do this next real meeting. So I'm giving the voice to Erik now, because I cannot do the succession thing.
ERIK BAIS: Thanks, Gert. It is going to be a change in the Working Group. You have been doing this now for 18 years, you know, we have been talking about this for quite some time already. It's been ‑‑ it's going to be challenging to fill your shoe size, and we'll definitely do a proper, you know, stepping down party in Berlin next year. So, that's something you have.
.
I believe you are running the slide‑show, so if you can skip to the next one.
.
So, the ‑‑ as you have seen on the mailing list, we had, in the RIPE 81, we asked for new chairs to be added to the ‑‑ as a co‑chair. We had two candidates that said, well, we wanted to join as a Chair for the Address Policy, we wanted a candidate, that is James Kennedy and Leo Vegoda. They have been as apprentice chairs, how do you call that? They ‑‑ so they have been in the back helping us already, seeing how Gert and I have been doing the chairing of Address Policy, although it was a very quiet six months, there was still a lot to do, especially for, you know, running up for the new sessions, all the preparations that come with that. So, on the mailing lists, we had already suggested ‑‑ or I suggested that we would go from a two‑Chair option to a three‑Chair option, and although that may have ‑‑ may give some additional problems when we have to reappoint new Chairs when their time is set for reappointment, when the time is up, because we're doing the rotation every two years, that is something that we'll deal with at a later time, but at this point, especially with the policy change ‑‑ or the review of the policies that are coming up, it is definitely something that we see as a benefit moving forward because when it's actually very busy with, you know, policy documentation, policy changes, it is good to have an additional set of eyes, and both James and Leo have a lot of experience in the Working Group already, they both have a lot of experience in working with the policies, they have worked for the NCC in the past, and they are still very active in this field.
.
So, I would like to ask the Working Group to agree on appointing the new Chairs. We have had the discussion already on the mailing list where the majority said that they were both good candidates. I didn't hear from anybody that they were against this. Any questions on this?
.
Then I would like to say welcome James, welcome Leo!
.
All right. Having done that, next slides, Gert.
.
So, Angela prepared the policy documentation from the various RIRs. It is ‑‑ good morning, Angela.
ANGELA DALL'ARA: Good morning everybody.
ERIK BAIS: It was an interesting read to see all the changes in all the various policy from the Address Policy groups globally. Anything where you say, well, this stood out specifically on the ‑‑ in the various RIRs?
ANGELA DALL'ARA: Well, as you saw, if you had a look at the slides in our region, it looks like everything is very quiet because we have no policy proposals at the moment, but there are many discussions going on and you will have them also in this Working Group, and what is interesting is how the PDP is under attention in other RIRs. They are tuning it, and especially in AFRINIC, let's say they had some challenging moments where the Working Group Chairs for the policy development were recalled, new ones were nominated and now they are picking up again.
.
So it is an interesting, let's say, moment for the PDP and other registries.
.
Another thing is about transfers, because as, you know, lately also the inter‑RIR transfers have picked up. So, also, there are some tuning is going on, some questions, especially what is compatible in one policy with the policies of other RIRs. So, it is a good idea to have a look also to other RIRs and chat what is going on there and compatible with other policies.
ERIK BAIS: Yeah, definitely. I see that we have Jordi standing on queue. Should I see if I can provide him with video and audio? Jordi.
JORDI PALET MARTINEZ: Can you hear me now? So, should click both the video and the audio to get the audio. Just one small clarification, in slide number 14 ‑‑ sorry, hello, Angela ‑‑ in slide number 14, there is something that I believe is an incorrect interpretation of the situation. There is actually not two proposals for inter‑RIR that reached consensus; it's only one. What happened is that there are two appeals, one against that proposal and one against the non‑consensus declaration of another proposal.
ANGELA DALL'ARA: Okay. So you had two appeals ‑‑
JORDI PALET MARTINEZ: It's true that there is one more pending problem is that the board said that they didn't get from the previous Chairs the ratification request, which I know is not true because I have copies of that. But whatever... that's a different situation. Just for clarification. Okay, because it may be confusing. The story is that there was initially one proposal from my side for inter‑RIRs, then there were two other proposals which were not reciprocal and one of those proposals, according to the Chairs, not to the community, reached consensus, and that's the reason behind the recall of the Chairs and also the appeal committee's failure and so on. That's the thing. Thank you.
ANGELA DALL'ARA: Thank you for that clarification, Jordi.
ERIK BAIS: Thanks, Jordi. Any other questions? Anybody that wants to speak up? I don't see anybody in the queue currently. Gert, Leo, do you have any questions for Angela? James?
GERT DÖRING: So I think we have been informed, good.
ANGELA DALL'ARA: And just to let you know, last week LACNIC finished completing the meeting and in the beginning of June is going to be the AFRINIC meeting, so probably some new news is going to come out of it.
ERIK BAIS: Excellent. We'll be waiting for the update. Thanks, Angela.
GERT DÖRING: Thank you. I'm not exactly sure how to deal with the rest of the session. Since I had done the steering slide, I think I can do the intros as well. With this, we go to Marco Schmidt, who will bring the report from the NCC. I'm not resharing my slide because it makes sense for Marco to share his own. Like, if a question comes up about, "I have a question about slide 14", then we can just look at that. So, Marco, here you go.
MARCO SCHMIDT: Yes. Good morning, everybody, and nice to be here and I'm happy to take any questions or any comments.
ERIK BAIS: Okay. Marco, we have had some ‑‑ during your session, you talked about the v4 allocations and assignments. Let's take that on. We have a question from the audience. Let's start with Randy. Mr. Bush, good morning! I can't hear you, Randy.
RANDY BUSH: Hello. So, even though I was there, I lost the thread of why we have a single organisation at multiple LIRs, which seems to be at the root of a number of things in Marco's presentation. My memory is that, oh, I don't want to justify need across separate POPs, you know, I don't have to justify my need in Germany against the allocations in France. Since we're not doing needs‑based justification any more, why are we in this game still? Why are we not discussing one organisation/one LIR?
MARCO SCHMIDT: That is probably a question not for Address Policy, it's for the General Meeting, Randy, because maybe you remember a couple of years ago, I think it was Erik Bais who stepped forward in the General Meeting to make that proposal and then there was a temporary hold on multiple LIR accounts opening for one member, and then they both looked into it and they came up with a proposal to the membership to continue with that multiple LIR account approach, which was accepted by the membership, and indeed, I agree with you, it created a lot of unwanted side effects that, back then, nobody really considered or had on its screen, and, like, one of them is the v6 situation. So, yeah, it's definitely a root call for quite some issues but probably nothing that the Address Policy can tackle.
RANDY BUSH: We may not be able to decide it but perhaps we can say to the Board that we have a number of problems occurring with Address Policy, but are caused by this and could the membership look at this again?
GERT DÖRING: I actually have something to say on that and that is not as Chair but as a consultant working for a large company in the last few months.
.
In some cases, I can really understand why companies ask for two or three LIR accounts and two or three /29s to come with it. Some of these large companies are so disorganised that they really have three or four fully separated networks, and, in that case, it's sort of really hard to common a network plan. We still have needs base, so if you want a 26, you have to demonstrate the need for that, which makes sense for some networks. For other networks, I can see that it's really complicated due to internal politics. On the other hand, I personally do not think that even 80 /29s is a serious problem. We have a question on the Q&A which sounds much more like a problem, but let's see. We have more in the ‑‑
ERIK BAIS: We have a couple of people in the queue. Let's start with Hans Petter in this one and then move to Jordi and Rudiger after that.
HANS PETTER HOLEN: Thank you. So, I think this is one of the complicated things and this relationship between Address Policy and charging scheme and membership will actually come up in the GM as well which seems a bit of a chicken and egg problem. As mentioned here, there is a link to policy from getting new address space if you are an LIR. If we hadn't had that, then we wouldn't have had 3,000‑plus LIRs that are just there to get another /29, or today it's down to a 24, if I remember correctly.
.
So, there is a driver there where we implicitly are selling address space by requiring a new signup fee and a new membership fee for two years and then changing the fee structure actually affects this, so if we change the fee structure, then there may be a change to policy in order to balance the price of IP addresses.
.
Now, this is really a relationship that we don't really want to have. We want to be able to make holistic decisions on fee structure versus policy independently, but they are inherently interconnected with the setup now. Why it is the way is probably, as Gert was saying, we have some very few organisations that needs this. Out of the 20,000 members today, we have around 3,000 more LIRs, so it's kind of like a bit more than 10% of the membership in total that has notable LIRs, and I would be surprised to see if a large portion of this has this for any other reason than getting more address space. So, I think it's really worth discussing this and figuring out the way forward where we can solve both these issues where today, we don't have one member/one fee; we have one LIR/one fee, and that means that some members are paying more than others, which is not consistent with the way we have been talking about the fee structure. So, I would really thank Randy for bringing this to the table and really hope that we can find somewhere to discuss this and move forward on this matter.
ERIK BAIS: Jordi.
JORDI PALET MARTINEZ: My point is basically about the same question. I agree with what Gert said, that in some situations multiple LIR accounts are needed, and that was the reason we did the change for IPv6 to match the existing IPv4 policy. Now, looking at the slide number 10 from Marco, he says the policy requirement to justify larger IPv6 allocations is rendered useless. I don't think that's the problem. The problem is that there is abuse, and we may need to somehow clean up the policy or find a way to avoid abuses, because there are real cases where that's a need, and Gert said one example, but in some other cases it's just plain abuse. That's my point.
ERIK BAIS: The question, before you move on, Jordi, from what I have understood from Marco and the presentation, is that if we're talking purely about the v6 allocations, this is primarily to do by merging LIRs that have received a v4 allocation and a v6 allocation, and that there is ‑‑ there are some members that have ‑‑ by doing that, have excessive amounts of v6 allocations; that's correct Marco?
MARCO SCHMIDT: It's partly correct. However, we do see in the, especially in the last year or so, an increased that when people very consciously requesting the v6 allocation, so not just as a by‑product to the v4, but really consciously requesting it via a multiple LIR accounts or even via transfer from other providers, other members.
ERIK BAIS: Other providers as well?
MARCO SCHMIDT: Yeah.
ERIK BAIS: Okay.
JORDI PALET MARTINEZ: So it's a case for stockpiling?
MARCO SCHMIDT: Yes, for some members, for sure, that's what we observed.
JORDI PALET MARTINEZ: So we should find a way to avoid that somehow.
GERT DÖRING: And indeed I have no idea why one would do that. It's not like IPv6 is running short and the price will go up any time soon.
JORDI PALET MARTINEZ: They may think that in the future they will have value, maybe? Like IPv4.
GERT DÖRING: We have Rudiger in the microphone queue, and we have three questions on Q&A and then the time for this slot is over anyway. So let's proceed. Rudiger, please
RUDIGER VOLK: I'm not looking at the tactics with gaining access to more resources. What I wanted to point out is, be very careful about installing one organisation/one LIR rule. In the business world, acquisitions and mergers around spinoffs and so on happen all the time for more or less good reasons, and we certainly would not want to have one organisation/one LIR rule forced to match in the LIR organisation, all the time close connection, close mapping to the actual enterprise organisations. And, by the way, I remember that about 25 years ago, I had good reason for asking and negotiating with the RIPE NCC a split of the LIRs for my enterprise because the existing assignment for enterprise use indeed could not be easily managed by the newly set up ISP LIR operations.
.
Things look much different in those companies these days, but kind of, a strict rule, quite certainly, is going to create unexpected problems of all kinds.
.
Thanks.
ERIK BAIS: Thank you, Rudiger. So we have a couple ‑‑ we'll close the mic ‑‑ we have a couple of questions in the Q&A.
.
I'll read them out. From Lars: We recently passed 100,000 global visible IPv6 routes which, today, there are, like, 120,000 or so. In the light of v6 management becoming much simpler, every CIDR size up to 48 propagating more or less globally. How do we expect the intentional lack of allocation requirements for anything up to a 29 to affect routing table growth in the future?
GERT DÖRING: I think that should be aggregation requirements.
ERIK BAIS: Then there is ‑‑
GERT DÖRING: I'm not sure we have a good answer here right now, but it's a question that has come up and I look at the routing tables and about half the prefixes today are more specifics of allocation blocks. So, yes, the policies suggest you should be allocating there, there is a RIPE document that says you should aggregate, but Address Policy can't actually force anyone. I have tried to bring this up in routing. The result was, yeah, but we have a document that says you should be aggregating. So, this is certainly an important topic, but we can't involve it today here.
ERIK BAIS: Okay. "Are 24s regularly moved out of the reserve pool and into the free pool and, if so, at what rate?" And the second question: "Are there more 24s due to be added to the reserve pool and, if so, how many?"
MARCO SCHMIDT: I am happy to answer that. So, yeah, it's correct, regularly we move /24s out of the reserve pool, although I have to make a distinction there. We have a reserve pool that is fixed. We have ‑‑ for example, we have found the /24 for temporary assignments and so on. However, whenever we deregister the address space, they go into quarantine for normally around six months and then, after six months, they are going to be released to the free pool and we talk about roughly 20 /24s per week that are being released from quarantine into the free pool, and at this moment it is also roughly the same amount that we deregister. Of course, this is not steady over the year. You can imagine that, at the end of the billing period, so if there is a large amount of deregistration happen due to nonpayment which creates a spike, but, on average, right now, we get 20 /24s into our pools, they stay in quarantine and, six months later, they go into the free pool and the pool appears quickly, the stats, how many /24s we hand out per month, and you see this is what we hand out is slowly exceeding what we, let's say, get in, and this is expected, and we expect over the next years that we deregister less and less IPv4 address space.
ERIK BAIS: Okay. Thanks.
GERT DÖRING: We had run‑out, run‑out, run‑out of the run‑out.
MARCO SCHMIDT: Yeah, still running out.
ERIK BAIS: So last question from Peter Hessler from DENIC regarding IPv4 allocation versus assignments: "How many of the announced allocations without assignments are announced as exact, the same size as the allocation?"
.
Obviously, this has to do with a lot of them already being 24s, and then not being able to register in the database at 24 as an assignment, that's a technical difficulty. We'll talk about that later as well in the presentation from James.
.
But do you have some numbers from arcs and what you see currently?
MARCO SCHMIDT: I would have to look into numbers for allocation larger than a /24. So I can bring it up to the mailing list. But I just put up this slide number 6, so for the allocations that we hand out of the /24, obviously there is no smaller size to be announced. And we talk about 81% that are without assignments and are announced of the whole allocation size.
ERIK BAIS: And that is 80% out of the 1,800?
MARCO SCHMIDT: It's 80% of the 1,100, so, it's roughly also 80% of the 1,800 but we really looked at the ones that are announced, then we can assume they are in use, so they are supposed to have assignments in it, according to the policy, but, yeah, more than 80% haven't.
ERIK BAIS: Okay. All right. Thanks, Marco. Thanks for the updates.
MARCO SCHMIDT: Thank you so much.
ERIK BAIS: I have ‑‑ before you leave, I have one question.
.
There is a charging scheme change coming up. This has potential impacts on the starting off new LIRs, because the plan is to lower the fees for the ‑‑ for the setup fees, basically. Do you see an increase already or how far is that moving forward now that the price for IPv4 is moving up? And do you expect to see a new rush coming up even with the waiting list?
MARCO SCHMIDT: Yes, I do. I can't really foresee the size, but I have stopped sharing my slide but I also mentioned it already right now, around 10% of the /24s are going to multiple LIRs, which were maximum one member open 12 accounts already to get /24s. And yeah, I mean, it seems one more organisations making the calculation. What a surprise for membership and what a surprise for getting IPv4 on the transfer market, and obviously if they then ‑‑ if the new charging scheme would be accepted, we'll see that price for the membership even goes down. I do think some people will do the maths and it will increase more, yes.
ERIK BAIS: Okay.
GERT DÖRING: The original plan was to have a short coffee break, Hans Petter wants to say something, so, a quick round and then coffee.
HANS PETTER HOLEN: Thanks for that. This may sound like nitpicking, but it's important, when we talk about the fee structure versus policy, please note that it's a fee per LIR; it's not a membership fee. So, when ‑‑ in the current structure we have a fee per LIR, so that, basically, you have to have one LIR to become a member, but then you can set up multiple LIRs to get more address space. Now, the reason we have that policy in place is that it was possible to have multiple memberships, it was discovered that that's not allowed under Dutch law as one organisation, you can only have one membership, and then we had the split between membership and LIRs. And then we are in the current situation, because the policy allows a member to set up multiple LIRs and get more address space, which is what the policy to ‑‑ for the last /8 was set up to prevent in the first place. The reason why we didn't prohibit that is, if we don't stop that, then any organisation will simply set up cheap data companies or PO box companies in order to register additional memberships and get them. So we're kind of in a position where we really want to have a structure that we can simplify without having this additional work of setting up additional LIRs for just the purpose of getting more address space.
.
So I'm not ‑‑ the RIPE NCC doesn't have a position on whether you need multiple LIRs to manage your stuff or not. That's kind of ‑‑ that's a separate thing.
.
But the additional overhead of creating LIRs structure and having fees assigned to use something that is new to policy is probably that it would be worthwhile to see how we can get out of that thing, and I don't have a good solution to that, but please tune into the discussion that is coming up in the GM on Wednesday to see how we can bring that forward and that needs close coordination with Address Policy. So, just, it's not a membership fee, it's the LIR fee, and we need to get that thinking right.
ERIK BAIS: Okay. Thanks, Hans Petter. So, we do have a short break and we'll see each other back in five minutes ‑‑ let's make that seven, then we'll start at 11:20.
.
(Coffee break)
GERT DÖRING: So my clock says it's twenty past. Nurani and Herve, can you hear?
HERVE CLEMENT: Okay, I am here, I can answer any questions
GERT DÖRING: I see some questions in the Q&A but these were about the multiple LIR and the AFRINIC discussion, so this is not for you. Any questions on the AOAC report? The video is online. I don't see slides online, so if you could upload the slides, eventually that would be great.
ERIK BAIS: You need to stop sharing, Gert.
GERT DÖRING: I wanted the slide on the agenda page, not so much shared right now. It says a new deck is being shared.
.
ERIK BAIS: If this ‑‑ is it working, Herve?
HERVE CLEMENT: No, because I think the sharing is taken by somebody else.
.
Okay, we have it now.
ERIK BAIS: So we had the report already, we'll skip through the whole introduction stuff.
HERVE CLEMENT: So, you have the comment of the report online and so it's useless to talk about that, I think, but the most important thing is the part that Nurani commented, it's about ‑‑ so the next elections that will be performed ‑‑ so the idea is so ‑‑ first, you will have soon the reserve of the seat 9 of the board of the... ICANN election that we are waiting for the due diligence performed by the ICANN, and so there will be two elections: There will be the one seat of the nomination committee of the ICANN, so there will be some procedures and timeline shared by every RIR, so it could be announced in a few weeks, I think. So it's a message to the community: If you are interested in that election and to be part of the nomination committee, so it's a committee to design some important function within the ICANN, so you can be a candidate to that, and there will be another election, it's a seat 10 of the ICANN Board of Directors. So it currently ‑‑ also, it is currently held by the APNIC, and so there will be elections starting in the second half of 2021 and there will be another announcement, so from the RIPE NCC, from our region. So when again if you are interested in ‑‑ so don't hesitate to be a candidate and don't hesitate to contact Nurani or me for that. And it could be good to ‑‑ so to have some of those on the committee interested in that.
ERIK BAIS: Anybody have a question for Herve or Nurani? Hi, Nurani.
NURANI NIMPUNO: I just wanted to add also, if you are interested in the ICANN board, get in touch with, obviously, us, but also anyone who is serving on the ICANN board now or has done it before because it might be difficult for people of the community to know what is required, so I'd recommend everyone to speak to those who sat before to get a sense of what's involved.
ERIK BAIS: When is the due date for this?
HERVE CLEMENT: It's not fixed yet.
ERIK BAIS: Okay. All right. So there is still some time for people to ‑‑
HERVE CLEMENT: Yeah, yeah. But just to be careful, to be a message from the RIPE NCC because it will be announced, as I said, by every RIR.
ERIK BAIS: Okay. All right. I don't see any questions. Nobody in the queue. Thanks, Nurani and Herve. Now, we go to Ulka for the NRO NC.
ULKA ATHALE: Hi. I would like to just load the slides, just give me a second. I am here to remind everyone that we are holding the NRO NC elections for May 2021 at this RIPE meeting. This election is to fill Filiz Yilmaz's seat. Thank you for the serving on the NRO NC, that's the Number Resource Organisation Numbering Council. Filiz ends her term on the 31st May and the term for this seat ends on the 31st December 2022. So it's to complete Filiz's term. All RIPE 82 attendees are eligible to vote. You need to do two things to vote. You need to check yourself in as being present at this RIPE meeting and you need to register to vote so you have the link here, it's under 'events' on the RIPE 82 website and you can check in via your registration page. The meeting team sends an e‑mail every morning which contains the link to your registration page, so please just go there and check in. If you do not check in, you will not be eligible to vote, you will not receive the ‑‑ even if you have registered. So please make sure you have checked in by 6 p.m. UTC plus 2 on Thursday, the 20th May.
.
Voting will open at UTC plus 2 on Thursday and it will close on Friday morning the 21st May at 10:30 UTC plus 2, and the RIPE Chair will announce the results in the Closing Plenary.
.
We have two candidates standing for election and I will give the floor to our first candidate to introduce himself.
JAMES KENNEDY: Hi, everyone. I am James. I have been involved in the whole RIPE setup for the past (inaudible) at this stage. For three‑and‑a‑half years I was IP resource analyst working at the RIPE NCC, and since then I have been managing the IP address space for an international Internet provider in Europe. I am a regular attendee of the RIPE meetings over this period of time. I have been through the PDP process. I had a policy back in 2015, I think it was, so I have had a good understanding and deep appreciation of the whole bottom‑up consensus‑based Open Policy discussion model that we all practice, and, with your blessing, I'd like to take my knowledge and experience to the NRO NC and help them achieve their objectives.
.
That's me.
ULKA ATHALE: Thank you, James. Our second candidate is Robert Poehler, who has unfortunately not informed to me whether he is attending this session. So I thought I would just check one last time if he is in the audience, but I do not see him in the participant list. So, Robert, if you are here? And I don't see him here so we can move on. Thank you.
.
If you do have any questions, you can e‑mail nominations [at] ripe [dot] net about registering or voting. Thank you.
ERIK BAIS: Thank you. I don't see any questions in the Q&A. So, nobody in the waiting list. Let's move on.
.
Then, again we have James Kennedy, to talk about the database task force. James put a presentation online and also the video was already provided. James, the floor is yours!
ERIK BAIS: Let's go through the small things and then open the mic for the discussion, and for the questions that we cannot answer, we'll take it to the mailing list.
JAMES KENNEDY: Absolutely.
.
So, I am under instructions that I have already uploaded the video, so I hope you have all seen it or at least read through the slide. But I'll give you a quick summary and we can talk about it here for a few minutes, otherwise you can feed back ‑‑ I can show you how to feed back to the task force, first to take into consideration anything that we might be overlooking, but, in essence, what we are recommending...
.
We're finalising our documents. We are going to have a call for comments on the final draft over the coming weeks, we hope. But, yeah, on Friday, Bijal will have more detail on the general status of the task force and/or objective.
.
But I wanted to highlight a recommendation that we're currently working on that's related to Address Policy directly, so ‑‑ and it's also related to previous discussions we had with Marco and what's going to come.
.
So basically, the recommendation is to remove the hard policy that requires all PA IPv4 assignments to be registered in the database, but of course still make it ‑‑ still keep the functionality there to allow people to use it if they need. So, in essence, giving the PA allocation holders the freedom to make or register PA assignments INET NUMS objects in the Ripe Database or not. We caveat that if you are going to sub‑allocate or partition a chunk of your PA address space to a third party, to another entity, we would recommend that these be registered in the RIPE database.
.
The rationale involved are in my previous slides. I think time‑wise we are a bit short that I can't go through it in more detail, but again, feel free to read on the website. But if you have any initial feedback to this recommendation that we're working on, is there anything you would like us to take into consideration? Either let us know now or I can tell you how we can we can do so afterwards.
ERIK BAIS: Okay, there was already some discussion posted based on the video from Denis on the mailing list, a lengthy e‑mail. I do not see any questions currently coming up.
JAMES KENNEDY: There was one point that I'd like to clarify for Denis and anyone else who might have mis‑read, you know, the video. We're not proposing to remove any data that's currently in the database. We're not proposing ‑‑ sorry, wrong word. We're not recommending this function be removed for people. It's specifically for the hard policy that requires all the assignments to be registered in the database to remove that. For one example, so ‑‑ well, a couple of examples. Previously, to qualify for additional address space, it was required for LIRs to show the utilisation of the current pools and it was mainly done through inetnum objects for PA assignments, not only, but that was a key factor, but since the NCC ran out of IPv4 again, is this really a hard requirement? And also, as Marco said, quite a few /24 PA allocations are now out there in the field, and, under current policy, they must be registered in PA assignments, the address space that's being used, even if it's, you know, used contiguous in a /24, they can't register that because cannot register overlapping inetnum objects of the same range.
.
So, taking these into consideration, yeah, the main point of this ‑‑ my quick update here is to let us know if there is anything you'd like us to take into consideration into our report that maybe we're overlooking?
ERIK BAIS: Okay. I have one remark from Peter Hessler from Internet community member. I'll read it out. "I have always been confused on the details of registering IP assignments in the database so some detailed guidance would be extremely welcome."
.
And Jordi Palet is saying: "I agree with Denis's points, we can't back the work down done by the database task force."
.
GERT DÖRING: I want to actually comment on that, Not as an ex‑Chair but also as an LIR address manager, which has been ‑‑ what brought me into all this 20 years ago.
.
I think this is a valid suggestion to rethink what we want to have in the database. I'm not saying that the database task force recommendation is something we must follow, but it's definitely something we carefully need to consider.
.
Back, 20 years ago, you put in the telephone numbers of people that are responsible for certain address blocks, and that was the end‑customer holding the addresses. Today, with today's business structures, if I put the CEO of our end customer in there who has a/29 from us, you are calling him and say, yeah, there is a problem with your IP address, that will most definitely not lead to what you think it might lead to.
.
So we need to reconsider what we want in there. Do you want the name of the end customers there? Do we want the contact details of some persons that are in a way related to that company but might not actually be a useful contact? We're not going to solve this in three minutes, but I think it's a very, very valid point the database task force brought up.
ERIK BAIS: Yeah. Good point. There is also the part about the ‑‑ that was also mentioned by ‑‑ in your presentation, but also in the presentation from Marco, about LIRs being allocated a /24, using the /24 as, you know, that was, you know, the use for their network, so basically creating an assignment for a /24 besides the fact that's not currently possible in the database, you know, the /24 is what they actually use, so basically you are duplicating the same information as you have for the allocation, which doesn't make any sense. That has come up with arcs already, I had the discussion already with Marco on that, and we'll need to see how we can move forward on that as well.
.
Thanks, James. And let's go and see if Remco is available.
REMCO VAN MOOK: Well, as opposed to all the other presentations, I haven't rerecorded mine, also because I finished at 11:30 last night in the time‑honoured tradition of doing late Address Policy presentations.
.
This one is called 'Why PI?' And people who have been been in the room for too long recognise this statement. This was one of the statements in the ASCII art form allocation request that you had to fill in and send via e‑mail to get an allocation for an assignment from the RIPE NCC, up until mid‑2000s, I think.
.
And I am here today to talk to you about why PI? Now, honestly why? And I'm not doing this in the form of a policy proposal or not even the Address Policy, but I just want to put this in front of you and see where we take this.
.
So, let's see if I can share the slides. Yes, here we go.
.
We have a whole bunch of flavours of address space. This is just a number of v4 flavours; you have got legacy allocated PA, signed PA, signed PI, signed Anycast. You don't really think that's all of them, right?
.
If I dive into the database and I look at the inetnum registrations, this is what comes up.
.
It's a bit of a zoo. And one of the ‑‑ one of the things that caught my attention was that, apparently, we allow typos in the established field, and there is many thousands of them, and four typos are actually more common than the valid status of assigned Anycast, which is all not fantastic, and you can certainly question yourself whether ‑‑ how much of this still has relevance in today's situation.
.
Now, if you focus on assigned, I mean bearing in mind the whole discussion we had now about the /24s not being able to be assigned, this is roughly sort of the breakdown in the number of inetnum records, the number of entries to the database, and if you then put that into a helpful pie‑chart, you see that legacy is about 3%, PA is 96‑odd percent, PI is I think somewhere in the 0.6% of inet‑nums, and then Anycast is actually less than a routing error.
.
Now, if you look at IPv6, which has hopefully a little less legacy in the literal end and transitive form of it in the database, and you have a look at this again and again, there are more typo ‑‑ there are two typos that are more common than assigned Anycast, and the other thing that actually also struck me is that we're actually abusing a status to represent something it isn't allocated by RIR, just focus actually allocated by the IANA, which is a bit of a ‑‑ sort of a weird thing to say. So, just taking this true, except that it's not true.
.
So looking at assigned again, you see there is a breakdown of 567,000 assigned, 46,000 aggregated by LIR, which is sort of assigned but in a stream‑like form. We have got assigned PI and assigned Anycast, and if you put that into a helpful pie‑chart, you are seeing that basically every ‑‑ everything that's not ‑‑ that's not associated with PAs essentially in terms of number of entries.
.
Now, how much of this still matters? And a lot of this was informed by old pieces of policy to set limitations or criteria on which piece of the puzzle goes where? Do we have a special case for people running Anycast? Do we want something special for this? Do we do something for that? And we felt that it was all necessary to document that in the Ripe Database.
.
Now, the Ripe Database has gone through, in its purpose, I mean, the core purpose of course has not changed, but what it does and how it does it has changed quite a lot. Originally, the database was the whole registration and nothing but the registration and the RIPE NCC did not have additional records other than the database.
.
Of course, we have moved on from that a long time ago. There is CRM aspects, there is business relationship aspects that are not reflected in the database, yet some of these artifacts are still in the database.
.
So how much of this actually still has operational relevance in this day and age?
.
Now, I'm going to apply the first law of Kurtis here, which is, if you think you are special, you are probably wrong. And take that lens and look at sort of what are the various aspects that we're administering and making visible?
.
Allocated? Sure. I mean, we want to make sure that if I look at ‑‑ if I want to know who is responsible for a piece of address space, knowing that it has been out to ‑‑ handed out to a contracted entity in some way, shape or form, yeah, that's relevant.
.
Assigned? Well, definitely. I mean, the question here is, is this being used and, if so, by whom? is, of course, very valid.
.
Going to more contentious bits of it, legacy, is a legacy flag operationally relevant in the database? Isn't legacy just an admin flag inside of the RIPE NCC that informs who should or should not be able to update these records? So, I'm guessing it's probably no operational relevance to this.
.
Anycast? Anycast is a hard no. The point of Anycast is that it functions as Unicast except that you handle it from multiple points. So, there is no relevance from an operational perspective on this.
.
So what if we just did a massive cleanup, and not just the typos, which obviously I think need to have a script run against them and make sure that we are getting consistent statuses, even just for the sake of people writing scripts.
.
What would we gain?
.
Well, if we just went to inet‑nums that are either allocated or assigned, we need a lot more clarity and consistency in our database. We have a lot less room for loopholes, and we'd get much simpler policy and certainly much simpler procedures around all of this.
.
So why would we look at this now?
.
Well, it's actually ‑‑ we have touched on this before in this session. It's sort of the combination of policy informing charging scheme, informing membership structure, informing ‑‑ and it creates a circle. But actually, the result of what we currently have in the database and which are remnants of Address Policy that is no longer being applied but as a result of still being in the database still has some validity. It defines a very rigid model for the RIPE NCC to follow for the structure of the membership and it's actually mostly based on how we used to distribute IPv4.
.
So if we want to give room to evolve the membership structure and charging schemes, and based on what today looks like, I think we need a clean break with the policy and database that no longer prescribes the way the RIPE NCC membership should structure itself, but rather, allow it to accurately reflect reality. I mean, going back to the discussion about multiple LIRs per member is exactly one of these artifacts that should be cleaned up. Direct assignments, sponsoring LIRs, we have a pretty big zoo of options that could do with a fresh look. But with what we have right now in terms of policy and RIPE NCC being instructed to implement policy, because that's sort of foundational to the RIPE NCC, maybe we should think, as a community, on cleaning up the old stuff so we can actually go and move forward with evolving structures that actually fit the current day and age.
.
And I'm looking at the Chairs now, I didn't have like a question section in here, but I think we're going to have like a wider discussion on policy. Erik?
ERIK BAIS: So thanks for the quick presentation. I was a bit worried about time and the amount of slides that you put up. Can you go back to the slide which basically says this is what I am proposing in a short one?
REMCO VAN MOOK: This one?
ERIK BAIS: Yeah. That one. So, if I understand correctly, try to avoid as many additional statuses for the inet‑nums for v4 and v6 without having any kind of contractual agreements status assigned or allocated to those and move on from there and let the contractual side be done by the membership in the GM and the Executive Board, is that a...
REMCO VAN MOOK: That's a reasonably fair description. And mostly, what I think is that the database should no longer be used to reflect the business relationship between whatever entity has an entry in the database and the RIPE NCC, which is what it's currently prescribing.
ERIK BAIS: Okay. All right. So we have a couple of questions. I have one from Elvis from V4Escrow. Question: "So make all PI owners LIRs."
REMCO VAN MOOK: Well, excellent question, Elvis. That's not what I'm proposing. That is something that is then up to the membership and the RIPE NCC, as an association, to decide whether that is a better structure going forward. So, it's not ‑‑ I'm not saying that we should do this right now. I should do ‑‑ what I will say is that, yes, if this is a possible outcome out of membership consultation, General Meeting, agreement, etc., etc., etc., which can only happen and only happen if community policy allows for it at all, and currently it doesn't.
ERIK BAIS: Okay. Moving further. Christian Bretterhofer: "Phone systems can currently receive from telcos and they can be kept back as you move to different telcos. That's what PI space is for. So I think we need less PA space and more PI space. Carriers should just route to more ‑‑ carriers should route to more PI space."
REMCO VAN MOOK: I am not sure if I'm qualified to answer that. I am sure that if we find more v4 address space to hand out, we could certainly build a policy that turns that into PI, and effectively by handing out /24s, that we can actually no longer put assignments in. It is effectively ‑‑ it has become PI. And ‑‑ but, I mean, PI versus PA, certainly in this day and age, it is such ‑‑ what is the difference? The difference is who you are paying for it. That's it! It doesn't have any functional operational difference. If you get your own LIR with your own PA space, that is effectively the only difference is who are you paying for it and how much are you paying for it? There is zero difference. Of course, if you taking someone's PA space and using it and then you are moving to announce someone else, of course you are going to give it back, that's PA and that's what it's always been like.
.
So, I don't know how to answer that question.
ERIK BAIS: Gert?
GERT DÖRING: Yeah, but actually what Remco just said is the most interesting bit about it. The difference between allocated and assigned PI is who are you paying for? So, if we want to do away with that distinction, it needs to be considered very thoroughly. We tried to do that a couple of years ago and the resulting policy proposal was a nightmare. Back then it didn't work out, but I don't know, let's see what the discussion brings.
ERIK BAIS: No problem. I have a remark from Alex Le Heux: "Can we stop talking about phone numbers and just silly details and maybe take a step back and ask ourselves what does the Ripe Database need to do today and then go and implement that?"
REMCO VAN MOOK: Yes. Thanks, Alex.
ERIK BAIS: I am closing the mic by the way, because otherwise we'll have not enough time for the rest of the agenda. I have three questions, and I have a couple of more questions in Q&A, I will just move through those.
Sergei: "Membership can decide the community policy. Please don't seek the membership consent without consensus within Address Policy Working Group."
REMCO VAN MOOK: I think that's exactly what I'm trying to do here, is trying to get consensus within Address Policy, get the community to decide on a new policy framework that we can then take to the membership and go from there.
ERIK BAIS: Petra Zeidler: "If I am a new network admin for an entity that has PI and the documentation of the entity is lacking, how do I find out what type of assignment it has? If I can look it up ‑‑ if I can't look it up in the database?"
REMCO VAN MOOK: You should have a contract with someone, anyone. Ever since we implemented 2007‑01, there is a paper trail for everything including PIs.
ERIK BAIS: Yes. Peter Hessler: "Comment about requesting cleaning up of the database, I started participating in the Database Working Group especially because some of my objects were modified by the NCC without my knowledge as part of the cleanup process requested by the Working Group. Any sort of modification in the database must be told to the affected contact before changes are done."
REMCO VAN MOOK: Yes.
ERIK BAIS: Another one from Peter regarding converting PI to LIRs: "I have some PI address space specifically because I don't want my home address published on the database or on the RIPE website."
REMCO VAN MOOK: Well, that's no longer allowed by GDPR anyway, so...
ERIK BAIS: By Daniel Karrenberg: "Will we be getting the systematic review discussion?"
REMCO VAN MOOK: That's for you to answer. And with that, I'm going to unshare. Thank you for your time.
ERIK BAIS: Then I have a short question from Elvis. Elvis, you have the mike.
.
ELVIS: I hope this will work. Yeah, just a question regarding this transformation. I think more of a comment, a bit of a longer one, I hope; I have a couple of minutes, maybe less.
.
So in order for this to work, we would have to find a way to have address space still given out to companies that don't want to become a member, and we have the sponsoring LIR saying now that when we give up on the PI, we basically have to figure out a way for that to work, allow address space to move to non‑members right now PA can only move to members, and it's extremely complicated, we have tried this in 2015. I coauthored the proposal then and the community thought it was extremely complicated. Maybe this time we'll find a different approach, I hope.
.
I agree that this would make sense, but it has to be worked from many angles.
ERIK BAIS: Yeah. So one of the topics that Remco is starting here is to uncouple the actual contractual relationship with the actual information in the database. So, first, the Working Group here needs to decide can we move to a common status for, you know, any colour of IP space, whether it's allocated an assigned PI or legacy, that kind of stuff, and without having an effect on the actual contractual relationship with the NCC or the intermediate LIR? And then move from there. And if the NCC, with the membership in the GM, decide at some point that we need to have an overlook in the contractual relationships, at least then we can have that discussion, but before we do this step, that's not an option, because policy won't allow it.
.
GERT DÖRING: So we're running out of time, and I notice that I actually messed up my slides, so I don't have a slide for the last agenda item. I do have a slide for goodbye. But we do want to at least mention the last item on the agenda.
.
I think I'll hand the microphone to Leo because it was his idea to start with. Maybe just describe what you have been thinking of and then we need to put it on the list anyway.
LEO: Thank you very much. The last item on the agenda is something that has been raised recently on the mailing list, and that is to have a structured review of the policy and to basically go and say: We have all of this policy that was accumulated over decades, and what is the current status of the world and can you see the policy fit the current status of the world, and is it fit for the current status of the world?
.
Clearly, we're not going to have time to get into the detail of that today, but this is something that we wanted to raise as a policy topic. That gives us the opportunity to systematically go through each element of the policy in a structured way and make sure that we are fit for purpose.
.
So if anyone has a comment on whether this is a good idea, a useful use of the Working Group's time, it would be great if people could add a note in the Q&A, or if there is a quick ‑‑ someone who wants to quickly make a spoken statement, then we have a couple of minutes while we run into people's lunch break
GERT DÖRING: I have feedback from Sander Steffann on the chat, and he says he doesn't want to use the mic because it takes too long, but he likes the idea, wants to take part of it and do all the work.
ERIK BAIS: All the work, even. Well, I hear that you have some time, as you are now ‑‑ this was the last official time for you as Chair, that means you can start working again in the Working Group with policy work. Are you intending to help us out on that, Gert?
GERT DÖRING: I will not run away so... I will help, of course, and I think it's a reasonable idea.
ERIK BAIS: Yes. Definitely I. I would like to thank Leo for the suggestion. We definitely need to take this to the mailing list, as we also have the scribe on the Working Group, I want to thank Suzanne Taylor for scribing here, this whole session, and keeping track of everybody and all the questions.
.
If there is no other topic that we have missed, and I don't think we have, I would like to thank you all for attending. I would like to thank Gert for all his hard work and see you all next time, and any questions, use the mailing list. Thank you.
.
(Lunch break)
