Address Policy Working Group
Wednesday, 26th October 2022 at 10.30 a.m:
JAMES KENNEDY: We are running a couple of minutes late, a technical issue with slides, we will kick off as soon as they are ready, give us a couple of minutes, please.
ERIK BAIS: Welcome back, everybody, after a well needed coffee break, nice to see we didn't lose everybody here. We are still trying to get the slides from Leo on the system. Do we have Leo on site? Ah, there's Leo.
LEO VEGODA: Hello.
ERIK BAIS: We are trying franticically to get your slides into the system.
LEO VEGODA: I have the slides here and I can share them remotely if that's okay.
ERIK BAIS: Yeah, let's see if that works.
LEO VEGODA: Share screen. Can you see?
ERIK BAIS: No.
LEO VEGODA: Can you see my screen?
ERIK BAIS: No, not yet.
LEO VEGODA: Let's try. I do want to share my screen. Can you see that?
ERIK BAIS: I don't see it yet.
LEO VEGODA: Okay. Maybe just to avoid people having a bad experience, I will go and talk and we will make the slides available later. They are mostly pretty pictures. I don't think the slides are essential; what's essential is what is being said. Does that work for everyone? So we don't waste people's time.
ERIK BAIS: Yeah, let's go.
LEO VEGODA: Okay. So, at RIPE 83, we essentially kicked off a bit of an IPv6 policy review noting that it was roughly 20 years since the IPv6 policy had been created. Obviously there had been small changes but the substantial body of the policy is roughly the same as it was when we moved from the boot strap policy, which is what we used when IPv6 was launched, like, at the turn of the century, to sort of the globally coordinated policy we ended up with around 2003.
So, the ‑‑ oh, apparently my slides are now in Meetecho, so that's nice, so let's manage slides.
AUDIENCE SPEAKER: Your slides are on the agenda page, too.
LEO VEGODA: Share pre‑loaded slides. Okay. So, here we are. So, at the last meeting, we got a report from Gert Doering, Kurt Kaiser, Sander Steffann and they had taken a look at where we were with the IPv6 policy, and they came back with what I thought was really quite a positive report, basically saying that it should be a little bit easier to get and all of the stuff that we started out with at the beginning was positive, and of course, that was reinforced earlier this week with the IPv6 panel when we saw some of those roll‑out statistics and people talking about networks going IPv6 by default, things like that.
So, we did have a few rough spots, some areas where we need to sand down the IPv6 policy, perhaps, and the kinds of things that they talked about were the kinds of things you would expect if the IPv6 policy had been developed by network engineers and hard boundaries, definitions that were either yes or no. And I think this is a recognition, perhaps, that we live in a world where there aren't always these very clean definitions. Sometimes, things get a little bit smudged and, so, we probably do need to do some work on the IPv6 policy, especially because, you know, we need to make sure that those people who don't have access to IPv6 now do get IPv6 to it in the future. One of the important things that is going to go elsewhere is an update to the route aggregation recommendations. I can't remember if that's going into the Routing Working Group or BCOP. The point I'm making here is that it's not going in address policy because it's routing rather than address policy.
In order to make things easier, to sand off those edges, some of the things we need to do are to take account of RIPE NCC feedback. The documentation that we give to users through the RIPE NCC could do with some improvement; some of the issues that were raised in that report that we saw at the last RIPE meeting essentially talk about PI policy and interpretation. If you have got just a couple of addresses used by another network, can you still get PI? And, of course, justifying a /47, there is this very hard barrier at the moment; anything up to a /48, no questions asked;/47, that's a little bit tricky. So, this is the feedback we have got from the RIPE NCC. At this point, we need to go back to some of those goals that are sort of listed in the IPv6 policy, so administrative ease and the uniqueness of addresses, are they all the same as they were 20 years ago or has the priority order changed? If the priority order has not changed, are there new goals and where should those be added? Because, you know, we are now the ‑‑ the system that everyone uses to get a job, to pay their bills, all of those different things, that means that maybe something that we didn't think about in 2002 when we were essentially developing the framework that is the current policy, is really important now, because we've moved on by 20 years.
So, we don't have a specific policy to discuss right now, but we do need to make sure that, if we do come up with a policy proposal for a change, we understand what that policy proposal is and there is a consensus that there is a real and well‑defined problem that we can go and put into a policy proposal. So, I would like to step away and listen to people in the room and I'd' also like to say that, you know, while we are going to have this discussion in the room, we are also very happy to run a couple of intercessional webinars or whatever the word of the day is, between now and the spring so that people who want to have an actual conversation, can have an actual conversation and we can work towards that clearer definition so that we can perhaps come back with something a little bit more concrete in the future. So, here we are, thinking about relative priorities, and now I'd like to hand over to Erik to look at people in the room and essentially coordinate this discussion so that we can work out where we want to go. Thank you.
ERIK BAIS: Thank you, Leo, for this short recap of what we already did since Berlin. So, since the last RIPE meeting, RIPE 84, there was a lot of updates on this topic. That does not mean that the issues that were raised are gone. I have also had a discussion with a Dutch ISP that had quite some issues because they actually planned to do v6 with /48s to their customers and instead of that, had to refer back to /56 because they couldn't get the documentation at a certain pace and they needed to move forward so instead of requesting a 25 I think or 27, they had to go with a 29, so, the amount of documentation that is needed, once you have a 29 but need more space, is substantial and there should be some guidance in the policy for how are we going to approach that because it should not be impossible for larger networks even though they are still rolling out fibre to document that and get the request, that they put in. We have somebody on the mic.
SANDER STEFFANN: It turns out I don't need to be in a different room at this point. Hello again. I was part of the group that discussed all these v6 policy changes and yes, the main thing in this case was like the steep jump in requirements like, we felt it's like this is completely no documentation at all and this is go write a full size ‑‑ go write a full size novel. That slope we thought should be more gradual.
One of the things and this is actually a question for the NCC because I remember back in the day, when you got a /32, the NCC would always keep three bits reserved for future growth, that's why we changed the policy to a /29 and not 28 because there were only three bits guaranteed to be available. Is that still the case? Is it still three bits?
MARCO SCHMIDT: Yes.
SANDER STEFFANN: Yes. That does mean that organisations that need to grow, because I had some other organisations we request something now but in the future we have to request more and get all these deaggregated blocks, at least that is kind of a mitigation you know if you go back later at least you will grow your current block for a few bits, so at least that ‑‑ that helps them a bit because I had one organisation in the Netherlands, but he was worried about this, he is like we have this plan for future growth but we can't justify it right now and I don't want to end up with a massive address space so in their case they probably don't need to worry so much because they can grow but again this is not something that's in the policy, this is in implementation detail, so maybe to alleviate some of this, oh, God, I can't justify everything right now stress, is to actually make that a bit Morrow figures and tell people like, maybe you can't document it now but we have a reservation for you if you come back in the future. So maybe it would help just to make this implementation detail a bit more formal but I don't know how the NCC feels about that so I don't want to micro‑manage them
ERIK BAIS: We can go from 29 to 28 to 27? What's the gaps.
SANDER STEFFANN: 26, even.
ERIK BAIS: 26. Okay. That would be ‑‑ I think for ‑‑ if we take some ‑‑ a gradual approach, you know, even if you grow into it, that would be very helpful and I think that ‑‑
SANDER STEFFANN: Now we don't guarantee people that they get this and people who used to get a /32 could only go to a /29 because when they got to 32 the three bits are up to 29, but the ones who initially got a 29 will be able to go to a 26 so we do have the risk that the older allocations can't grow and the newer ones can depending on what the initial size was so we have to see how that affects our the LIRs because I don't want to force people like, maybe some LIRs only request 32 and I don't need /29, don't realise if they request 32 but might not be able to grow to ‑‑
ERIK BAIS: For me I thought the 29 was the actual, the growth path from the 32 to a 29 but it did do that for the new 29s, that there were three bits as well. Okay. Did you know?
LEO VEGODA: Can I ask you a question. My question to you is when you are talking about reservations in growth potential, what sort of planning Horizon do you think looks reasonable from the perspective of the network operator and I'd love the RIPE NCC to chip in as well from their perspective because they need to go back to the IANA if they have to get more address space.
SANDER STEFFANN: There is no official planning Horizon and the implementation detail there is a planning Horizon of three bits so somebody can grow up to eight times as large. I am just I don't want to micro‑manage the NCC here, I want to give them some leeway in how they manage the address space but if we can let the people know ‑‑ maybe we need to put this in policy or just inform people better about what the current operational procedure of the RIPE NCC is, I don't know what the ‑‑ where the solution lies yet
ERIK BAIS: There could be that an LIR gets some form of first right of refusal so they can actually make it noticed to the NCC we are intending to grow in the next three to five years so that additional bits are not being consumed. That might be an option which is actually quite low weight or lightweight to do it that way.
SANDER STEFFANN: You mean not a guaranteed something but just an informational hint to the NCC.
ERIK BAIS: Yes they still need to do the documentation part.
SANDER STEFFANN: My personal preference would be to round allocation sizes to nibble boundaries.
ERIK BAIS: We can't always, especially if we are running out, and we also have to go back to IANA and say: I need additional v6. And the question is why? You will need 2000 allocations.
SANDER STEFFANN: Because we gave everybody 16 bits extra.
LEO VEGODA: Just before ‑‑ on that point, one of the things in the global policy, if I remember correctly, and I did used to have to implement it, was that reservations are considered use, but that doesn't mean that we shouldn't manage things responsibly.
ERIK BAIS: Exactly.
MARCO SCHMIDT: RIPE NCC just to confirm that right now indeed for every allocation that we hand out IPv6 we will serve an additional three bits so somebody with a /29 has a reservation up to /26, somebody with a /26 until /23 and so on, there are a few exceptions like /32 got extended to a /29 cannot go further and sometimes IPv6 allocations are being split in half, transferred and of course this is also loss but that's just as a sidenote. The three bits are there since quite long time so this allocation algorithm worked quite well, it's operational decision and indeed we could make this more clear, that it is out there, that people are aware, we do this on a case basis when we, for example, large allocations request, that's a bit ambitious we usually tell them start with /29 and you can go later but maybe we can make it on more general outreach basis. To respond to Leo about IANA, going back to IANA, I am less concerned about that, so still the /12s that we get they last quite long even with this allocation algorithm so I wouldn't worry too much about that part.
ERIK BAIS: Okay, thank you.
AUDIENCE SPEAKER: Tina Morris. Same thing. Nibble boundaries, why not? We are using 3% total globally of what's been assigned and it's ridiculous to get these micro allocations and when you assign just a part of a block, the entire network planning is messed up, internally you can no longer use nibble boundaries and make an organisational plan of your network, which is the whole point of v6, to make it better, easier, implementable, and if we don't do that we are blocking growth into v6 which is so important.
ERIK BAIS: True. Thanks. How we are going online? James, any questions online?
JAMES KENNEDY: No questions. There's a couple of comments. Elvis has confirmed that three bits are actually reserved even for larger blocks, he understand why we are having a discussion. And he will advice is asking to...
ERIK BAIS: So he will advice is requesting the coup.
ELVIS VELEA: I wanted to say [inaudible] allocation, logic to make applications out of /12s from the IANA, which allows any allocation that it makes on top of the three bits that are by default reserved to grow to an as much as possible just because how allocation mechanism is implemented by the NCC.
ERIK BAIS: It's quite hard to understand what you are saying.
JAMES KENNEDY: The line is very unclear. If you can summarise that quickly again.
ELVIS VELEA: [Inaudible] to make IPv6 applicable ‑‑
JAMES KENNEDY: Please type in the Q&A and I can read it out, I think it's a bit easier. Kurt said I would turn it around and define a nibble routing obligation to support v6 routing tables, I hate fragmentation and deaggregation.
ERIK BAIS: So that comes back to the goals of the policy, obviously as we still think that deaggregation is not something that we can fix in policy. We do encourage everybody to use best common practices in that and not start announcing all their 48s, but, you know, if you look at the current v6 routing table, it's 48% is 48s at this point.
SANDER STEFFANN: I might really regret this. Like Tina said and I said it before, nibble boundaries, I would really like that, would there be interest in me writing a draft policy proposal to realign the policies with that so, that would mean changes the /29 to 28 to align it, ask the NCC to reserve four bits to align it with /24s and actually redo the policy that we only do allocations on nibble boundaries or is that ‑‑ is that going too far, do we want something more fine‑grained? Show of hands. Who would like to actually align the policy with nibble boundaries? I only see a couple of hands so not completely sure yet. So, I will discuss it with the Chairs to see if there is support for this.
ERIK BAIS: I definitely support the fact that you are writing it, definitely.
SANDER STEFFANN: Like I said, I am not sure if I am going to regret this. Maybe it's time to be a bit more ambitious than tweaking it ‑‑
ERIK BAIS: Totally agree. And also, during the next video call that we are going to have on v6, we would like to invite you and Gert and Kurt obviously to provide the additional feedback on that. We will also invite people from RS to tell us exactly what their current operations is, where they stumble upon in the current policy and how we can invite them to provide their information before we make any policy changes going forward into RIPE 86 in Rotterdam. And we have the RIPE Chair on the mic.
JAMES KENNEDY: There was one question online. Daniel Karrenberg, Internet geek asks: Why is maintaining a very low number of prefixes is suddenly such a big problem? We manage much more and much bigger number in IPv4?
ERIK BAIS: You mean the fact that the v6 prefixes are a bit longer and if you have ‑‑ if you start announcing every 29 in 48 ‑‑ /48s, you get an explosion in the routing table so that's why aggregation is a topic Raymond: Exactly.
MIRJAM KUEHNE: I think you said what I wanted to respond to Sander, I am happy to see this, enthusiasm, shall I propose a policy proposal and I was going to suggest discusses it on the list that was discussed in the previous session, so that you have some more time to discuss it before it enters the formal policy but I think you just answered that during the interim sessions that you are going to organise.
ERIK BAIS: Yes. Thank you for the feedback and maintaining that we follow the PDP proposal, the PDP process.
All right.
JAMES KENNEDY: We have an extra plus one for the nibble boundaries from Radu ‑‑
ERIK BAIS: Okay. Leo, any other topic on this? Or are we done on v6 for now?
LEO VEGODA: I think we have had a really useful discussion. The one thing I'd like to say is before leaping towards proposing a specific thing of nibble boundaries it would be really good to route it in the policy goals and either positively reaffirm the goals or to go and say no, no, no, we need to adjust the goals in this way, and then we will have clarity and alignment within the community on what the policy proposal needs to be. And that should hopefully make the discussion over the policy a little bit simpler, because we have already worked out together what we want to achieve.
ERIK BAIS: Excellent feedback and thanks for your structured approach on this and you are totally right. We will take it from there. And have the discussion further on the mailing list. And then we will go to the next topic on the agenda, which is going to be temporary assignments, the minimum assignment size. Oh, are we going back to Leo then? There's no slides. That was topic that we discussed in Berlin as well, the temp assignment size. There is a temporary pool where researchers can request v4 space for research, events, stuff like that, and Leo is coming to do a quick chat on that and see if we can get some feedback from the room after that.
LEO VEGODA: Hello again. Okay, so we are talking about temporary IPv6 ‑‑ sorry, temporary IPv4 assignments and the minimum assignment size and this is a really simple question, the question is that the RIPE NCC gets requests for academic and research experiments which often only need a very small number of IPv4 addresses in order to conduct the experiment. The policy that they have says that you justify IPv4 addresses for experiments in basically the same way that you justify IPv4 addresses for anything else, so if you don't need the 128 or more you can't get the /24. So, do we need a minimum size for temporary IPv4 assignments? And, if so, should that apply only to academic research assignments or does it need to be a more general thing, because if you need an assignment and you need to use it then, at the moment, you need a /24. So, as I'm not in the room I'm not going to point out people in the room and say oh, yes, you can speak, but that is essentially the question there.
ERIK BAIS: I will do that.
LEO VEGODA: That is the problem that we face, and it would be great to hear what people have to say on that.
JAMES KENNEDY: We have a comment online from.
ELVIS VELEA: Minimum /24 should be allocated for temporary assignment, unusable otherwise.
ERIK BAIS: I tend to agree on that as well. I see a raised hand in the room. Any other thoughts? Do we need to minimise this to research or is it more general use? My personal feeling would be not specific research but ‑‑ because you know, for the v4 assignment policy, there is the minimum allocation and assignment for a /24 anyway so I think this should align there as well. And then the next question is, we are going to take this back to the mailing list and if there is some additional comment there and we have somebody on the mic.
AUDIENCE SPEAKER: I work at Serve, actually we are really happy RIPE NCC provides temporary assignments, we use it for events, we are really happy with that. But one practical thing we encounter is the geoIP, it's not governed by any authority, it's like scattered, there should be maybe some authority on that but that's out of scope for this meeting. But a short term solution for this could be that we actually keep /24s or small assignments, reserve them inside for use for specific countries, so, that the IP databases will keep the same and we don't encounter issues, like, for example, services that limits their services for specific countries.
ERIK BAIS: Yeah, so geolocation is going to be an issue with whether you talk about leasing or if you talk about temp assignments. There might be an option there where the NCC can provide a geofeed. There is some options to feed those specifically for the temp assignments into all the IP databases that are doing geolocation. That is definitely an option, otherwise you'll need to extend the time that you actually have the space in use because, you know, it typically takes about six to eight weeks before most databases are actually updated with gee location. You can speed that up if you do that yourself and you are willing to do the legwork. But that is how it is. So definitely good input on that.
JAMES KENNEDY: Question ‑‑
ERIK BAIS: Marco, go ahead.
MARCO SCHMIDT: RIPE NCC. I just want to say that we are really happy to see there's a general support for that to here to make a minimum assignment size and to bring it back to the mailing list and we really would appreciate if somebody takes the lead and make a proposal and we have Angela in the room and she also can help on that, to help with all the formalities because we brought it up, it is for us, like a pain point, everybody says it should be changed and how can we make it work so yeah, just at this moment thank you for the general sense that it should be changed and we are happy to help any actual policy proposal.
ERIK BAIS: For us as chairs it helps if there is somebody who is actually using it, might actually help in the policy proposal so I will have a discussion with you on that and see if we can pinpoint a volunteer with you.
JAMES KENNEDY: We have a very good question from Kurt Kaiser, he asks: Is there the same usability guaranteed after getting it back? For example, that is spam lists, blacklists, etc., I have seen pretty ‑‑ I have seen pretty unusable space come back which is a lot of work. So maybe it's a question towards the NCC about due diligence to ensure that the space is cleaned up correctly before being reissued.
MARCO SCHMIDT: At this moment we don't really have a perfect clean‑up. We do pick address space randomly and we allow a certain ‑ time but we don't really let's say look how ‑‑ [[inaudible]] maybe I can contact Kurt if he has some negative experience to find out what ‑‑
ERIK BAIS: Thank you.
JAMES KENNEDY: Elvis online has put his hand up: I will pick up the temporary assignment policy proposal. And we also have an extra comment from Radu, from France internet exchange: How about we start to phase out the temporary allocation stuff and start to gradually reduce the temporary pool towards zero? The message should be v4 is over, do your stuff over IPv6, no?
ERIK BAIS: Thanks for the comments. Anybody else in the room?
Then there is the AOB open mic, anything, Sander?
SANDER STEFFANN: You think I almost ran this Working Group.
ERIK BAIS: Well, you have some experience in this.
SANDER STEFFANN: Only eleven‑and‑a‑half years. Gert still won. I miss him, by the way, I am sad he is not on side. Gert, if you are online, we miss you. Anyway, there was a message on one of the RIPE mailing lists about Ukraine by Hans Petter Holen, the CEO of the RIPE NCC and this was about protecting the Ukrainians because sometimes with invasion, they are being forced to transfer their addresses to companies that are friendly with invaders, sometimes at gunpoint or their family is at gunpoint, so, we already talked about this in Berlin, but it's still going on, there are still no solution there. And one of the things I noticed was that Hans Petter in his reply to the Ukrainians said take this up in address policy. My personal feeling was that protecting its members' resources is not a policy, that's not something that the NCC should do but Hans Petter said he thought he needed a policy from this Working Group to be able to do anything. My personal feeling is that he doesn't, but how does the rest of the Working Group feel about this?
ERIK BAIS: Yeah. So, before we actually go to the room, and I see Hans Petter standing up as well, we, as Chairs, have discussed this also during the Chair meeting last week. From ‑‑ and if you look at this from a point of war, this is not unique to Ukraine, so whatever comes into play here, needs to also apply for other war zones that we already have in the RIPE region so it is ‑‑ it should apply to Syria, it should also apply to Palestinia so there are different countries that have issues with this. And it should basically be conformed for everybody. There has been suggestions where people get an option in the LIR Portal to shoot themselves in the foot if they want to and basically lock transfers in their LIR or lock them as their resources. That has some options to discuss. Doing a country‑specific transfer lock is not something that I would envision but if you look at this from a point where you look at art, and art is stolen during war, what typically happens is, the previous owner or the heirs, they go to a court case, they report it as an act of war and actually get it ‑‑ something from a court case in a designated country and that, in my opinion, should be the way to go here. We should actually have a look at the appeal process and not at the ‑‑ not at policy. And having said that, I'll be more than willing to, if you can leave the mic for Hans Petter and have him answer to the room.
JAMES KENNEDY: Shall we hear from this gentleman first?
AUDIENCE SPEAKER: Maxim ‑‑ Ukrainian Internet registry. I totally agree it's not a policy proposal, it's not we are the policy change, I agree that good idea to have bigger button so if you push it, the transfer will be locked for some period of time, for example, half of year. I think it's the best. I think country‑specific lock is not an option at all. Also, I should point you that, now, in Ukraine, we have very bad situation inside, we have some corrupted government people that thinks to let something like government agreement for transfer for (inaudible) ‑‑ of course. I think that should not be done. So no country‑specific for me, no policy change, just bigger button will do the work. Thank you.
ERIK BAIS: Yes. So, one of the risks that we see if we ‑‑ if people start locking their own transfers, and I hate to make this ‑ here, if a director of a company at gunpoint or his family at gunpoint is being threatened, I think the best thing to do is sign the freaking document and get the transfer done and actually take an appeal, because that is the safest option for everybody involved. As soon as guns are there, this is, you know, get it out of the way.
Locking transfers and making sure that, within the system, and the policies that we think we have, that somebody with a gun will say, either you sign this or you remove the lock and things like that, it will only put the family in harm's way. So the safest option is to do the transfer and then go to a court and actually do an appeal in the court. However, that's my opinion.
AUDIENCE SPEAKER: The problem with at first we have some statistics like situation that already done on occupied territory, not with ‑‑ I personally don't know any case of this hijack of IP addresses. So, maybe somebody knows. But for physical object we know that people actually was killed after their transfer. So, they take the car and kill after that. So it will not help, just to make a transfer. But, we will open bigger can of worms, it means reverse transfers. I think there should be no reversed transfers at all. But (inaudible) can do the transfer and after that go to the court and get the papers that there was some maybe force majeure or something like this and there was ‑‑ know that their whole ‑‑ whole ‑‑ so they want to do whatever transfer before the transfer so it's like some ‑‑
ERIK BAIS: Like I said, you know, the process in here is quite similar on art, for instance. So, how that, how that looks into, in reality, that's what we need to see. I would like to give the mic to Hans Petter first, Sander.
SANDER STEFFANN: I want to mention it sounds like we are doing NCC services here because this is not about policy.
ERIK BAIS: No, no, it is. So in the whole process, there is going to be a topic this afternoon by Athina with a couple of slides in NCC services.
AUDIENCE SPEAKER: Hello, I am the director and co‑founder of Web ProK we are the telecommunication company internet provider of critical infrastructure and business in Ukraine. We continue working in Ukraine and of course we have LIRs who only sell and buy IP addresses and do we have LIRs who use it every day and give services. Of course, in when the war started in Ukraine, business who continue work in Ukraine, we afraid that somebody with guns stay near our head and in this case of course we don't think about some IP address, of course we do everything to save family, to save our lives. And staying here and continue working in Ukraine, not abroad, living in Ukraine and stay and continue working, of course we are afraid for our business and afraid to our resources, because it is a cybersecurity, this is ‑‑ this is not small money, which we can save because our infrastructure destroyed every day and we don't think about our future, we don't think how money from sale in IP addresses, we think how to survive in this time. That's why, today, in our Ukrainian community chat, we have, for example, discussion from, not from occupied territories, and he stay in the territory today not occupied but in the documents it is a part of Russia, and he afraid and he, today, ask Max could you tell me how, for example, government can sold my IP addresses? It is not possible because we have RIPE policy, we agree this policy and we don't want that some government organisation have influence for this policy. It is our position and we agree with policy of RIPE. It is very important. And in all countries corruption is present, even in European Union, and we fight with this, of course, and we don't want to have some influence from government, because business, it's a business, private is private, and government, it is a government. We have very good dialogues with our government, with different ‑‑ business have influence to other government because we have a lot of work groups. And we discuss all those which they want to improve. And in this case, I must mention max, he don't know any stories about stolen IP addresses, asks, I want to mention situation with T Com, had a lot of IP addresses which today stolen registrated in Russian territory. It is a real history. And now we can discuss changes in policy, everything, and I want just now say thank you very much, RIPE, and NCC, for dialogue, because for us it is very important that you can hear us and the possibility that I can stay here, because within that Ukrainian community is that community that stay and continue working in Ukraine. It is more important that only have some IP addresses and have business in this. That's why of course we want to discuss and we want to frozen all these transfers to that period when find some way how can you protect us, because we are the part of your family, we stay here and ask, maybe you have some ways how can you protect us, please protect us because we are your family. Thank you very much.
(Applause)
HANS PETTER HOLEN: Managing director of the RIPE NCC. So first I want to say thank you for my Ukrainian friends for coming here and sharing your thoughts on this, my heart is with you and what is happening is really terrible, so let's that be clear.
The RIPE NCC operates under a transfer policy. My colleague Athina our chief legal officer will present in the Services Working Group of analysis of different solutions that has been published so far and Labs article on that, the legal analysis tells us we might need a policy change or not. We are more than willing to discuss this with the community and hear input and we need input on how to do this and listening very carefully to everything that's being said in this Working Group and the next Working Group and then we will have to review this afterwards and see what next steps we can take and I assure you that no matter how we are going to do forward on this, the board is also very supporting in taking action in a timely manner so we don't led this drag out so if it needs a policy proposal we may suggest to the Executive Board that they could do temporary freeze in the meantime. So, don't let the policy process path be prohibitive because of the timing so ‑‑ just want to say that. There will be a detailed analysis in the next Working Group and then let's look at it from that.
ERIK BAIS: Thank you for that.
AUDIENCE SPEAKER: I am provider and guy from occupied territories in Ukraine. And I have a short remark. I think it will be good for just physical security to make kind of log for transfers and make it like to know everyone that it's physically impossible and legally impossible so guy with weapon should know that it's impossible and it's like no reason for him to threat somebody if he knows it's like impossible. So you can still ‑‑ it's physically can be done so. I think for security reason for people it will be good idea just to log everything.
ERIK BAIS: Okay.
AUDIENCE SPEAKER: Maybe like max says, it should be if person want to log it he can choose to log it for some time, year or two years and it will be undone and can't be done in ‑‑ I think it will be like good idea.
ERIK BAIS: Okay. We will take this back also after the discussion with services. There's definitely some legal implication at that point, but we will take the discussion back to the Working Group as well.
JAMES KENNEDY: One question online in the Q&A from.
ELVIS VELEA: Hi, Hans pert, I do not see how policy can help here. Can you please guide us on what kind of policy would the NCC need to see, to help the Ukrainian LIRs. (Hans Petter).
HANS PETTER HOLEN: Comes to the Services Working Group and listen to the analysis. We have a policy instructing us to do transfers under certain conditions. Now you are telling us not to do some of those transfers, so if we don't that may be a violation of the policy and normally, the community do not like if I violate policy, you hold me true to the letter in the policy so that may be the distinction but listen to Athina's analysis of that rather than mine
ERIK BAIS: I think it's interpretation of the policy and how the transfer log would be implemented but it's something we will see after services. All right. So I think we are almost out of time. Definitely. We have two minutes, so Rudiger we are going to keep it very short.
RUEDIGER VOLK: I wonder whether the status field in the delegated extended file as it is defined and operated by the RIPE NCC is something that should get some attention in the ‑‑ in address policy Working Group. I noted on Monday evening that ISOC was reporting about some confusion using the data and kind of, as far as I can tell, there is not really a very clear documentation and, well, okay certainly little attention to what's being done in that file, couple of years ago I think everybody was thinking yes, that's statistics that are RIRs are putting out somewhere and it doesn't have kind of real meaning at the time of the Dubai RIPE meeting policy changes in RPKI by the RIRs actually provided arguments that the delegated extended file actually has ‑‑ has to be taken serious, the RIPE meeting I had to report about operational problems with a file and, well, okay, quite obviously at least ISOC people, who should be knowledgeable, get confused about the status field and I think ‑‑ I think there is a possibility that whatever which RIR is documenting in that field is probably something that should be viewed with a policy ‑‑ with ‑‑ as a policy point of view.
ERIK BAIS: Thank you very much for your feedback. Definitely, need to have that discussion on the mailing list, Rudiger, so we need to have some more background info on that. Then, with that being said, I would like to thank everybody here on the ‑‑ I would like to thank everybody present here on the Working Group session and we will all see you on the mailing list at Rotterdam RIPE 86. Thank you very much.
