Session 2 of the Address Policy Working Group session.
RIPE 93.
29 October 2026.
2 p.m. .
FRANZISKA LICHTBLAU: The bell outside started, so everyone please find their seats, people come in.
As we have quite a few agenda points for the second session and we still want you to give you sometime for the Open Mic, we are not waiting for long for stragglers.
First of all, and second, we have Remco on stage, but we start off with an idea to moving towards a RIPE policy manual.
REMCO VAN MOOK: It is a noticeably more quiet room than this morning. I think I have really chased people away by getting on the agenda, that's amazing.
I am going to be talking about what I call the new kitchen. We keep talking about kitchen sinks and reinventing stuff. I will take you through the new kitchen which is basically, see if we can clean up the way we organise our policies and get some structure in place.
Previously, on this show, this is my fourth attempt at getting some awareness on where we are, I started in RIPE 82 with Why‑PI presentation. Then I retried at RIPE 88. And then at RIPE 89 I tried to sort of pull one strand of the, of cleaning up, which is looking at the status of things, and that was deemed too complicated.
So, here we are today. And here is a picture from my opening slide. This is AI generated, obviously, but rough representation of what our current policy set looks like. On one side, we have stuff like RIPE 140, a trustee old aga, that has been there since your grandmother's age, that has been cooking the meals. There is the IPv6 assigned status, which is stuck in the drawer that couldn't open. Then, we have like the 2015‑04 which is transfer policy, you can see it's a bit more modern stuck in a corner. And, you know, there is some inconsistencies, we have multiple clocks and they are all different times. And I didn't even point out the clock on the microwave because that's different still. And of course they are it 2023‑04, which is aggregated by LIR for v4.
.
It's a bit of a mish‑mash of stuff, and I previously had a presentation, had like the three Cs of address space: Complete, concise, consistent. And my conclusion of that is, we are basically picking none of them. And I mean one would be good, two would be very nice and three would be inspirational.
There is a bit of a problem with that, because yes, not having a complete policy is okay, and the reason why that is? Well first of all we are incredibly nice people, we are very understanding. And also the RIPE NCC absorbs the ambiguity of what we have, as a community, failed to define. They will do tea leaves or I don't know what the exact internal process is, they come up with: How does this work? How does this apply?
And if you are trying to fix policy, which we have again recently seen, you are ending up in a pretty much impossible balance between this proposal is too complex and this proposal doesn't cover my particular corner case, X. Both are true. And in the current structure, trying to fix one makes the other one worse. So you can have, I mean completely random, you can have like Version 1 of a policy proposal trying to be as complete as possible, then gets to ‑‑ you get to the point of proposal is too complex, then you take that to heart and say okay, I'll cut the corner cases out of this proposal, and then you get the feedback, it doesn't cover X. And time passes and no progress is made.
Here is another thing I dove into. This is my representation of the participation of the Address Policy Working Group mailing list, where you have, I have the number of unique posters, as in unique people posting anything in a given year on Address Policy. I went through my 20 years of archive, yes, I am sorry, I am also sorry for myself. But I also did a refinement of that because you can have, you have got basically one and done, people say, I don't like this, or how do I apply whatever, random posts. So what I then looked at is okay, so what is our engaged core looked like? People who actively participate in discussion? So, that would be people who have done five or more posts on Address Policy, and they are not working for the NCC and they are also not Address Policy chairs. So, you see that the line was ‑‑ I mean, 2006, that was like 60 people going into around 110, by the time of 2015, when the fierce debates were ongoing about last /8 and who could get a little bit more address space. Then you see that discussion being over, you see it dropping back down to normal levels, and then Covid, and then where we are right now.
We are basically down to a quarter of our maximum engagement. We are down to less than half of what we had 20 years ago. And this community, and the number of people coming to RIPE meetings was quite a lot smaller.
So, what is the Address Policy result of the 2020 so far? There is really two kinds of things that got accepted. One is a feature parity thing where we ported the aggregated LIR from v6 policy to also include v4. That was accepted. And there are some arithmetic things and parameter tuning to change this number up by 5, to closer this number by 3. That got accepted as well. This is the sum total of Address Policy results of the 2020s. Everything else has failed. I don't think that's a particularly great look. And it's not because we're perfect and we're done. I mean that's where we started off with for the complete concise and consistent. There is certainly stuff to clean up. And where actually currently I think failing to clean up after ourselves which I think, and I have pointed it out in a presentation before, that amounts to gate keeping. It's not getting any easier for anyone to come into this room and participate. And as the graph is showing you, we quite desperately need more people to come and engage with us, right. So, we need to clean up after ourselves. It's gate keeping, even if that's not intended, so we really need to look at how we are doing this.
So, we have a control experiment. There once ‑‑ once upon very long ago, there was a status on allocated PI. Which is I mean, if you are deep into Address Policy, is a deeply confusing and weird status. So, in 1996, that was introduced, I guess for feature parity sake, I don't know. Then 2016, the Address Policy Working Group had feedback on a conversion project that the RIPE NCC instituted to get rid of that thing. Then in 2018, we had 2018‑03, that actually removed the status. And eventually in 2020 it was completely dropped from the Whois code. So that status has now been dead for close to a decade. That's good, it evolved getting a proposal and we got some stuff cleaned up. That's excellent.
Another control experiment. Spelling errors. This was my Why‑PI presentations. Spelling, Why‑PI at RIPE 82 found out that there were 12 different spellings of a single status value live in the database. And when I came back and did the presentation, those were all gone. And I mean kudos to the NCC for cleaning that up.
But note the lack of policy proposals here. There was no ambiguity, that was all fixed, that was all fine. So, rot in the database gets fixed when we pointed at it, and rot in policy needs the PDP. In order to get the PDP we need to have people engaged and involved and get consensus.
So, let's see if we can make this more accessible. That's really the point here. Knowing what structure you're operating in.
There were a couple of requirements that were raised during RIPE 89 when I was doing my last presentation. It needs to be in small pieces. You need to sort of scope the direction, vary the clean slate direction first. You need to be forward only, so no retroactive rewriting. Sure. And people are very attached to contractual statuses, so that has remained visible.
So are, the proposed framework is to aggregate per topic, and this is really just a framework as an index to start, it's references only so we're not moving any texts. So policies as published under numbers are what they are. And that Index will have chapters for v4 related, v6, ASN, transfers, special purpose distribution, contractual relations and all of the registry adjacent policies and global. And then appendices to actually give a bit of context and history, like a changed log and how the NCC actually interprets some of that on the operational side, the NWI register, which is on the database side of the house, but also impacts Address Policy sometimes, and some of the retired stuff.
So a notional example right now is IPv4 is the general v4 allocation and assignment policy including the waiting list policy, and it currently points to RIPE 826.
Very simple.
So, what I would like to do is discuss right now and on the mailing list if this framework is something to move forward with. To be very clear, the framework itself contains zero policy, right. It is just references right now. If we move further, when we move further, we will have a separate discussion about that. And I mean, I already have offers to help with writing this from Leo and Tina, so Thanks to both of them. If anyone else wants to come join that effort I would very much like to hear that.
And that's my first presentation.
(Applause)
ALEX LE HEUX: We have a question from the Internet from Jordi Palet from the IPv6 company. "I recall having proposed this already a couple of times and I think we need to act. Count on me as volunteer. I think the RIPE NCC staff should be involved as well. It is clear that we aren't proposing existing policy changes. In any case, I think we should go further and in a follow‑up step integrate the text of what duplications, correct errors not just references. That's a more heavy task because some changes may be interpreted by some folks as policy changes even if it's not the intent."
REMCO VAN MOOK: I thank you, Jordi, thank you for volunteering. And I pretty much agree with everything you said there. Thank you.
BRIAN NISBET: Just wondering, and I may have missed this, is this framework intended for just Address Policy, the policies that come through this Working Group or all of the policies?
REMCO VAN MOOK: Eventually we can add all policy in there. So Address Policy is an obvious one to start with, but adding like chapters on database and security on whatever else. Right now I have orientated this in a direction of Address Policy because that's where we are here right now, but if it we have this structure for Address Policy, it only makes sense to put the rest in as well.
BRIAN NISBET: Cool, start with Address Policy and hopefully... cool, thank you.
AUDIENCE SPEAKER: Tom Hill, BT. I do like this ethos, even as someone who does have a relatively decent understanding, albeit probably not perfect, around the policy documents and what's in them, a lot of it is that's what I remember, not I have actually been looked at it recently, and so, a bit rotten, brain rot and everything else in between. So to have almost a Wikipedia style reference that points to all these policy documents is a really wonderful idea and I sincerely hope that the community can understand the difference between that and refactoring policies, and perhaps this will make it easier to see them as a whole.
REMCO VAN MOOK: Wikipedia is a nice analogy, I'd like to think of it as like a GIT where I can do GIT blame and see who is responsible for writing all of crap into policy 20 years ago.
AUDIENCE SPEAKER: That's step 2.
REMCO VAN MOOK: That's Facebook step 4. That's a general direction I would love for this to end up in.
AUDIENCE SPEAKER: In any case I am fully in support of the work so thank you.
TOBIAS FIEBIG: I am also in general in full support of the work. I am not yet sure whether there is a fitting document framework for that. And how that list should then handle inconsistencies, because like one big fear I would see, if we talk for example about IPv6 policy that we do have much different policies that are inconsistent towards each other. For example, the minimum assignment size. And there, I think is the biggest threat because one might feel inclined to put a clarification next to the reference.
REMCO VAN MOOK: So I will ‑‑ so the whole notion of this is exactly, to stay away from the clarifications here because that would be redefining policy. I am very much and very strongly advised also against touching policy at this point. This is basically baby steps, right. This is where we start and yes, once we have all of this in one structure, we can start thinking about removing the references and moving the verbatim text, so instead of pointing at here is RIPE 826, you can go read 826, we can just stick 826 in here. In terms of document structure, yes, we need to figure out what that looks like. Initially it could be just a RIPE document which we can publish outside of the PDP even if need be, as soon as policy starts being touched we should of course run it through the PDP, and there is a wider more technical issue with the PDP which states that policy, when accepted, needs to be published as a separate RIPE document. So we might want to refine that a little bit eventually. But this is baby steps.
TOBIAS FIEBIG: To say something I am going to regret tomorrow. Count me in.
FRANZISKA LICHTBLAU: And maybe one point, if I recall correctly, there was already some work done by the NCC, at least on the website, to put policies into categories, so we already have something like that to look at. In that sense, it would already be the sensible next step to actually put that into a document.
PETER HESSLER: I am co‑chair of the Database Working Group and I am speaking on behalf of the working group. This is all very interesting work. This is something we look forward to seeing. We definitely would like to participate at some point in this process and it makes sense also to bring in a lot of the database documentation within this framework.
My main question is not around the collation, because that's a relatively simple process effectively. It is about the unification of the various conflicting definitions that Tobias had also mentioned. I think that should be an early, probably an early second step in trying to address those issues, or at least collecting where the conflicts are.
REMCO VAN MOOK: I wish I could show you a previous version of this presentation, because that was in there, and after consulting with a lot of people, decided, you know, what, let's baby steps again, let's get this hurdle cleared first and then we can move forward. But I mean I am a hundred percent in agreement.
PETER HESSLER: This is tackling a mountain, let's work our way up from the valley.
FRANZISKA LICHTBLAU: We actually wanted a session where people agree on stuff and we get somewhere. But yes, we actually had exactly that discussion.
MAYNARD KOCH: So let me spoil the consensus here. Of course, dissent is my second name, you knew that! I think it's a lot of a goal, and that's a wrong, that's a miss naming, I said Peter, just for the ‑‑ just so that the record is set straight and no other poor guy is suffering for my words. Any way, I think the last attempt to do this was pushed back for good reason or to do similar things. When you say baby steps, my paranoid policy ear hears "boiling the frog in the water". Now, that's not the intent you have and not the intention that the group has, but there is of course a significant risk and Jordi alluded to that in his contribution that fixing errors or clarifying things is actually changing the policy, because the text, as it stands, and much of the text has a lot of badge already, has precedent by being applied and that precedent would also usually influence decisions that are based on that policy. So even if you take the text and republish it, not by reference but somewhere else outside the policy development process as you said, I think there is a significant risk, while at the same time the need for new policy is probably declining because v6 is mostly baked and we are dealing with significant edge cases only. So, I am ‑‑ I wish you all the best. It should be stopped, but we need to be very careful not to over do it.
REMCO VAN MOOK: The way I intend this to work is we can basically stop at any point in this process and have made progress, right. So, any step towards a fully unified singing, dancing, interpretative, whatever, is great. Every step adds value and we can decide where we want to stop this.
AUDIENCE SPEAKER: Yes, says the avalanche. Thank you.
FRANZISKA LICHTBLAU: I think we have a comment from the Internet.
ALEX LE HEUX: We have a question from the Internet from Petra from DLREV. "Would that make doing changes harder?"
REMCO VAN MOOK: I would hope it would achieve the exact opposite.
GERT DÖRING: Taking part of the blame for the existing mess, I need to disagree with Peter, I am just not sure what about. In general I think this is a reasonable thing to start, because baby steps, manageable steps, visible progress.
I do see the need for clarification of some of the texts of unification, of definitions and so on, and it's very clear that these have to go through the PDP, because it needs to be ‑‑ the new language needs to actually have confirmation that it is still the intent behind the text. As you say, there is ambiguity and ‑‑ if we are not sure about the intent it's hard to rewrite it to have the same, or a still valid intent. But I assure you you all know this, but I am just stating the obvious.
REMCO VAN MOOK: In any sense, don't let drafting this block people shooting for clarifications. I mean Marco, I don't want to throw you under the bus, but I know you have got a good dozen or so clarifications that you, I mean that would be helpful to put through the policy process at some point. And I can only encourage you to start feeding them into this group, even if it's like two word changes or shifting a comma, any improvement is welcome, and anything that makes life easier for new people to come and help us out is actually very, very helpful.
AUDIENCE SPEAKER: I am not finished
GERT DÖRING: The last one is quick. The PDP can be changed. It's a task for the wider Plenary. We know where they are. So, let's just throw the ball over there.
REMCO VAN MOOK: I mean let's get this thing sorted out and we can have a chat about how we update the PDP.
AUDIENCE SPEAKER: I like to speak as a member of the community. I see that when some policy has to be created, there is a bit of barrier of entrance, let me clarify. So if I don't have everything figured out, so know everything as a specialist of all the nooks and crannies of what is said in any policies, it's very hard to advance a proposal. So I was wondering if sometimes it would be better just to understand what is the goal of a policy proposal to understand what can be done and then the senior experts, technicians will know pretty well how it goes. Start from the idea and start building a policy together because what happens sometimes is that if the language is not perfect but the idea is nice, as you were already explaining with the clear example, the policy cannot go through and then it's totally discarded but maybe the idea behind was interesting and to be pursued. So...
REMCO VAN MOOK: Absolutely. And I think, I mean I already sort of mentioned the reading tea leaves that the NCC has to do. So one of the things that is part of the policy development process and policy proposals is the rationale behind the proposal, and a lot of that, even if it doesn't end up being the actual policy text, is usually helpful to try to establish what was intended.
AUDIENCE SPEAKER: Maybe my suggestion could be, if there is a good idea behind, maybe could be interesting to have, I don't know, a task force or something that works on the idea and then writes little by little a working proposal.
REMCO VAN MOOK: I would love that. At the same time, it's 24 people right now.
FRANZISKA LICHTBLAU: Also let's not have a task force proposal, but actually seriously, this is also what we as Working Group Chairs are for. If you have an idea and you say hey, I have a structural fix, I have an idea, but I don't know like the language, the wording, you can and should always come, reach out to us, we can guide you and help you doing this. We also have Angela to guide us through the process. We can always go to the NCC, figure out what is the interpretation. And that, for example, we can also find you seasoned experts and co‑authors for policy proposals, that's actually kind of our job, and the fact that that is not clear to everyone, actually means we should make sure that people are aware.
AUDIENCE SPEAKER: Yes, thank you. Even to make it easier for others to joinery and go higher than 24.
PETER HESSLER: Speaking on behalf of the Database Working Group again. We do agree with Peter's comment that we have to be very careful on the collation versus correcting steps. They must be absolutely separate. We will insist upon this. This is acceptable to call out. There is a conflict between proposals, you know, between accepted policies one and two, please do call that out, that makes it easy for us to identify where the work belongs. There has to be a separate unique step.
REMCO VAN MOOK: Yeah, absolutely.
JIM REID: Thought provoking talk as always Remco. I am a burnt out, cynical engineer from Scotland speaking solely for myself. I have a got a semi‑serious, semi‑flippant comment to make. You said a few moments ago, we can stop this at any time we want. Why not stop it now?
REMCO VAN MOOK: I mean, so... okay, I am going to be brutally honest here. This is the last ‑‑ this is my last attempt at doing this, and if this room decides that this is not a worthy proposal, do you know what, it's going to be 23.
TOBIAS FIEBIG: Maybe to respond to the question why not stop this now? Well, I plan to be in networking in this region for a couple of decades from now. I would like to clean this up some way, so if somebody is motivated to clean it up, let's please do this because it's like the next 35 years of my life.
FRANZISKA LICHTBLAU: Thanks everyone. I think we actually had a discussion this time.
REMCO VAN MOOK: Excellent. Amazing.
So, now I do the weird thing where I walk off stage and walk back own.
FRANZISKA LICHTBLAU: You can stay, that's fine, so we don't confuse the room. So now we go to Remco's draft global policy proposal..
REMCO VAN MOOK: Alarm bells should be ringing. Global policy proposal. Does anyone remember ‑‑ okay, who in this room has been involved with drafting global policy? Raise your hand? Usual suspects. Okay. Yeah, and I am still taking the medication!
So, quick introduction on global policy for the people who haven't been there before.
Global policy is our special sauce policy that happens between the five RIR regions where the five RIR regions draft policy text that relates to the IANA function and stuff that IANA does to the RIRs. And that policy is then word identically agreed by five communities around the world. And after that approved by the ICANN Board of Directors and the ASO AC has a shepherding role, congratulations, Herve, in seeing all of this through.
Now, IPv6 and extraterrestrial networks. You can see this as sort of the ‑‑ are part of the opening dance that the IETF is currently doing with developing a standard that will ask IANA to designate a block of IPv6 address space for extra‑terrestrial use. The current draft text of that refers back to the NRO to figure out how to use that block. I am not sure if the actual no text is correct but that's an IETF discussion, it's not our document. There's been a policy proposal in the ARIN region earlier this year to designate ARIN as the "Space RIR" that receives staff feedback that ARIN would only do so on an interim basis and only with the direction from the NRO and its Board consent until a space region RIR got organised.
Further move, there is ongoing discussion on the IETF mailing list that actually flamed up again last week, whether that new block should be part global IPv6 Unicast 2000/3 or not. And my take on that is, dear God, no.
The problem statement. What are we looking at here?
.
So, first of all we need to figure out how does this new block relate to our current IPv6 global unicast?
And second, what happens to existing IPv6 allocations that are already flying in space somewhere? I don't know how many there are, but there is bound to be more than zero.
Then, a more fundamental point is: Well, the NRO, or if you want to read it as the RIRs, currently have no remit for outer space. And the ICP‑2 language, and also the updated ICP‑2 language falls short because it refers to "Community consensus on a continental scale", which is a short phrase but fails in at least three points; namely, community, continent and scale.
So we need to figure out how we're going to organise that. Then there is some confusion over the appropriate address architecture to be used. Are we going to have multiple RIRs in space? It and are they going to do allocations from their own blocks or are we going to aggregate per planetary body and at what scale do we call something a planetary body? There is a bunch of stuff out there. Then more concerningly, something we didn't think about really, current IPv6 and IPv4 as well, but this is about IPv6‑only, has an unstated assumption in pretty much everything that is running IPv6 of a terrestrial level latency, TCP retransmits, Whatever ICMPs, whatever, everything assumes that if you don't get a reply like in three second or so you re‑try. The if you are one way latency to mars' 12 minutes you can see how that just doesn't work. And see if we can isolate that a little bit.
And finally we need to identify a clear handover point from the point where the IETF does its thing in making sure there is a block available to IANA, and the RIR side of things where we decide okay, so this is what the address architecture looks like, this is the set of accepted policies that we apply to issuing space.
So, why global policy? Well this will be a new block next to the current IPv4 and IPv6 Unicast and ASNs. And global policy it the only stick we have that defines how IANA allocates to RIRs.
Why use global policy? It's the only tool we have.
So, what do we want to achieve on a global policy?
Setting you boundaries. Only start allocating from that new block once we have an architecture and an Address Policy in existence. Also ensure that only one kind of IPv6 can actually be used off earth. Don't mix and match. Don't have ‑‑ don't get a block for, I don't know, mars, and then allow people to say, well, actually I would like to have regular earth IP addresses on mars. You don't get to pick and choose.
You want to safeguard the current assumptions about latency and reachability for global Unicast, and the address administration assumptions, I mean the ICP‑2 aspect of it for example are very much to be determined.
Now, that also probably means that we are going to need RIR level policy as well. Because global policy only deals between IANA and the RIRs, and eventually any RIR shaped object will have to do something with that space and allocate it to LIRs or SIRs or I don't know what you want to call them. So the same fundamental problem set exists at the RIR level.
So I'll just go through the draft text that I have right now and all suggestions and comments are very, very welcome.
So, the abstract of that global policy is "This policy governance IANA allocations to RIRs for infrastructure beyond the geostationary earth orbit ARC."
I mean, if that, if we can find a refinement for that, I would be very happy with that. This is the best I could come up with with.
"The allocation hold in section 3.3 takes effect on ratification."
So we have a hold that we put in.
"The restriction on global Unicast allocations takes effect when we start using that space block."
If restricts new allocations from the IPv6 global Unicast for that purpose and places a hold and pending architecture and subsequent registry services policy.
The global policy on the table, or that is about to be on the table does not establish itself an allocation regime for the designated space governing its use or its earlier IANA allocations. So none of it is retrospective, retroactive.
Definitions. IPv6 global Unicast address space. We didn't really ever have to come up with a name for this space to make it ‑‑ to distinguish it from other space. So, we'll need to come up with a name. Then the architecture is like, what does address allocation look like. And architecture look like beyond the geostationary earth orbit. And then there is the designated space, which is the block that IANA will receive as a result of IETF action.
Activation of the address space requires all of the following. We need to have a published architecture. We need to have the space recorded in the applicable registry. The we need to have policy for registration registry services, and that has to be published. And IANA has announced this designation and given notice of activation. So we have some lead time so we know exactly if ‑‑ we don't get jumped with the data now it's different there has got to be a bit of a time gap in between so we all know when it's going to happen.
Conditions:
Once activated, IANA must not allocate IPv6 global Unicast address space, basically 2000‑/3 to an RIR for the purpose of use beyond earth.
Allocations made by IANA from the global Unicast address space before activation are not affected. That's a clear carve out.
We must not allocate part of the designated space to an RIR unless the architecture and the policy have been adopted.
And apart from that hold, this policy does not govern allocation, administration or use of the designated space on earth or anywhere else. And satisfying, just paragraph 3 doesn't itself authorise allocation. So we have to fix the documentation first. We have to fix the architecture and then we can start using it.
Then finally, reporting: IANA will announce each designation, and the conditions and the activation dates.
And that is pretty much it.
Now, this is a whole bunch of stuff. I am currently looking for people who would like to help me get this thing drafted and launched in the various RIRs. Thank you, Angela. And see if we can get this pushed forward in parallel with the activities that the IETF is doing, and with that...
.
JEN LINKOVA: Just a minor, first of all thank you for doing this. I have never been involved with this global policy stuff so I understand it's a very hard job.
Your slide with the ‑‑ like two slides back. Conditions: A question, probably a stupid one. Are you saying IANA must not allocate from global Unicast, which you probably need to rename to dual Unicast or something, To space. Do we need an opposite statement that space block should not be used by RIRs, it's going to be RIR policy, so you could not allocate for your residential customer from the space block.
REMCO VAN MOOK: I mean that would be amazing to find that in address architecture to see how that works. As I commented in Edinburgh, I mean one of my main takeaways from Tony Lee's presentation of Address Policy is that earth is in space!
AUDIENCE SPEAKER: Herve. It's about as you can imagine the possibility it could be global policy because you presented it as global policy. And so we are here, Ondrej, and I as part of the ASO AC. I am the Chair of the ASO AC, so, we have the responsibility to look after the process of the adoption. But before that, we have a sub‑group within the ASO AC which is a PP FT, so the people who are looking at the discussion specifically in the different regions. Ondrej, you are the member of the PP FT of that, so perhaps you will report to me at one moment there is a discussion about a potential global policy. I proposed to you to read our operational procedures, 6.4, so there is a specific process regarding for the beginning of the discussion about that and the spread in the different regions.
REMCO VAN MOOK: Okay. Thank you.
AUDIENCE SPEAKER: I am not responding as an AC member. As an AC member I'll be supporting you here. My question is rather, so what you said, architecture is not there. The ‑‑ we are not sure IPv6 will work at all, so it's essentially experimental, and I am too young to remember, but there was this thing 6 bone, and I wonder if lessons from 6 bone give us exactly that proposal or alter active ways to address this problem?
REMCO VAN MOOK: I am ‑‑ I thought this for a while, and I am not going to touch the topic of whether IPv6 works at all in space. The I mean I'm not going to touch it with a barge pole, I am not going to go anywhere near T that's up for the IETF to figure out.
AUDIENCE SPEAKER: I was referring specifically to how address space was allocated used and phased out.
REMCO VAN MOOK: Yeah, absolutely. I mean the 6 bone is an interesting example of very early deployment and then later retraction of address space. That might apply here, but again that is ‑‑ we'll have to see how that goes.
AUDIENCE SPEAKER: My point was, do we see any analogy here and whether this analogy informs our decisions on that particular topic?
REMCO VAN MOOK: In all honesty, my personal feeling is I don't think so, because 6 bone was stuff on earth that got replaced by other stuff on earth. Mars is not going to be on earth any time soon, I hope.
ALEX LE HEUX: There is a question from the Internet from Petra. "What are the expected users for the space block?"
REMCO VAN MOOK: I would love to know.
AUDIENCE SPEAKER: Thank you Remco for summarising it, it was a nice presentation. But as other people already said, the detector is actually the key factor here because we cannot run this. You already said that terrestrial IPv6 will work in space in a long distance. Maybe discussing how far space reaches is maybe another topic, but I think that if we start with IPv6 here, it's my opinion that we will have a minimum of one or two approaches to work with this and to find new stuff there. It could even be that we are not using IPv6 at the end of the day, so therefore, make it really a bit careful not too much and to have a close look at what they are doing there, that would be my suggestion.
REMCO VAN MOOK: Absolutely. One of the things is it's good to know and also to mention in this group, is that the actual transport protocol for space, the deep space network right now is the bundle protocol, BP, not IP, and it is ‑‑ and these people have tried for a very long time to make TCP IP work, so terrestrial normal TCP IP work on that network was not a large success, but even from the bundle side, the necessity to have like an identifiable block of numbers has been raised.
AUDIENCE SPEAKER: One last comment, I had a discussion a few days ago about this and the guy said, he talked to people and they said who will use IPv6, it's much too big? We will use v4 forever in space.
REMCO VAN MOOK: Everyone is welcome to have their own RFC 1918 Internet in space, absolutely.
FRANZISKA LICHTBLAU: I would actually like to ask you to clarify your answer you gave to Petra earlier on because you said you don't know who the intended users of this is so maybe contextualise this, where is this coming from and why this is unclear because especially given her background?
REMCO VAN MOOK: I mean, that's fair enough. There is currently a couple of projects under way, some large companies in US Government contracts that are looking at building infrastructure on the moon and mars. There is companies like SpaceX who are looking to ‑‑ I mean have already set their plans on doing something that is very definitely not on the planet. That's roughly the direction you should be looking at for early users of this.
FRANZISKA LICHTBLAU: Thank you. Aaron?
AUDIENCE SPEAKER: So, first, thank you for taking this. We are putting more work on your plate. Thank you. Capable of answer to the question that was addressed to you also in the room. IPv6, like IPv4, work in the space of neither ARP nor nibble discovery works, thanks for the time‑out so IPv6 could work, that's not a problem.
Regarding the user, potential user of the address space, this will be indeed not only the SpaceX, but also the mobile provider, there are multiple projects to have 6G running on the moon and on mars, so that's...
And to come back on the IPv6 thing, usually the issue isn't a transport layer, right, so TCP is a no‑go. So we need to use QUIC, but with a non‑default timers and same thing right. Other topic will be about DNS, that's upcoming because people want to get a specific TLD for this.
REMCO VAN MOOK: I wish IETF and the TIPTOP Working Group in particular would help me figure this out.
AUDIENCE SPEAKER: And normally TIPTOP the users of the first document will be submitted, mostly in the coming weeks, so we'll get a first RFC out of TIPTOP in the summer and the architecture is mostly defined as well so expect something there.
PETER HESSLER: In previous jobs, I did work in the space industry with communications and friends of mine still do this deeply as their primary job, so I have seen a little bit of the inside of how that sausage is made. One comment I should give is, the definition of geostationary earth orbit, I highly recommend that we just, you use that as a textual phrase, I think it's a number of kilometres from the centre of earth. To be extremely clear to both the network nerds and the space nerds.
REMCO VAN MOOK: I was struggling to find a single, logical definition that would be workable. I could say 40 thousand kilometres, whatever, and then people are going to go how many miles is that.
PETER HESSLER: For the reader but I also think that effectively the boundary should be approximately where the default TCP timers no longer work. Approximately. You know, pick your favourite like where ‑‑ does neighbour discovery work? Or the standard earth protocols no longer work, that's now space.
REMCO VAN MOOK: That's something, that's exactly one of the phrases I would very much like to clarify and nail down before we actually enter a global policy proposal process, because doing revisions in global policy is an absolute pain.
PETER HESSLER: Of course as we all remember in the glory days of classful addressing we had different definitions of what was Unicast versus multicast so we can use the same concept and say this address range is classed space.
REMCO VAN MOOK: Yes. Thank you.
FRANZISKA LICHTBLAU: I am also closing the queue. Peter.
AUDIENCE SPEAKER: Peter Koch, thanks for that presentation. Great thing. Also thanks for being proactive here. I am following the TIPTOP discussion, I do think that there is a couple of policy questions that haven't been responded to and some that even haven't been asked before going ahead. Now, my reading of this proposal is actually that this is not a constructive one, it's a defensive one, so what it essentially does, if my reading is correct, it prevents IANA and also therefore the IETF from designating parts of the global Unicast address space, which is only a fraction of what could be the overall IP address space, prevents them from designating that part for the particular use or for that purpose. It doesn't, though, prevent anybody from holding address space from using it in space. Nor does it prevent an RIR to hand out address space for that. So the only thing I see is this is, this is a stop sign to the IETF, and IANA in that case. What could happen of course and that could be the consequence of these policy questions, that when the IETF designates something, it won't be ‑‑ it could be completely new section of the IPv6 address space that would be, would have a different name and it would also not necessarily be subject to RIR ‑‑ sorry, global Address Policy or by distribution to the RIR. Is that reading correct? You are putting a lock on that address space?
REMCO VAN MOOK: No. I mean no is not a fair answer. A little bit. What this tries to do is disconnect the decision‑making process on the IETF side from the decision‑making process that inevitably needs to happen on the RIR side as well being able to collectively get something meaningful done. And in that sense, is it defensive? Well, it is proactive. We want to have a structure in place, at least I want to have a structure in place, where IETF can have their deliberations and their decisions where and the RIRs can have their deliberations and decisions informed by what's going on there without basically having to get chased into accepting policy because there has been an IANA decision. That's what I'm trying to do.
AUDIENCE SPEAKER: What do you mean by IANA decision in IANA is not there to make decisions.
REMCO VAN MOOK: No, but there's been a decision to give a block to IANA.and then the next day someone raises their hand and I'll have some thanks and then we're all going to be looking really stupid at each other how do we do this? I don't know.
AUDIENCE SPEAKER: But the policy setting body for that newly flavoured address space would still have to be designated and it doesn't necessarily have to be the RIRs.
REMCO VAN MOOK: It doesn't have to be any existing RIR, exactly. So that's the TBD on the administrative body. We don't know yet. So, if we don't know yet, then how do we move forward? And the only thing that this is trying to achieve is to pull those, pull the two decision factors sort of, pull them apart. Make sure that everyone reaches their own decisions in their ‑‑ in the time they need to come to a sensible decision without one having to chase the other.
FRANZISKA LICHTBLAU: Let take this offline we are running out of time.
AUDIENCE SPEAKER: There is one thing I want to bring up. You didn't talk about aggregation here. I really wanted to put something about aggregation into this because I think it's important like since, Peter said you are putting up this big ‑‑
REMCO VAN MOOK: If we can come to an agreement on where we're going to aggregate, then would I love to put that in.
AUDIENCE SPEAKER: I think there is substructure of the passed the first RIR TBD stuff.
REMCO VAN MOOK: I mean if we're going to have five RIRs allocating into space and then we end up in this situation where I have got, I don't know, AFRINIC mars and ARIN mars for all I know, which are two completely different blocks and we would be loosing the aggregation at planetary level, this is going into the discussion that I would very much like to have on the IETF side of the fence and what you know they think that should look like.
FRANZISKA LICHTBLAU: I assume that answer was so informative we lost two people on the microphone. But we are good. You see, aggregate.
REMCO VAN MOOK: I am aggregating answers. That's crazy.
FRANZISKA LICHTBLAU: Okay of. With that I think we'll close this one and we go over to our next presenter.
(Applause)
JAMES KENNEDY: From outer space to the RIPE Database. Sorry to bring you back down‑to‑earth with a bump.
Hello, good afternoon everyone. I am James Kennedy, I run an independent IP address management and strategy consultancy, and today I want to talk to you about a policy proposal I am working on at the moment, and not yet published, I spoke to a few different individuals already, but I want to share it with the wider community, and get some input and get some discussion going. That is the topic is naming organisations using IPv4 PA blocks in the RIPE Database.
So, a bit of background first. RIPE Database Requirements Task Force, some of you might remember. We worked for a couple of years we revised the RIPE Database purpose, how it's used, things like this, over two years and we developed a report, RIPE 767. A lot of interesting detail in there. Will today I want to focus specifically on recommendation 6.1.2 which is "If a resource holder wants to sub‑aggregate or partition part of their v4 resources to another entity the task force strongly recommends to document that allocation or assignment in the RIPE Database" and to be verified through ARCs.
Coupled with the data accuracy principle 5.1, also in the document, it recommends that data accuracy should facilitate contact with and identification of the organisation holding the assignment.
Also, we have separate, we have data management principles, data consistency principle, which is also relevant I wanted to include. Resource registration requirements to be applied consistently to all Internet number resources regardless of status or type.
And, you might ask, well why am I bringing it up now? It's been five years since that document was published. Nobody actually I think went forward with this recommendation to the Working Group and to have a discussion. So here I am. And it's been reported from Virginia Tech this year that third party use of space is growing up to almost 30% over the past four years. I think now is a good time to discuss this, see what the Working Group and community really wants.
So, in our system, we do have several different types of records with different purposes so I want to be specific in what I'm talking about today and what I am addressing with the policy proposal.
We have LIRs who are holding top level allocations who may announce space, who does announce space, they are all covered in a registry, RPKI, route objects, BGP, they are pretty much out of scope. What I'm focusing on is for organisations that are using PA blocks, That's the home for this is the RIPE Database, and within inetnum objects.
List here of other things that are out of scope because I know they'll stimulate those thoughts. So security and abuse handling processes, out of scope. That's already been discussed in this Security Working Group. That's where it should belong.
Private data, also get to the other points later on, they are out of scope, RIPE NCC enforcement processes, nothing new. Also new database objects types, fields. And LIR own assignments, so what the use for infrastructure, for access networks, point to point, things like this also out of scope, and individual host addresses.
So, Marco in May of this year in Edinburgh, for me there was a quite insightful statistic we'll say, he reported that of a third of ARCs that the RIPE NCC conducts, assignment information that they find is outdated, no longer needed or missing. And to me that gives an impression of the inconsistencies, perhaps, inaccuracies that currently exist in the database. And of course that's not the RIPE NCC's responsibility, that's our ‑‑ those are the LIR's responsibilities. You might ask, well, who cares? What's the point? LIRs are accountable. Well, on the wider scale, transparency, accuracy and consistency within the database does help a wide range of stakeholders.
I think it's key to keep in mind that networks, prefixes what not, they don't work in isolation, they are part of a large err ecosystem, Internet ecosystem with multiple stakeholders that are there to help ensure that, you know, operations, networks operate effectively and securely. And the RIPE Database is where people check to see who holds address space but also who use it, two different definitions. And many depend on the accuracy of the data to do their day job. To just list a few network operators, IXPs, transit providers, security team certs, block list intelligence companies, resource holders themselves, the RIPE NCC of course, public authorities, and researchers, policy developers, and yeah, you know, unless the blocks are registered in the database and are kept up to date, people don't know who are the actual users.
This was said after Marco's presentation also in Edinburgh on the mic remotely, that it is impossible to contact prefix brokers in the middle of the night to find out who is using the block of resources. So in this specific case a session was dropped, the operator didn't have any other details other than what's in the database, which was an intermediary, and it wasn't effective ‑‑ there wasn't enough information to effectively resolve the time sensitive issue, potentially it was time sensitive, they could not know because they couldn't find out how critical the session was. That's just one use case.
I did speak to a number of others, some in the room today, as well. So if you want to share more that would be great. So when we'll say the organisation who is using the block is not registered but only brokers, intermediaries, LIR, whoever, their uncles, it doesn't matter, so in the middle of the night again, if a session goes down, and action is needed on the users end, you need to know who is actually behind the block, if you want something done.
Also, for traffic is treated differently, can be, depending on who is operating the block for filtering and fraud cheques. Abuse handling, the reports when they need to go to the specific user rather than an upstream provider, could be the LIR or someone else.
Honeypots as well. So, when there is an issue when they detect that there is an infected infrastructure is useful to know if it's critical. If it's a hospital, if it's power plant or retail shop. In the case that where the user of the block is only ‑‑ when the identity of the user is blocked, they can only identify the autonomous system itself wider.
I also looked up a number of articles recently, there was quite a lot over the past couple of years on security systems that also act upon names and who is using blocks. I have at the end of the presentation a reference link, I recommend you to have a look and we can go through them briefly now though.
.
For investigations, Team Cymru followed RIPE records to find a virtual office that had thousands of registered companies. Also for sanctions, a threatened intelligence company last year, identified a fund company for a known Russian bullet proof hosting provider. That was sanctioned an then a few months later, that actual fund company was then also sanctioned.
Block listers. So Spamhaus do have a policy that says if their network listing is ignored, that they may extend their listing to wider networks related to the assignment. That actually happened in practice towards the end of last year where they identified ‑‑ well there was a prefix, a specific prefix that was listed, there was no action taken and they ended up listing the entire allocation that they cited RIR data not being reliable to reflect the customer user as one of the reasons that led to this.
.
There are malpractices everywhere in our industry and others. So I am sure there are brokers that might not do things correctly, but it has been reported by Spamhaus this year that some brokers have been seen to list prefix, listed prefixes to new users in their interpretation as an attempt to force delisting of that address space. And university twenty a last year found that blocked addresses in Italy were rereleased to other companies while still block listed. Huge oversight, you know, we'll say are these corner cases? Is it the tip of the iceberg? That's what the discussion is all about, so love to get your input, experiences and thoughts about these.
So, how to consistently name third parties in the RIPE Database. My policy proposal is to make the org attribute mandatory for these inetnum objects. How does that look in practice? Well not in practice, but we'll say a schema, a typical schema. So for an allegation that an LIR holds, what you see on the screen,s /16, org ID is already registered to the LIR within the registry, that's reflected in the RIPE Database. In this case, we'll say the first half of the block of the allocation is used for the LIRs own infrastructure. That's out of scope what we're talking about today is specifically blocks assigned or sub‑allocated to third parties.
And as you see in blue and in green and in yellow, I recommend the org IDs be added for those third entities. Third party entities.
For private individuals who are issued IP blocks, that does happen. For GDPR reasons, you can ‑‑ with the LIR org ID so that private data is ‑‑ remained protected. A final layer underneath a /22, 24, individual host addresses are the scope for this proposal.
How it would look practically in the database?
On the left you'll see what we have today. Org ID is optional, and I am proposing to have that mandatory for what you see in the right within green, so have that org ID. You will see the contact information and the maintainer information remains the same that does not have to change. They remain the primary contacts on that network. So if you are a third party providing some kind of services managing the network, that's all fine, that's what people will see once they click into the RIPE Database, but we'll say when needs to know for the aforementioned use cases they have got some way to find out who is using the network.
So as I mentioned, there can be quite a few parties involved in managing space also within the database. I think it's very important to keep in mind who is actually accountable for the address space. That remains with the LIR.
So, delegate different types of responsibilities, but the LIR is the one who is contracted to RIPE NCC and RIPE policies under SSA, the standard service agreement, and that includes, they are liable for all aspects of its use. That is also ‑‑ this is also reflected in the RIPE IP version 4 policy and the IPv4 policy as we all know includes registration requirements in the database with data to be correct at all times.
So the point here at the end of the day, if something goes wrong or if the addresses are not being in use, in compliance with RIPE policy, it's the LIR who needs to answer for this. So, they might be audited, if there is an issue, they have to rectify it. If not, they risk losing the resources.
So, the policy itself. A little bit of detail. I am happy to wordsmithing now if we have the time. I am getting a frown. So, essentially, as I have mentioned pretty much. Org ID for these type of inetnum objects in the RIPE Database. Third party can be subject to the LIR's org ID. It doesn't matter if the status is assigned or sub‑allocated.
Benefits include aforementioned we'll say operational security challenges that are being felt. So to help mitigate. To have a reliable record to help them in processes. To make sure the ecosystem is working effectively and securely. To develop greater transparency, consistency and accuracy within the RIPE Database for these type of objects. Also to link organisations and their IP resources, again not LIRs but users across different LIRs, but also potentially across RIRs. So I think that also can be quite useful to track and to be aware of and also to enable action, again specific users and specific prefixes rather than we'll say with Spamhaus earlier, block listing entire LIRs or their allocations.
Roles and responsibilities, also very important to keep in mind. So, implementation. As the ones who are accountable giving LIRs a certain amount of time to add org IDs to these type of inetnum objects. There will be corner cases, so I'm sure for some users of blocks, organisations, that it's sensitive and should not be put on a public database. Those type of corner cases, that's why I recommend a best common operating practice document be developed midway through, we'll say, potentially after impact analysis. To identify those and to give everyone clear guidance as to what's included and what should be at discretion.
Enforcement: As I mentioned, use RIPE NCC existing mechanism, the assisted registry checks. It's not for the RIPE NCC to we'll say Internet police, micromanage the community. It's also not for us to micromanage the NCC and how they conduct their work, but I'd recommend a light touch, could ask a simple question during the ARC if the LIR is aware of this new policy and if they comply, if they have any questions, point them towards the best operating practice document. And as we're using an org ID rather than free‑text search fields. So the description, remarks, there is a few others, it makes it easier to automate the script. Hence, save time and efforts.
And again remains unchanged is RIPE NCC how they actually handle policy non‑compliance. So, that's also has, was raised as a question to me earlier. I am not suggesting any changes in how existing registration policy requirements, so to continue as they are doing. LIR means accountable, no changes to the SSA. No creation of new database objects, attributes, fields. And no new enforcement mechanism using the RIPE NCC existing ARC and we'll say tools of checking chamber of commerce.
That's enough from me. So, discussion.
I have a few questions for feedback as I am working on this policy proposal at the moment. Have you encountered issues from not being able to identify users of IP blocks?
Is greater transparency, consistency and accuracy needed for these type of addresses within the RIPE Database?
Addresses and blocks, specifically.
And finally, we'll say policy scope. Yes, should have mentioned that ARIN already have this policy in place for any blocks of /29 or larger, need to be registered separately to those third party entities. So, the policy scope for the size of the addresses, of these blocks be similar to /29 or /24 a routable sub‑net or other?
.
So thank you for your time.
FRANZISKA LICHTBLAU: As a general remark, I would highly recommend to keep the wordsmithing to list, it is much better for that and focus on the general intent here.
PETER HESSLER: Thank you for bringing this up. We do have two numbered work items related to this.to I can that we have, let's say we have been casual about working on it, they are specific NWI 15, baseline requirement for registration information and tangentially W I 18, operational content information. I guess we could have a discussion offline where address space is the appropriate Working Group or database is the most appropriate Working Group. Either way, and announcement should be sent to both lists about where the actual discussion needs to take place. Thank you.
GERT DÖRING: Speaking with my LIR technical operational hat on. I totally don't like this. Because it means I get to do all the implementation work to get our automation system to actually create all this new argues al ID objects for our direct customers. There is ‑‑ nobody is going to benefit from it because we already have all our data there, the data has good quality, the contents that are there that can be reached so you are now requiring me to spend engineering time on getting extra objects into another database that nobody benefits from. So, from a purely LIR operational perspective, I don't think this is something I want. And I don't think it's going to help anything. The balance we have to have, who pays for it, who benefits from it, is this a valid trade‑off, and I think there is no benefit and there is cost. Those that want to put good data there, have it. Those that do want, will put something in there.
JAMES KENNEDY: I understand that there is, there is a cost/benefit to be evaluated for every type of policy proposal. I am aware that it's going to cost a bit of extra ‑‑ well depending on the size of the LIR, how many objects of the update.
FRANZISKA LICHTBLAU: I am closing the queue ‑‑
JAMES KENNEDY: We'll take into the cost benefit analysis. As I mentioned this is not just coming from a nice to have. It's for a lot of people, it does impact security and operational ‑‑ there are benefits. So I am happy to list them clearly and follow‑up with you later.
TOBIAS FIEBIG: I kind of think that in general, this is a somewhat good idea. I do have a concern which probably also Peter Hessler has which is the growth of the database, because if you are a sneer of five different entities, it is highly unlikely that they will co‑ordinate setting up the ARC objects, then you have five times an ARC object for the same entity, which would be resolved if that goes through the RIPE NCC, which was putting us to PI and which is a huge mess. I would leave out the exception for private individuals. Based on what Gert said, if people don't want to put good data in there, they won't the and then all those critical blocks will then have been, you know, given to a private entity, that's because that's why they put the org.ID in there, which is also problematic, and I would rather see something along the lines of everything that needs assignment and documentation in the database gets an org ID and those things that do not need an assignment and are to a private person, there we would have something for example like the aggregated by LIR status on the v6 blocks. Which is the final thing, if we do this for v4, I would like to do it for v6 as well.
JAMES KENNEDY: I am addressing it first with v4, and if it passes, then happily to bring it on to v6. With the private individuals, like I mention using LIR information, using LIR org ID, we're talking about blocks of addresses as well so using LIRs and contact information, and as you said, people can put in different data for these org objects, they could use shell companies, things like this. But the thing is there is no incentive at the moment for them to do things, we'll say, the correct way.
TOBIAS FIEBIG: The private person thing, like my objects also have nigh private information and what sponsored resources I have, that's also usually to individual and that private information is also there. So I don't see why we should make a distinction there when it comes from PA.
JAMES KENNEDY: In these corner cases best operating practices should have had allow what's out of scope and what's in scope. Shall we say.
AUDIENCE SPEAKER: This is a good discussion. If you can go back to the questions because I think I was one of the persons in RIPE ‑‑
FRANZISKA LICHTBLAU: Could you remind us of your name and affiliation.
AUDIENCE SPEAKER: Thomas. I think I was one the persons at the previous RIPE meeting mentioned if a BGP session goes down during the night, then I don't know who to call. But I have another ‑‑ I have encountered a number of other issues and it is that what do you do when somebody starts to ruin your AS reputation by adding route objects and you don't know who did it, or adding ROAs to your network and you don't know who did it. If I can't find the person that I can sue or that I can hold responsible and tell them: You know, you are ruining my network's reputation, then it's affecting my network, so that was another example that I gave.
The other thing I wanted to ‑‑ and we talked about this in private already ‑‑ I like that RIPE gives a good example by doing something like this, but I would like to see this in the other RIRs as well.
AUDIENCE SPEAKER: I think it's not a secret that we advocate for accuracy, consistency and transparency, I also remember that in the 767, there was a call from Europol also, so we are one of the stakeholders which actually benefit from it, we'll say yes to both the two questions. Just to say not even ‑‑ when I was working in the police we were contacting many times people in the night and we needed to know who was behind the results because we were working also on suicide and also on helping people, not only arresting people, and then time is crucial. The less layers we have to follow, the less steps we have to do to reach the end users, the better it is to find it and solve an issue, and many issues I see can be better solved with this which comes from cybercrime, hijacking resources and so on. So I think that it's a good start, this proposal, let's see how it goes, but I like it.
PETER HESSLER: With my commercial hat on this time. My employer routinely updates the RIPE Database with contact information from our customers based on the Admin C or text‑c depending on whether their administration is involved in the utilisation of the space or if they are technically involved with the announcement of the space.
As I said, we have already been doing this for 20 plus years, we're relatively up to date in the databases, asterisk, but because that's an existing thing that already exists, people already relatively understand this, would that be a better solution than adding a new attribute?
JAMES KENNEDY: It's not a new attribute. IDs already exists but just making it mandatory when you issue blocks of addresses to the third parties. Like I mentioned earlier, we do have several records that we use in our system for RPKI, for identifying who is the LIR, who is announcing who is allowed to announce and you mentioned now that Tech C, Admin C, it can be the user itself, it can be the LIR, it can be intermediaries, it can be somebody else providing that service and their details be added. Again, those don't need, the contacts don't need to change it's more about who is using the address at the end, who is updating their routers, their configurations at the end. That's who is going to be at contact if you click on the org ID behind the inetnum object. The inetnum object does not have to change.
PETER HESSLER: My other concern is in your list of examples, all of them were fraudulent, and I can predict with fairly good accuracy they will continue to be fraudulent, and they will give you either a bogus org ID, a fictitious org ID or themselves. So in those situations this will gain you nothing.
JAMES KENNEDY: Then they are breaking policy and they are liable.
GEOFF HUSTON: But they are already breaking policy.
JAMES KENNEDY: A bigger issue to be addressed.
FRANZISKA LICHTBLAU: I suggest we take that discussion to the list. We will publish the minutes earlier this time so everyone can come back to it and we can take up that discussion. Thank you, James.
(Applause)
.
And now we have five glorious minutes left for our originally intended 30 minutes open microphone. I am very sorry for that. What I would suggest is if anyone has any topic they would like to highlight and make us aware of, at least go to the microphone, mention it, and then we as co‑chairs can maybe approach you, have a discussion, or the Working Group can see that there is any interest. So, is there anyone who wants to bring something up?
AUDIENCE SPEAKER: Clara Wade, speaking for myself. I would just like to draw attention to the fact that I noticed there is over 20 that transferred this year in aggregate to a mix of investment firms and shell companies set up by leasing companies. I think it might be time to discuss needs based policy if we want to make sure, especially with an upcoming waiting list policy situation for this to not be abused in the region and scarce resources to be taken up for folks that are actually running networks.
FRANZISKA LICHTBLAU: I don't think we should have immediate responses for that. That goes to everyone. If there is anything that concerns you, approach us, we can connect people to each other and see if there is anything for this Working Group to take on.
Okay. Then thanks everyone. And as usual, I got this lovely piece of paper from the NCC.
Again, as before, the PC voting is still open until five o'clock, you know that, you can also rate the talks and it says here in friendly red letters, to it's important, the dinner starts at 7:30, and it's a short walk from the hotel.
So, I think I see you at the dinner then and have a good time. I think next up is the Community Plenary after the coffee break.
(Coffee break)