- address-policy-wg - mailman.ripe.net

IPv6 Stockpiling
by Marco Schmidt 04 Nov '21

04 Nov '21

Dear colleagues, During RIPE 82, we provided you with an update on our observation of IPv6 stockpiling [1]. Based on the feedback we received and in preparation for the coming RIPE meeting, we would like to give you another update on that issue. According to the IPv6 Address Allocation and Assignment Policy, an LIR can receive up to a /29 IPv6 allocation without needing to supply any additional information. The RIPE community considered this size sufficient for most organisations for long-term IPv6 deployment. Additionally, LIRs may qualify allocations greater than /29 by submitting documentation that reasonably justifies this request [2]. However, over the past few years we have noticed that some organisations are collecting multiple IPv6 allocations in ways that are permitted by current RIPE policies but might conflict with the above-mentioned intent of the IPv6 policy. For example, it is possible for a single RIPE NCC member to receive a /29 allocation for each of the multiple LIR accounts that it holds. This is the result of a policy change in 2018 [3]. LIRs can also receive multiple IPv6 allocations via policy transfers without needing any further justification. However, when the IPv6 transfer policy was discussed in 2014, it was assumed that there wouldn't be an active transfer market [4]. We have gathered data showing the significant development of the collection of IPv6: - Almost 700 IPv6 allocations have been transferred in 2021 so far (and there have been more than 3,900 transfers since policy implementation in 2015) - About 60% all IPv6 allocations ever handed out by the RIPE NCC are now held as multiple allocations - In the last three months, more than 75% of all new allocations were given to members that already hold at least one IPv6 allocation - More than 1,500 members hold multiple IPv6 allocations, exceeding the size /29 - Almost 100 members hold more than 10 IPv6 allocations (the maximum is 102 IPv6 allocations held by one member) It is the RIPE NCC’s understanding that some of these situations are within the intent of previous policy changes, for example, to avoid renumbering of deployed IPv6 networks during holdership changes, or if a large company has multiple network departments that prefer to manage their own allocation. However, the huge volume indicates that most are for other reasons. While members can collect multiple IPv6 allocations without evaluation by the RIPE NCC, we still were able to gather some feedback how members plan to use their allocations. Many members simply stockpile them for an undefined future use, others plan to use them for activities which temporarily require a vast amount of IPs, and some plan to offer IPv6 on a large scale to other ISPs in their country. We believe that this situation could create several issues: - IPv6 might be deployed in conflict with RIPE policies, underlying RFCs and other best practices, resulting in challenges to that IPv6 deployment once the policy violation is discovered during an audit - There could be a negative impact on the quality of the registry if large parts of allocations were given to third parties without clear registration requirements - The policy requirement to justify larger IPv6 allocations would then be rendered useless If you agree that this is a problem, we would like to initiate a discussion in this Working Group about possible solutions. We see at least two potential paths forward. Firstly, if the Working Group believes that this trend is an indication of a widespread need for IPv6 address space larger than /29, then the requirement for justification could perhaps be adjusted for a larger allocation size. Members could then more easily get the address space they need, but as an aggregated block. Stockpiling would still be possible under this potential policy change, in fact on an even bigger scale. Secondly, if the Working Group believes that this trend is in conflict with the original intent of the IPv6 policy, adjustments to the policy can be proposed that give the RIPE NCC a stronger mandate to enforce it. One challenge here would be defining what IPv6 usages are considered within or outside of the intent of the policy and how to ensure better oversight without too much impact on IPv6 deployment. There might be other options that this working group can consider and discuss. If required, the RIPE NCC can provide additional information for this discussion. Kind regards, Marco Schmidt Registry Services Assistant Manager RIPE NCC [1] https://ripe82.ripe.net/presentations/7-RIPE82-Feeback-from-RS.pdf from slide 9 [2] https://www.ripe.net/publications/docs/ripe-738#initial_allocation [3] https://www.ripe.net/participate/policies/proposals/2018-01 [4] https://www.ripe.net/participate/policies/proposals/2014-12

8 9

RIPE 82 Minutes
by Leo Vegoda 14 Jun '21

14 Jun '21

Dear WG, The RIPE NCC has now published draft minutes of our session at RIPE 82. The page also links to the stenography transcripts and chat logs. Please inform the co-chairs of any issues or corrections. https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-82-addre… Kind regards, Leo Vegoda for the Address Policy WG co-chairs

1 0

Mass deletion of assignments from RIPE Database?
by denis walker 18 May '21

18 May '21

Colleagues [Apologies for the long email, but I feel the video is an oversimplification of the issues involved.] I have watched the video from the AP-WG agenda for RIPE 82 by the RIPE Database Task Force (TF). As a netizen, rather than in any other capacity, I am totally opposed to this recommendation which would allow the removal of all IPv4 assignments from the public registry of IP addresses. I would like to present some opposing arguments before the discussion tomorrow in the AP session at RIPE 82. In the video there are 4 justifications given. None of these can actually be considered as a justification for this recommended policy change. 1/ some allocations have no registered assignments This should be followed up by the RIPE NCC with ARCs. If the current policy has not been followed, then assignment objects should be created. If a few resource holders don't follow the policy, that is not a justification for changing the policy. Encouragement to follow, or enforcement of, the policy is the answer to this. 2/ Small (/24) allocations require even smaller (/25) assignments There is an action point in the DB-WG (NWI-4) to allow multiple status values in INETNUM allocation objects which would address this issue without policy change. 3/ data minimisation, less data to maintain = more accurate [implying that having no data gives 0% error] Googling for 'data minimisation' it is hard to find any definition that doesn't relate to personal data. This is the best fit I found: "The principle of data minimization involves limiting data collection to only what is required to fulfill a specific purpose." If there is a valid purpose for assignment data then this isn't 'data minimisation', it is 'data loss' resulting in reduced functionality. So the historical, present and future use of assignment data is the real question to consider. 4/ justify additional allocations This was 'one of' the historical reasons for creating assignments in the DB. Since run out this reason no longer applies. But that does not mean there are no other reasons for having assignment data in the DB. In the video the TF suggest that 'now' this reason no longer applies, perhaps we can drop this policy requirement. As ripe-733 (assignment policy) no longer even mentions this as a reason for creating assignments in the RIPE Database, I don't see the connection between this long since discarded reason and changing the policy now. The video ignores any other reasoning for the existence of assignments in the DB. The suggestion in the video was that creating (PA) assignments would be optional. It also said "Partitions and sub-allocations 'should' be registered. It is important to note that in policy speak, 'should' is not the same as 'must'. This makes everything more specific to (PA) allocations optional. What are the likely consequences to this change? Many operators maintain internal software to align their internal address management with the RIPE Database. This involves a lot of time, effort and money to keep the RIPE Database up to date. They are also open to criticism if anyone finds a single email in the DB that is invalid. It also exposes their publicly identified customers to being directly accountable for their use of address space assigned to them. While most end users probably don't have an issue with that, internet abuse originates from somewhere. Those networks probably prefer to be hidden out of view. By making all this data optional, resource holders can simply delete all this data from the RIPE Database. They can archive the software used to align their internal systems with the RIPE Database. They can shield their customers behind the court order firewall from any exposure to questioning of their usage of their assigned address space. The resource holder can hide themselves behind a contract putting responsibility of usage of address space on their (now) hidden customers. Without a court order this all becomes private, hidden data. It is easy to see benefits to resource holders and operators for this change, but does it have a negative impact on other RIPE Database data consumers? I suspect making this policy change could/would result in a mass deletion of (PA) assignment data from the RIPE Database leaving only the allocations made by the RIPE NCC. In this scenario what happens with abuse reporting? All reports would have to be sent to the LIR holding the allocation resource. They could put a simple mail forwarder on that email address and forward all reports to the appropriate (hidden) customers. If anyone questions a report sent, the answer could be "I forwarded it on to the user. If they haven't replied to you, get a court order to reveal the customer details and take it up with them directly." What happens with blocking & blacklisting addresses? Unless it is possible to determine assignment sizes from other data (routing perhaps?) then the only option is to block or blacklist the whole allocation. There are no aggregated objects with assignment sizes like with IPv6. Removing assignment objects also impacts the use of the RIPE Database as a contact DB for network operators. Resource holders will have to weigh up if the need for more specific network contacts was important enough to justify them maintaining all their assignment data in the RIPE Database. For larger resource holders, given the savings to them by ditching this data, they may well choose to sacrifice network contacts. In the video the TF talks about the 'freedom' of LIRs to choose if they want to enter assignment data or not. Their freedom is someone else's denial. They also talk about a smaller, common, useful database. This smaller, common database is not very useful to anyone who uses the assignment data that is discarded to make it smaller. Looking at it from the perspective of accountability, openness and abuse issues, deleting 94% of the IPv4 registry data from this public registry and turning all this information into private data requiring individual court orders to access each bit of what was public data, I believe would be a huge backwards step. Even if the reality turned out to be half the assignments being deleted, is a partial data set, with less eyes focussed on the reliability and accuracy of the data, of any use to anyone? In recent years the use of the DB by LEAs, abuse handlers and researchers has been hotly debated and contested. If you look at recent policy discussions and DB functionality issues, two phrases come up time and time again. "It's not the purpose of the RIPE Database to do 'abc'." "It's not the function of the RIPE NCC to do 'xyz'." So many engineers and operators seem to have difficulty accepting that the purpose of the RIPE Database has evolved over time and is now more than an engineer's and operator's tool. In today's society the internet is not only an essential part of every day life, it is also a dangerous place. The DB has become an essential tool for LEAs and companies & organisations that try to address internet abuse. That is despite many engineers and operators constantly dismissing this as not a (historical) purpose of the RIPE Database. The same argument is used against researchers. Use as a research tool was not on the original list of purposes of the DB. The whole umbrella of research is an essential part of moving forward with technology. It is time to stop the endless arguments about the purpose of the RIPE Database and accept that use by LEAs, abuse handlers and researchers is now part of the fabric of the RIPE Database. Whilst the TF acknowledges this friction in their draft requirements document, there are no recommendations to resolve this issue. I would like to see the TF address this and recognise these as valid purposes of the RIPE Database. I hope recommendations will be included in a future draft of the TF's requirements document that recognises these new and important purposes of the RIPE Database by an expanding and diversifying set of data consumers. Moving forward on address policy with these newly accepted purposes of the DB, the IPv4 assignments take on a more important role. In this context I do not believe assignments should be made optional, and almost certainly deleted to become hidden, private data, behind a court order firewall. cheers denis long standing, but forward looking, netizen Question to the RIPE NCC... Can you select a random week day and calculate the total number of queries where the query string is an IPv4 address. If possible can you determine if the query string address is contained within a PA assignment object and calculate the percentage of these queries that would have returned an assignment object. If this recommendation is accepted, these queries in future would most likely only return the resource allocation object.

2 1

New on RIPE Labs: SCION - A Novel Internet Architecture
by Alun Davies 17 May '21

17 May '21

Dear colleagues, At RIPE 81, a group of enthusiastic researchers and practitioners from industry and academia discussed with the RIPE community what role RIRs and LIRs could take on in the SCION next-generation Internet architecture. Ahead of the SCION BoF taking place today at RIPE 82, David Hausheer looks back at what happened at the last BoF, reports on what has happened since then, and presents what potential RIPE involvement could look like in the future. Read more on RIPE Labs: https://labs.ripe.net/author/hausheer/scion-a-novel-internet-architecture/ Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

recorded RIPE NCC presentations are now online
by Gert Doering 14 May '21

14 May '21

Dear AP WG, as Erik already announced, this meeting is different :-) - in the last meeting, we noticed that Meetecho is actually quite good in enabling a "real" discussion - but we had no time. So, this time, the "we want to discuss this!" topics are online as a pre-recording, as of right now for the NCC PO/RS talks (Marco and Angela). Because I'm already enjoying my soon-to-be WG chair retirement, I'm just being lazy and forward Marco's Mail with the links and with the reminder: to have an informed discussion, you are expected to watch these before the actual meeting on Tuesday (or at least look at the Slides). We will *not* use our WG time to play back videos - we'll do Q&A, and then discussion, on the questions raised by these talks. See you next week (virtually...) Gert Doering creaky APWG chair ----- Forwarded message from Marco Schmidt <mschmidt(a)ripe.net> ----- From: Marco Schmidt <mschmidt(a)ripe.net> Hello Erik, Gert, James and Leo, The pre-recorded presentations from Angela and me are now online and published as part of the APWG agenda https://ripe82.ripe.net/programme/meeting-plan/ap-wg/ With the direct links https://ripe82.ripe.net/wp-content/uploads/presentations/ripe-82-policy-dev… https://ripe82.ripe.net/wp-content/uploads/presentations/ripe-82-feedback-r… Please feel free to inform that WG members to watch these presentations before the session. I see the risk that some people will not expect that they need to watch the presentation upfront. So as earlier they know about it, the more this risk is minimized. Have a nice weekend and see you next week! Regards, Marco Schmidt ----- End forwarded message ----- -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

WG chair rotation 2021
by Gert Doering 10 May '21

10 May '21

Dear AP WG, according to our WG Chair Selection process, one of the WG chairs has to step down every two years, and a new WG chair is selected by the WG. This time, it is my time to step down, and I will not(!) run again - I've been one of your chairmen for a long time, and I think it's time for a change. Do not despair :-) - as you are aware, we brought in two "trainee chairs" at the last meeting, Leo Vegoda and James Kennedy. Both have used the time to look "behind the curtains" and see what they will be getting themselves into, and last I heard, were willing to take the job. That said: it is your decision, as WG, not our decision as WG chair team. So other interested volunteers are free to make their interest known, and then the WG will decide. Please make your interest known to the remaining chair (Erik Bais) erik(a)bais.name and please include a short bio and your reason for applying. Erik will collect applications and publish them collectively on March 31st. Gert Doering -- creaky chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

10 12

Stockpiling IPv6 Update
by Marco Schmidt 28 Apr '21

28 Apr '21

Dear Address Policy Working Group, During the last Address Policy WG session in October 2020, we provided an update on the topic of stockpiling IPv6 allocations. For the upcoming RIPE 82 meeting, we want to share some additional information to support the community discussion. To summarise, the RIPE NCC observed a significant amount of members requesting several IPv6 allocations via multiple LIR accounts or the transfer policy. Based on the IPv6 policy, it is possible to request up to a /29 IPv6 allocation per LIR account, without any justification needed. Firstly, we want to stress again that this is not about any potential scarcity of IPv6. Rather we would like to ask the Working Group if the current development is within the intend of the IPv6 policy. Currently, we see around 100 members that have collected multiple IPv6 allocations with totaling amounts of /26 or more, with the maximum of 91 IPv6 allocations (totals /23+). To put this in perspective, in the last ten years, only 12 members could document the need for initial allocations of a /26 or more, with a decreasing trend in the last years while at the same time, more multiple smaller IPv6 allocations are being requested. We see a big discrepancy between organisations being able to justify larger IPv6 allocation based on actual network plans (despite eased policy requirements) and organisations that collect many /29 allocations without any real requirement of justification. We also noticed that some of the members rent out large blocks of their multiple allocations to other ISPs. While the IPv6 policy supports this approach, we would like to raise awareness that this creates a strong dependency of the ISP to their LIR, especially if large IPv6 networks are being deployed. In case the members decide to change their business model or terminate the membership, the sub-ordinated ISPs will be forced to renumber whole IPv6 networks or follow any requirement set by the LIR. We hope that this information will help the Working Group to review if the current development is in line with the intent of the IPv6 policy. Kind regards, Marco Schmidt Assistant Manager Registry Services and Policy Development RIPE NCC

1 0

Draft agenda AP-WG RIPE82 - virtual AP-WG
by Erik Bais 26 Apr '21

26 Apr '21

Dear working group, In the approaching time to the RIPE82 meeting there will be a couple things that are going to change. First as you may be aware, the AP-WG session is going to be on the TUESDAY instead of the Wednesday. This is due to the preference of people to not have WG sessions in parallel. So the AP-WG session is moved to the Tuesday May 18th 10:30 am Amsterdam time (CEST - UTC+2) Second this is going to be last WG session with our faithful Gert as co-Chair of the WG, as he is going to step down. And because he started RIPE 44 in Amsterdam, 2003 as chair for the LIR-WG (now AP-WG), he is probably one of the longest serving Chairs in our community. So, on the agenda, we have the following planned. We will be publishing a couple presentations in pre-recording, so that we can have more time for discussions. The publication of those pre-recordings is planned for the weekend before the WG session. The session is in the meeting schedule for 90 minutes .. but we plan to do a short break in approx. the middle.. to allow for some fresh coffee / short toilet break. So we have a pretty full agenda .. and we expect the session to allow for more time for discussion on various topics with this format, along with the information of the NCC about various topics. --- Draft agenda AP-WG session - RIPE82 A. Administrative Matters - Gert Döring Welcome, thanking the scribe, approving the minutes, etc. B. WG Chair selection / appointment - Erik Bais C. Current Policy Topics (Q&A based on pre-published slides/recording) Angela Dall'Ara, PDO, RIPE NCC - Global policy overview "What's going on?" - Common policy topics in all regions (end of IPv4, transfers, ...) - Brief overview of new proposals (if any) D. Feedback from the RIPE NCC Registry Services (Q&A based on pre-published slides/recording) Marco Schmidt, Registration Services [5 minutes break to top-up the hot drink of your choice] E. Introduction of candidates for the NRO NC Ulka Athale F. (Tentative) Agenda item arising from the DBTF James Kennedy or another DBTF member G. What colour is my IP(v4) space? PI addresses and LIRs Remco van Mook h. Systematic Review of RIPE Address Policy (Discussion) - Proposal to review whether environmental changes since a policy were agreed should be addressed with a policy update Z. AOB Hope to see you all on RIPE82. Regards, Gert Döring & Erik Bais, AP-WG chairs

2 1

RIPE DBTF Feedback
by Bijal Sanghani 14 Apr '21

14 Apr '21

Dear colleagues, I am writing to inform you that the RIPE Database Requirements Task Force (DBTF), is soliciting feedback on our recommendations for; Person Objects Historical Data Legal Address If you are interested or have any feedback on these topics, then please join the conversation on the RIPE Database WG mailing list so that we can keep all feedback and discussions in one place. Kind regards, Bijal on behalf of the DBTF

1 0

Request about homologation of policy documents
by Kurt Kayser 13 Apr '21

13 Apr '21

Dear RIPE friends, I have scanned the current address policy documents and I have some questions about homologation between a couple of topics. There are 2 main areas of concern, which I would like to discuss: 1. Validity of RIPE-451 - (IPv6 address space policy for IXPs.) aged well since 2009. Option 1: drop this document entirely - the pointer for the document "Obtaining the address space" (RIPE-575) is anyway outdated/obsoleted. Option 2: Integrate a relevant paragraph in the RIPE-738 (IPv6 address allocation and assignment policy) successor document? For comparison: RIPE-733 (IPv4 address ---) this area is mentioned in Section 6.1 - mainly due to minimal resources left to use. 2. Comparing Sections 6.x from RIPE-733 (IPv4 adresses allocation and assignment policy) with RIPE-738 (IPv6 address allocation and assignment policy) There are very nice paragraphs in Section 6.2 (network infrastructure) and 6.3 (validity of an assignment) which I miss as counterpart in RIPE-738. One would assume that there should somewhat similar approaches on how to assign and document used address space. There are also other areas that could be cleaned up (such as transfers - completely moved out of these documents or extended?) Suggestion: why not keep the same section numbering for identical topics? Best regards, Kurt Kayser

2 1

RIPE Database requirements progress
by ripedenis＠yahoo.co.uk 08 Apr '21

08 Apr '21

Colleagues For the benefit of those who don't often check the mail archives of the RIPE Database Task Force there have been 4 meetings in February and March and the TF has just published the minutes of their most recent meeting on their mail archive which can be found here:https://www.ripe.net/ripe/mail/archives/ripe-db-requirements-tf/ Their latest draft requirements document can be found here:https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-… There are quite a number of recommendations made regarding registration of address space in the RIPE Database. In their latest meeting minutes they also mention creation of assignment objects in the database (but this is not yet in their draft document). It would be helpful if more people would read this document (and meeting minutes) and comment or discuss publicly on this WG mailing list any issues regarding the TF draft document before they publish their final version of the requirements. They also plan to hold a BOF sometime in May where you can make comments. cheersdenis co-chair DB-WG

1 0

Internet access via different countries
by Fernando Cuartero 18 Feb '21

18 Feb '21

Hi, I am unsure if it is possible for UEs to exit to internet via different countries, Netherlands (DCP2) and Sweden (DCP1), using the same public IPv4/IPv6 address or if each country should have different public IPv4/IPv6 pools. Is there any regulation about that? [cid:image001.png@01D7062B.65C7C3F0] BR, Fernando

2 1

IPv4 Request
by Sales 12 Feb '21

12 Feb '21

Greetings, We're looking to lease a large quantity of IPv4 addresses, long term for our global web hosting business (est 2004). We're looking for easily /16 or larger block, even /14 if available. We can take multiple mixed sized subnets too, that's fine. We require ability to update whois, route objects, DNS and provide LOA for global provisioning. We're members with ARIN and RIPE. ARIN MNT: LOGIC-25 RIPE MNT: LOGICWEB PUBLIC ASN: 64286 We can sign a 1+ year agreement paid 1st of each month. We're willing to do even 3 or 5 years. Please let us know your subnets available and pricing.

4 3

Live e-lecture by Prof. Efstratios Gavves: ‘The Machine Learning of Time: Past and Future’, 9th February 2021 17:00-18:00 CET. Upcoming AIDA AI excellence lectures
by Ioanna Koroni 08 Feb '21

08 Feb '21

Dear AI scientist/engineer/student/enthusiast, Prof. Efstratios Gavves (University of Amsterdam, Netherlands), a prominent young AI researcher internationally, will deliver the e-lecture: ‘The Machine Learning of Time: Past and Future’, on Tuesday 9th February 2021 17:00-18:00 CET (8:00-9:00 am PST), (12:00 am-1:00am CST), see details in: <http://www.i-aida.org/ai-lectures/> http://www.i-aida.org/ai-lectures/ You can join for free using the zoom link: https://authgr.zoom.us/j/93863728654 The <http://www.i-aida.org/> International AI Doctoral Academy (AIDA), a joint initiative of the European R&D projects <https://ai4media.eu/> AI4Media and <https://www.vision4ai.eu/> Vision and Humane AI Net currently in the process of formation, is very pleased to offer you top quality scientific lectures on several current hot AI topics, starting with the above mentioned e-lecture. Lectures will be offered alternatingly by: Top highly-cited senior AI scientists internationally or Young AI scientists with promise of excellence (AI sprint lectures) Lectures will be typically held once per week, Tuesdays 17:00-18:00 CET (8:00-9:00 am PST), (12:00 am-1:00am CST). Attendance is free. Other upcoming lectures: 1. Prof. Pietro Perona, ‘Measuring algorithmic bias in face analysis — towards an experimental approach’, 23rd February 2021 17:00 – 18:00 CET. 2. Prof. Björn Schuller: ‘There will be Artificial Emotional Intelligence’, 9th March 2021 17:00 – 18:00 CET 3. Prof. Andreas Geiger, ‘Towards Robust End-to-End Driving’, 23rd March 2021 17:00 – 18:00 CET More lecture infos in: <http://www.i-aida.org/future-lectures/> http://www.i-aida.org/future-lectures/ These lectures are disseminated through multiple channels and email lists (we apologize if you received it through various channels). If you want to stay informed on future lectures, you can register in the <https://lists.auth.gr/sympa/info/cvml> CVML email list. Best regards Profs. I. Pitas, N. Sebe, B. O’Sullivan, M. Chetouani AIDA AI Excellence lecture series committee -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

CfP for EUSIPCO 2021 Special Session "Image and video analysis for autonomous drones" (Deadline February 12, 2021)
by Ioanna Koroni 05 Feb '21

05 Feb '21

Dear drone imaging scientists and engineers, you are invited to submit an original, unpublished technical paper to the Special Session "Image and video analysis for autonomous drones" of EUSIPCO 2021: https://eusipco2021.org/. Conference submission deadline is February 12, 2021. Autonomous Unmanned Aerial Vehicles (UAVs, or drones) are becoming more and more important to many industries, promising simplified logistics, cost reductions, increased safety for humans, quicker response times and more accurate results, when compared to traditional procedures. Drones are highly useful thanks to their easy deployment, their aerial point-of-view and their ability to access difficult-to-reach spaces. Recent advances in aerial robotics and AI have already pushed drone automation to an unprecedented degree in various application domains, such as infrastructure inspection and maintenance, aerial cinematography, search and rescue operations, etc. Manipulation, processing, analysis and learning of visual signals lie at the forefront of this revolution. This special session will consider current research in this interdisciplinary subject, aiming to bring together researchers working on image/video analysis and experts in aerial robotics. Topics of interest may include, among others: - Embedded computer vision - Deep learning for image/video analysis - Multimodal perception - Sensor and data fusion - Fault and anomaly detection in drone footage - Subcentimeter-accuracy inspection - Autonomous drone cinematography - Vision-based localization and mapping - Vision-based drone navigation/control - Vision-based human-drone interaction This Special Session concerns a very timely topic with high industrial potential, given that fully/semi- automated drones are slowly emerging as a viable alternative to manually teleoperated ones, thanks to recent advances in robotics and AI. A lot of underlying cognitive functionalities that enable such autonomy, particularly the ones facilitating drone perception, rely on advanced image/video analysis methods for achieving their goals, making this a highly interdisciplinary topic of exceptional interest both to imaging scientists and aerial robotics researchers. The Special Session is organized by Prof. I. Pitas and Dr. I. Mademlis, from the Artificial Intelligence and Information Analysis Lab (AIIA Lab), Aristotle University of Thessaloniki, Greece (AUTH), under the auspices of the EU-funded Horizon 2020 programme AERIAL-CORE (https://aerial-core.eu/). Relevant links: 1) Horizon2020 EU funded R&D project Aerial-Core: https://aerial-core.eu/ 2) AIIA Lab: https://aiia.csd.auth.gr/ Sincerely yours, Prof. I. Pitas, Dr. Ioannis Mademlis, Artificial Intelligence and Information Analysis (AIIA) Lab, Aristotle University of Thessaloniki, Greece -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- To unsubscribe from this group and stop receiving emails from it, send an email to imageclef+unsubscribe(a)sheffield.ac.uk.

1 0

Address Assignment Practices in IPv4 and IPv6
by Stephen D. Strowes 21 Jan '21

21 Jan '21

Hi all, We've published a study on the stability of IPv4/IPv6 assignments in domestic ISPs, and the size of the IPv6 prefixes that networks typically assign to subscribers. We look at this from two different angles: what can we measure from RIPE Atlas, and what do operators state in the RIPE Database? In particular, understanding the size of IPv6 delegated prefixes is important for applications such as host reputation & blocklists, geolocation, and research on network measurement. The RIPE Database offers the community a way to share information on their prefix delegations, and deserves some attention! Read more here: https://labs.ripe.net/Members/stephen_strowes/address-assignment-practices-… Cheers, S.

1 0

RIPE 81 Address Policy WG Draft Minutes
by Angela Dall'Ara 14 Dec '20

14 Dec '20

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 81 have now been published: https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-81-addre… Please let us know of any corrections or amendments. Kind regards, Angela Dall'Ara RIPE NCC Policy Officer

1 0

NWI-4 - role of status: field in multivalued status context -- Last call
by ripedenis＠yahoo.co.uk 17 Nov '20

17 Nov '20

Hi Lee With the current data model it is not possible to have two independent objects with the same primary key. Creating 2 smaller objects is a work around. Having 2 status attributes is another work around. The question is, which work around is preferable? cheersdenis co-chair DB-WG On Tuesday, 17 November 2020, 14:25:35 CET, Howard, Lee <leehoward(a)hilcostreambank.com> wrote: That sounds like it would be confusing to me. I’d want to see both the allocation to the LIR and the assignment to the end user independently. Lee From: address-policy-wg <address-policy-wg-bounces(a)ripe.net>On Behalf Of ripedenis--- via address-policy-wg Sent: Monday, November 16, 2020 7:57 AM To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] NWI-4 - role of status: field in multivalued status context -- Last call Colleagues We have not had enough comment on this to make a decision if any change is needed. So can we have a last round of comment to decide if this is a sufficiently important issue to make a change or if we just close this action item? In brief: when assigning a whole allocation should we be able to give the INET(6)NUM object 2 status values to reflect it being both an allocation and an assignment, rather than splitting it into two smaller assignment objects? cheers denis co-chair DB-WG On Monday, 5 October 2020, 16:48:34 CEST, ripedenis--- via address-policy-wg <address-policy-wg(a)ripe.net> wrote: Colleagues I was about to post this to the DB-WG but it may be more appropriate to include it as part of this discussion... Yet another 4 year old NWI that needs to be progressed or closed. The details are here: https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html In summary it concerns the assignment of a whole allocation. Because the range is the primary key (pkey) in the database you cannot have an allocation object and an assignment object with the same pkey. A common work around is to split the allocation and make two assignments. The suggestion is to allow "status:" to be a multiple attribute. This could be done quite easily and constrained in it's use by business rules in the database software. So the syntax could be changed in INET(6)NUM objects to: status: [mandatory] [multiple] [ ] The business rules could make this multiple option only allowed in very limited situations. For example if an INETNUM object has 'status: ALLOCATED PA' it could be possible to add a second value 'status: ASSIGNED PA' or 'status: SUB-ALLLOCATED PA'. If the status in an INET6NUM object is 'status: ALLOCATED-BY-RIR' it could be possible to add a second value 'status: ALLOCATED-BY-LIR' or 'status: ASSIGNED'. The business rules could prevent any other multiple status values. The "descr:" attribute is already multiple so it can describe both the allocation and the assignment. Is this still considered to be an issue? cheers denis co-chair DB-WG On Monday, 5 October 2020, 16:13:53 CEST, Erik Bais <ebais(a)a2b-internet.com> wrote: Dear WG, I want to bring the following email and questions of our PDO - Petrit Hasani to your attention that might have slipped over the vacation period. Please have a look at this discussion again and provide input if you can. Regards, Erik Bais Co-chair AP-WG. ( on behalf of the AP-WG Chair collective ) On 02/07/2020, 13:36, "address-policy-wg on behalf of Petrit Hasani" <address-policy-wg-bounces(a)ripe.net on behalf of phasani(a)ripe.net> wrote: Dear colleagues, Thank you to everyone who responded to our earlier questions on the intent of the policy regarding IPv4 status hierarchies. While this was helpful, it would be great if we could have input from a wider group of people: - Should inetnums with these statuses be allowed to be created inside one another? - Should there be a limit on the minimum size of a sub-allocation? - Do we need a policy update? https://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.… We look forward to hearing from you. Cheers, -- Petrit Hasani Policy Officer RIPE NCC > On 16 Jun 2020, at 15:36, Petrit Hasani <phasani(a)ripe.net> wrote: > > Dear colleagues, > > We are reviewing IPv4 status hierarchies in the RIPE Database (looking at objects with the same status as their less-specifics). > > Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED PA", for example. Other statuses might need a closer look and we would like guidance from this working group. > > The RIPE Database does not currently have any limitations on creating inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under inetnums with the same status. This often results in chains of inetnums that have the same status, sometimes ending with the sub-allocation of a single IP address. > > Although this might not seem useful at first glance, there might be practical uses for a few levels of sub-allocation. For example, a global company could give sub-allocations to its national branches, which make smaller sub-allocations to their multiple daughter companies. These daughter companies could then create and maintain assignments for their actual networks. > > However, this is not allowed under a strict reading of the policy, as only the LIR itself can make sub-allocations, and these must be used for assignments. > > Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and Assignment Policies (ripe-733) states: > > "Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". > > [...] > > LIRs may make sub-allocations to multiple downstream network operators." > > https://www.ripe.net/publications/docs/ripe-733#54 > > Before making any changes, we want to be sure that we understand the intent of the policy and what the community wants us to do. Thus, we would like to hear from the Address Policy Working Group: > > - Should inetnums with these statuses be allowed to be created inside one another? > - Should there be a limit on the minimum size of a sub-allocation? > - Do we need a policy update? > > We look forward to your guidance. > > Kind regards, > -- > Petrit Hasani > Policy Officer > RIPE NCC > > > > >

1 0

NWI-4 - role of status: field in multivalued status context
by Stephane.Dodeller＠swisscom.com 17 Nov '20

17 Nov '20

Hello Denis, In my opinion, not having the feature forces us to implement the workaround you mention, which hurts data quality because it causes our entries not to reflect the reality of our allocations anymore. So the proposed feature is, in my opinion, needed. Best regards Stéphane Dodeller ---------------------------------------------------------------------- Message: 1 Date: Mon, 16 Nov 2020 12:57:02 +0000 (UTC) From: "ripedenis(a)yahoo.co.uk" <ripedenis(a)yahoo.co.uk> To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] NWI-4 - role of status: field in multivalued status context -- Last call Message-ID: <1444964547.10532158.1605531422218(a)mail.yahoo.com> Content-Type: text/plain; charset="utf-8" Colleagues We have not had enough comment on this to make a decision if any change is needed. So can we have a last round of comment to decide if this is a sufficiently important issue to make a change or if we just close this action item? In brief: when assigning a whole allocation should we be able to give the INET(6)NUM object 2 status values to reflect it being both an allocation and an assignment, rather than splitting it into two smaller assignment objects? cheersdenis co-chair DB-WG On Monday, 5 October 2020, 16:48:34 CEST, ripedenis--- via address-policy-wg <address-policy-wg(a)ripe.net> wrote: Colleagues I was about to post this to the DB-WG but it may be more appropriate to include it as part of this discussion... Yet another 4 year old NWI that needs to be progressed or closed. The details are here:https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.… In summary it concerns the assignment of a whole allocation. Because the range is the primary key (pkey) in the database you cannot have an allocation object and an assignment object with the same pkey. A common work around is to split the allocation and make two assignments. The suggestion is to allow "status:" to be a multiple attribute. This could be done quite easily and constrained in it's use by business rules in the database software. So the syntax could be changed in INET(6)NUM objects to:status:? ? ? ? ?[mandatory]? [multiple]? ? ?[ ] The business rules could make this multiple option only allowed in very limited situations. For example if an INETNUM object has 'status: ALLOCATED PA' it could be possible to add a second value 'status: ASSIGNED PA' or 'status: SUB-ALLLOCATED PA'. If the status in an INET6NUM object is 'status: ALLOCATED-BY-RIR' it could be possible to add a second value 'status: ALLOCATED-BY-LIR' or 'status: ASSIGNED'. The business rules could prevent any other multiple status values. The "descr:" attribute is already multiple so it can describe both the allocation and the assignment. Is this still considered to be an issue? cheersdenis co-chair DB-WG On Monday, 5 October 2020, 16:13:53 CEST, Erik Bais <ebais(a)a2b-internet.com> wrote: Dear WG,? I want to bring the following email and questions of our PDO - Petrit Hasani to your attention that might have slipped over the vacation period.? Please have a look at this discussion again and provide input if you can.? Regards, Erik Bais Co-chair AP-WG. ( on behalf of the AP-WG Chair collective ) ?On 02/07/2020, 13:36, "address-policy-wg on behalf of Petrit Hasani" <address-policy-wg-bounces(a)ripe.net on behalf of phasani(a)ripe.net> wrote: ? ? Dear colleagues, ? ? ? ? Thank you to everyone who responded to our earlier questions on the intent of the policy regarding IPv4 status hierarchies. ? ? ? ? While this was helpful, it would be great if we could have input from a wider group of people: ? ? ? ? - Should inetnums with these statuses be allowed to be created inside one another? ? ? - Should there be a limit on the minimum size of a sub-allocation? ? ? - Do we need a policy update? ? ? ? ? https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.… ? ? ? ? We look forward to hearing from you. ? ? ? ? Cheers, ? ? -- ? ? Petrit Hasani ? ? Policy Officer ? ? RIPE NCC ? ? ? ? ? ? ? ? ? ? ? ? > On 16 Jun 2020, at 15:36, Petrit Hasani <phasani(a)ripe.net> wrote: ? ? > ? ? > Dear colleagues, ? ? > ? ? > We are reviewing IPv4 status hierarchies in the RIPE Database (looking at objects with the same status as their less-specifics). ? ? > ? ? > Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED PA", for example. Other statuses might need a closer look and we would like guidance from this working group. ? ? > ? ? > The RIPE Database does not currently have any limitations on creating inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under inetnums with the same status. This often results in chains of inetnums that have the same status, sometimes ending with the sub-allocation of a single IP address. ? ? > ? ? > Although this might not seem useful at first glance, there might be practical uses for a few levels of sub-allocation. For example, a global company could give sub-allocations to its national branches, which make smaller sub-allocations to their multiple daughter companies. These daughter companies could then create and maintain assignments for their actual networks. ? ? > ? ? > However, this is not allowed under a strict reading of the policy, as only the LIR itself can make sub-allocations, and these must be used for assignments. ? ? > ? ? > Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and Assignment Policies (ripe-733) states: ? ? > ? ? > "Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". ? ? > ? ? > [...] ? ? > ? ? > LIRs may make sub-allocations to multiple downstream network operators." ? ? > ? ? > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.… ? ? > ? ? > Before making any changes, we want to be sure that we understand the intent of the policy and what the community wants us to do. Thus, we would like to hear from the Address Policy Working Group: ? ? > ? ? > - Should inetnums with these statuses be allowed to be created inside one another? ? ? > - Should there be a limit on the minimum size of a sub-allocation? ? ? > - Do we need a policy update? ? ? > ? ? > We look forward to your guidance. ? ? > ? ? > Kind regards, ? ? > -- ? ? > Petrit Hasani ? ? > Policy Officer ? ? > RIPE NCC ? ? > ? ? > ? ? > ? ? > ? ? > ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip…> End of address-policy-wg Digest, Vol 109, Issue 1 *************************************************

1 0

IPv4 status hierarchies
by Petrit Hasani 16 Nov '20

16 Nov '20

Dear colleagues, We are reviewing IPv4 status hierarchies in the RIPE Database (looking at objects with the same status as their less-specifics). Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED PA", for example. Other statuses might need a closer look and we would like guidance from this working group. The RIPE Database does not currently have any limitations on creating inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under inetnums with the same status. This often results in chains of inetnums that have the same status, sometimes ending with the sub-allocation of a single IP address. Although this might not seem useful at first glance, there might be practical uses for a few levels of sub-allocation. For example, a global company could give sub-allocations to its national branches, which make smaller sub-allocations to their multiple daughter companies. These daughter companies could then create and maintain assignments for their actual networks. However, this is not allowed under a strict reading of the policy, as only the LIR itself can make sub-allocations, and these must be used for assignments. Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and Assignment Policies (ripe-733) states: "Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". [...] LIRs may make sub-allocations to multiple downstream network operators." https://www.ripe.net/publications/docs/ripe-733#54 Before making any changes, we want to be sure that we understand the intent of the policy and what the community wants us to do. Thus, we would like to hear from the Address Policy Working Group: - Should inetnums with these statuses be allowed to be created inside one another? - Should there be a limit on the minimum size of a sub-allocation? - Do we need a policy update? We look forward to your guidance. Kind regards, -- Petrit Hasani Policy Officer RIPE NCC

5 7

stockpiling IPv6
by JORDI PALET MARTINEZ 28 Oct '20

28 Oct '20

Hi all, After Nikolas presentation today, I've been thinking on possible ways to resolve this, so before sending a possible policy proposal, I think it deserves some discussion. The intent of the proposal 2018-01 (https://www.ripe.net/participate/policies/proposals/2018-01), was to align the IPv4 and IPv6 policies in the matter of an LIR vs organization. We must remind that the allocation/assignment of resources is based on justified need. And yes, we have a lot of IPv6 space, but it is really justified and the same organization, having different LIRs, can use it as a trick for stockpiling if there is not such justified need? In IPv4 this is not "a problem" because we don't have more space. Well ... not exactly true ... some organizations could have used "the trick" to get more IPv4 space by creating multiple LIRs. In other regions, I think this is not a problem because the cost of the membership is not per "LIR" (flat rate in RIPE NCC), but based on the size of the allocation/assignment. So, because IPv6 is not a scarce resource, it seems there is no incentive to pay more for getting more if you're not really using it. However, in RIPE NCC, if you created several LIRs for getting more IPv4 allocations, *even if you don't use/need it* you can get (and thus stockpile) IPv6 *at no extra cost*. I clearly think this is not a good thing. It seems to me that the problem lies in section 5.1.1. Initial allocation criteria, and exactly here: b) have a plan for making sub-allocations to other organisations and/or End Site assignments within two years. So, is the problem that "a plan" is not sufficient if it is not "verified" and the "bad guys" know that the chances for having it verified are too small? Do we need some text about "recovery if not announced and used" ? Other ideas? Remember that the problem is not only about scarcity. This extra space may be used "intermittently" for bad or even criminal activities and we have a responsibility on that as a community. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

16 25

Policy Reciprocity
by Taiwo Oyewande 22 Oct '20

22 Oct '20

Hello, I am a co-author of the Resource Transfer Policy, which is the inter-RIR transfer proposal that has just reached consensus within Afrinic, and we are reaching out to you so as to inquire about its reciprocity with RIPE. Your assessment and analysis about this matter would highly be appreciated. Please find below the proposal for your reference. [ Resource Transfer Policy Authors: Anthony Ubah & Taiwo Oyewande Submission date: 21/09/2020 Version: 2.0 Amends: CPM 5.7 1. Summary of the problem being addressed by this proposal The current policy fails to support a two-way Inter-RIR policy, thereby hindering smooth business operation, development, and growth in the region. This proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. This proposal outlines a model in which AFRINIC can freely transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 addresses and AS numbers. 2. Summary of how this proposal addresses the problem With the exhaustion of IPv4, several regions have adopted a transfer policy to accommodate the shortage of resources. Number resources are allowed to transfer within the region itself, as well as with other regions. Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operations while reducing prices. Such Inter-RIR transfer, however, is not yet established in AFRINIC. This hinders business operation and development within the African region. The current proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. Before moving to illustrate how this new mechanism works, let’s take a quick look at the situation of the current Consolidated Policy Manual: In Consolidated Policy Manual updated on 22 Feb 2019, only “IPv4 resources transfer within the AFRINIC region” is mentioned. Regarding resource transfer to other regions, only the following is mentioned: 5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered. The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied. The lack of a clear guideline of resource transfer is detrimental to the continent’s development. It makes business operation difficult and it also hinders new business from establishing in the region. Also, as Inter RIR policy is enforced in other regions, it is important that AFRINIC keeps up with other RIRs to ensure smooth operation and coordination. 3. Proposal CPM 5.7 will be modified by this proposal as follows: 5.7 IPv4 Resources resource transfer Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within and outside the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization. 5.7.1 Summary of the policy This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region. 5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC or any RIR member's account or from a Legacy Resource Holder. 5.7.3. Conditions on the source of the transfer 5.7.3.1 The source must be the current and rightful holder of the IPv4 address resources registered with any RIR , and shall not be involved in any disputes as to those resources' status. 5.7.3.2 Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for a period of twelve (12) months after a transfer is approved. Incoming transferred resource cannot be transferred again for a period of twelve(12) months. 5.7.3.3 There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the source and the recipient. 5.7.4. Conditions on the recipient of the transfer 5.7.4.1 A transfer from another RIR to AFRINIC requires a need-based evaluation. AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force. A transfer from AFRINIC to another RIR must follow the relevant policies. 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] We are looking forward to hearing from you. Regards, Taiwo O

13 24

Assignments have legacy status, not IP addresses themselves
by David Farmer 21 Oct '20

21 Oct '20

The concept that the legacy status applies independently to resources or IP addresses, separate from their assignment to a resource holder, seems incorrect. The legacy status applies to the assignment of resources to a resource holder before the creation of the RIRs, but not to the resources or the IP addresses themselves. All IPv4 addresses were created at the same time. When they were assigned for use differs; therefore, when they were assigned for use and to whom they are assigned for use is what matters. When addresses are transferred to a different organization, a new assignment is made, or in other words, they are reassigned. And it seems proper that the new assignment no longer has the legacy status, as they are now assigned to a different organization. When a merger or acquisition occurs, we also call that a transfer, but it is a transfer to a new version of the same organization, not to a different organization. In this case, it seems propers that the assignment maintains its legacy status, as the same organization, just a different version of the same organization, continues to hold the assignment. The legacy status is important and is not a mistake because, as a community, we believe it is important to maintain the uniqueness of the assignments made before the creation of the RIRs. However, at least in my opinion, it is a mistake to believe that the legacy status applies to IP addresses independent of who holds the assignment. Thank you. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

2 2

Re: [address-policy-wg] FW: Policy Reciprocity
by JORDI PALET MARTINEZ 19 Oct '20

19 Oct '20

Hi Erik, Regarding your response on reciprocity: If we do that in AFRINIC, then, there is no reciprocity with ARIN, which is the bigger “donor”. I already tried several models, for both LACNIC and AFRINIC, and they didn’t work out. Finally, making a full reciprocal proposal in LACNIC worked and it was implemented already since last July. I also included a “security belt” in the AFRINIC proposal so the board can “control” if anything is going wrong by six consecutive months, to stop the policy … the community was happy initially with that, but later on, there were to other competitive proposals that make the people unhappy again … Point 5.7.4.3 is broken, the idea was “incoming transferred legacy resources will no longer be regarded as legacy”, because that’s what we have now already for intra-RIR (and this policy motifies that to become intra and inter). Regards, Jordi @jordipalet El 19/10/20 15:52, "address-policy-wg en nombre de Erik Bais" <address-policy-wg-bounces(a)ripe.net en nombre de ebais(a)a2b-internet.com> escribió: Hi Petrit & Taiwo, Petrit, could you have a look at the following question from Taiwo in regards to the Afrinic policy proposal reciprocity with the current RIPE Transfer Policy. To Taiwo, <personal view> Personally I would argue if reciprocity should be desired for the Afrinic region, as long as AFRINIC still holds IP numbers to be handed out. I personally would prefer the AFRINIC inter-rir transfer policy to be incoming from other RIR’s only, to avoid the AFRINIC space to be removed from the region. ( As I think Afrinic would need them more to develop its own inter regional growth. ) Am I correct to assume that Afrinic at the current distribution rate would have about 30 months of IP space left ? So perhaps opening the bi-directional inter-rir transfers, could start once the AFRINIC region actually has no space left in its free pool. </end personal view> In the RIPE region, there is a 24 month transfer limitation on the resource that was transferred itself, there is no further limitation on either the leaving (source) or receiving (target) entity to engage in other transactions. On the point : Ø 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region The AFRINIC legal team might have to look if this is phrased correctly, as you can’t (shouldn’t be able ) to move Afrinic Allocated space to a Legacy space holder.. Afrinic allocated space should only be able to move to any of the other RIR members. Not directly to a Legacy holder. Legacy space registered in the Afrinic region could go to any organisation, regardless if they are a RIR member. There might be other contractual requirements required in the receiving RIR.. as the RIPE legacy policy would explain for the RIPE region. I can see the intention, but that is not what the policy states. (or how I read it..) And on point : Ø 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] If you would remove the word incoming, it would provide a more bi-directional way of looking at it, from an AFRINIC perspective. And still leave it to the receiving RIR to apply their own Legacy ‘policy’ Regards, Erik Bais Co-chair of AP-WG https://www.ripe.net/publications/docs/ripe-682 - RIPE Transfer policy ( including intra and inter-rir transfers ) https://www.ripe.net/publications/docs/ripe-639 - RIPE NCC Services to Legacy Internet Resource Holders ( aka the RIPE Legacy services policy ) https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services… ( Services provided based on the type of contractual agreement with the RIPE NCC ) From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> on behalf of Taiwo Oyewande <taiwo.oyewande88(a)gmail.com> Date: Friday 16 October 2020 at 13:35 To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> Cc: Anthony Ubah <ubah.tonyiyke(a)gmail.com> Subject: [address-policy-wg] Policy Reciprocity Hello, I am a co-author of the Resource Transfer Policy, which is the inter-RIR transfer proposal that has just reached consensus within Afrinic, and we are reaching out to you so as to inquire about its reciprocity with RIPE. Your assessment and analysis about this matter would highly be appreciated. Please find below the proposal for your reference. [ Resource Transfer Policy Authors: Anthony Ubah & Taiwo Oyewande Submission date: 21/09/2020 Version: 2.0 Amends: CPM 5.7 1. Summary of the problem being addressed by this proposal The current policy fails to support a two-way Inter-RIR policy, thereby hindering smooth business operation, development, and growth in the region. This proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. This proposal outlines a model in which AFRINIC can freely transfer number resources to/from other regions, i.e. RIPE NCC, APNIC, ARIN and LACNIC. This includes both IPv4 addresses and AS numbers. 2. Summary of how this proposal addresses the problem With the exhaustion of IPv4, several regions have adopted a transfer policy to accommodate the shortage of resources. Number resources are allowed to transfer within the region itself, as well as with other regions. Such practice is effective and necessary when we are facing a shortage of resources. This helps facilitate business operations while reducing prices. Such Inter-RIR transfer, however, is not yet established in AFRINIC. This hinders business operation and development within the African region. The current proposal aims to establish an efficient and business-friendly mechanism to allow number resources to be transferred from/to other regions. Before moving to illustrate how this new mechanism works, let’s take a quick look at the situation of the current Consolidated Policy Manual: In Consolidated Policy Manual updated on 22 Feb 2019, only “IPv4 resources transfer within the AFRINIC region” is mentioned. Regarding resource transfer to other regions, only the following is mentioned: 5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered. The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied. The lack of a clear guideline of resource transfer is detrimental to the continent’s development. It makes business operation difficult and it also hinders new business from establishing in the region. Also, as Inter RIR policy is enforced in other regions, it is important that AFRINIC keeps up with other RIRs to ensure smooth operation and coordination. 3. Proposal CPM 5.7 will be modified by this proposal as follows: 5.7 IPv4 Resources resource transfer Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within and outside the region is needed. The goal of this policy is to define conditions under which transfers must occur. The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization. 5.7.1 Summary of the policy This policy applies to any transfer request raised by a resource holder for resource transfer to and from the AFRINIC region. 5.7.2 IPv4 resources to be transferred - must be from an existing AFRINIC or any RIR member's account or from a Legacy Resource Holder. 5.7.3. Conditions on the source of the transfer 5.7.3.1 The source must be the current and rightful holder of the IPv4 address resources registered with any RIR , and shall not be involved in any disputes as to those resources' status. 5.7.3.2 Source entities are not eligible to receive any further IPv4 allocations or assignments from AFRINIC for a period of twelve (12) months after a transfer is approved. Incoming transferred resource cannot be transferred again for a period of twelve(12) months. 5.7.3.3 There is no upper limit regarding the amount of transfer, allocation and assignment of IPv4 number resources a source entity can receive as long as the transfer request is carried out under a mutual agreement between the source and the recipient. 5.7.4. Conditions on the recipient of the transfer 5.7.4.1 A transfer from another RIR to AFRINIC requires a need-based evaluation. AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify and demonstrate before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force. A transfer from AFRINIC to another RIR must follow the relevant policies. 5.7.4.2 The recipient must be an AFRINIC or any RIR member, legacy holders in any region 5.7.4.3 Incoming transferred legacy resources will still be regarded as legacy resources.] We are looking forward to hearing from you. Regards, Taiwo O ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

1 0

Draft Agenda RIPE81 - virtual AP-WG
by Erik Bais 12 Oct '20

12 Oct '20

Dear working group, dear RIPE meeting folks, Below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in online on the following time slot: Wednesday, Oct 28, 10:00 - 10:45 As we only have 1 time slot, we have a packed agenda. We don’t have any open policy discussions atm, however if you have any Address Policy related policy suggestions, feel free to reach out to us. Besides the usual PDO/RIR & Registration services updates, we will also have a presentation from the RIPE NCC legal team about the topic: Seizure of the “Right to Registration of IPv4 Addresses” for the Recovery of Money. As WG Chairs we thought it would be a good topic to discuss in the AP-WG. So make sure you are present for the session. Regards, Gert Döring & Erik Bais, APWG chairs ---------------------------------------------------------------------- Wednesday, 10:00-10:45 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics – Petrit Hasani – RIPE NCC PDO - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE 80 - brief overview of new proposals (if any) C. Feedback from NCC Registration Service - Nikolas Pediaditis (+ discussion with the group) D. Presentation about the Seizure of the “Right to Registration of IPv4 Addresses” - Ciaran Byrne ( Legal Counsel of the RIPE NCC ) Z. AOB

1 0