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

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