From jameskennedy001 at gmail.com Mon May 1 11:56:21 2023 From: jameskennedy001 at gmail.com (James Kennedy) Date: Mon, 1 May 2023 11:56:21 +0200 Subject: [address-policy-wg] Call for presentations, Address Policy WG at RIPE86 (Rotterdam, The Netherlands) Message-ID: Dear Address Policy WG, With RIPE86 fast approaching - 22 to 26 May, 2023 - we are busy arranging the agenda for the Address Policy Working Group sessions. https://ripe86.ripe.net/programme/meeting-plan/ Is there a topic or issue that you would like to bring to the attention of the working group? If so, please send us an email at apwg-chairs at ripe.net, stating: - the topic you would like to discuss and a short description - the expected duration of your presentation - if you intend on being onsite in Rotterdam or online Regards, James on behalf of the Address Policy WG co-chairs From leo at vegoda.org Wed May 3 22:12:17 2023 From: leo at vegoda.org (Leo Vegoda) Date: Wed, 3 May 2023 13:12:17 -0700 Subject: [address-policy-wg] Fwd: Coop WG interim session on Wednesday, May 3rd 15:00-16:00 CEST In-Reply-To: <66BCD719-B898-473E-A291-DB28311C7465@gmail.com> References: <66BCD719-B898-473E-A291-DB28311C7465@gmail.com> Message-ID: Dear Address Policy WG, Please review the pages linked in Desiree, Julf, and Achilleas's message below. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs ---------- Forwarded message --------- From: Desiree Miloshevic Date: Wed, 3 May 2023 at 02:37 Subject: Coop WG interim session on Wednesday, May 3rd 15:00-16:00 CEST To: Cc: Cooperation WG Chairs Dear WG chairs Please find the announcement about Cooperation Working Group Small Task Team session today at 15:00 - 16:00 CEST. We would be grateful if you could share it with your working group members as well. https://www.ripe.net/participate/ripe/wg/active-wg/coop/interim-sessions/cooperation-working-group-interim-session-small-task-team-to-respond-to-european-commission-consultation-on-the-future-of-the-electronic-communications-sector-and-its-infrastructure The announcement was sent to the mailing list as well. https://www.ripe.net/ripe/mail/archives/ripe-list/2023-March/002814.html Best Desiree, Julf, Achilleas -- Coop WG Co-Chairs From matthias.wichtlhuber at de-cix.net Thu May 4 08:21:38 2023 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Thu, 4 May 2023 06:21:38 +0000 Subject: [address-policy-wg] 2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <53dfc57e-dff2-d252-e58b-3cae26ae3373@foobar.org> References: <281efcf3-c3d2-b8c1-f914-b4969ec12b04@ripe.net>, <53dfc57e-dff2-d252-e58b-3cae26ae3373@foobar.org> Message-ID: <6ac522b4caf447ebb752d539ca717d40@de-cix.net> Hi Nick, > I can't work out what the proposed new section 7 is saying. This paragraph only has an editorial change, it is already present in the current policy. It covers the time threshold for returning space: after 180 days of disuse or from a new assignment received as per points 4 and 5. > there are a bunch of problematic edge cases associated with section 5. E.g. what happens if an IXP has a /23 and has 254 IP addresses used after 1Y? They will be obliged to downgrade to a /24, according to the current text. Also I don't know what a special circumstance is. > The problems in section 5 can be fixed easily, but it depends on how the authors want to handle assignment upgrades / renumberings. I'd suggest either dropping the 1Y utilisation requirement to e.g. 40%, or else that if you reach e.g. 80% current usage, you qualify to receive an assignment of 2x the current, up to /22. Those figures are plucked out of the air btw. The point with them is that they are not 50%, which is obviously a magic number when the natural increase of assignment size would be to double the size of the block. The goal of this part is to minimize renumberings while avoiding greedy requests. Dropping the one year requirement to 40% is reasonable if you think 50% is too harsh ("magic numbers"). We can incorporate this change. Regarding the "special circumstances": this was already present in the current policy. I guess it is intended to give RIPE a little leeway to react to unforeseen circumstances. Kind regards, Matthias -- Dr.-Ing. Matthias Wichtlhuber Team Lead Research and Development ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber at de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ________________________________________ Von: address-policy-wg im Auftrag von Nick Hilliard Gesendet: Mittwoch, 26. April 2023 16:59:59 An: Angela Dall'Ara Cc: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] 2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) Angela Dall'Ara wrote on 06/03/2023 10:43: As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. two issues: - I can't work out what the proposed new section 7 is saying. - there are a bunch of problematic edge cases associated with section 5. E.g. what happens if an IXP has a /23 and has 254 IP addresses used after 1Y? They will be obliged to downgrade to a /24, according to the current text. Also I don't know what a special circumstance is. The problems in section 5 can be fixed easily, but it depends on how the authors want to handle assignment upgrades / renumberings. I'd suggest either dropping the 1Y utilisation requirement to e.g. 40%, or else that if you reach e.g. 80% current usage, you qualify to receive an assignment of 2x the current, up to /22. Those figures are plucked out of the air btw. The point with them is that they are not 50%, which is obviously a magic number when the natural increase of assignment size would be to double the size of the block. Nick From jameskennedy001 at gmail.com Sun May 7 20:58:14 2023 From: jameskennedy001 at gmail.com (James Kennedy) Date: Sun, 7 May 2023 19:58:14 +0100 Subject: [address-policy-wg] 2023-02 - Review Phase Ended (Minimum Size for IPv4 Temporary Assignments) Message-ID: Dear All, The Review Phase of policy proposal 2023-02 - Minimum Size for IPv4 Temporary Assignments - ended on 2nd May, 2023. https://www.ripe.net/participate/policies/proposals/2023-02 Taking into consideration the feedback received, the proposers will work on making the wording of their proposal clearer. The change will be purely editorial, the content will not be modified. The RIPE NCC will soon publish the new version of the proposal and the policy draft, and announce an extension of the Review Phase. Regards, James co-chair apwg From steven.bakker at ams-ix.net Mon May 8 15:56:11 2023 From: steven.bakker at ams-ix.net (Steven Bakker) Date: Mon, 8 May 2023 13:56:11 +0000 Subject: [address-policy-wg] 2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <6ac522b4caf447ebb752d539ca717d40@de-cix.net> References: <281efcf3-c3d2-b8c1-f914-b4969ec12b04@ripe.net> , <53dfc57e-dff2-d252-e58b-3cae26ae3373@foobar.org> <6ac522b4caf447ebb752d539ca717d40@de-cix.net> Message-ID: <344a354bead7646932e6056a5c90eea5b460166b.camel@ams-ix.net> On Thu, 2023-05-04 at 06:21 +0000, Matthias Wichtlhuber via address- policy-wg wrote: > > The problems in section 5 can be fixed easily, but it depends on > > how the authors want to handle assignment upgrades / renumberings. > > I'd suggest either dropping the 1Y utilisation requirement to e.g. > > 40%, or else that if you reach e.g. 80% current usage, you qualify > > to receive an assignment of 2x the current, up to /22.? Those > > figures are plucked out of the air btw. The point with them is that > > they are not 50%, which is obviously a magic number when the > > natural increase of assignment size would be to double the size of > > the block. > > The goal of this part is to minimize renumberings while avoiding > greedy requests. Dropping the one year requirement to 40% is > reasonable if you think 50% is too harsh ("magic numbers"). We can > incorporate this change. I believe that what Nick was getting at was that 50% is "magic" in the sense that it creates a problem: * a /24 has 254 usable addresses. * a /23 has 510 usable addresses -> half of that is 255. So, suppose you have used 230 addresses out of your /24. You apply for and get a /23 and happily renumber. Then, after one year, you have used 254 addresses. This is less than half of the /23 (510/2 = 255), so according to the rules you'd have to downgrade back to a /24 again. You can now no longer grow, unless you immediately apply for a /23 again. So we either live with this "bug" and trust that whoever has to perform evaluation is "reasonable", or we find a numbers that don't cause these kind of edge cases. Cheers, Steven -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From me at cynthia.re Mon May 8 18:42:17 2023 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Mon, 8 May 2023 18:42:17 +0200 Subject: [address-policy-wg] 2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <53dfc57e-dff2-d252-e58b-3cae26ae3373@foobar.org> References: <281efcf3-c3d2-b8c1-f914-b4969ec12b04@ripe.net> <53dfc57e-dff2-d252-e58b-3cae26ae3373@foobar.org> Message-ID: Hi, I just want to quickly pop in and say that I really agree with Nick in wanting to avoid these "magic numbers". I do not know which numbers would be appropriate, but probably somewhere around 40-45% (instead of 50%). -Cynthia On Wed, Apr 26, 2023 at 5:04?PM Nick Hilliard wrote: > > Angela Dall'Ara wrote on 06/03/2023 10:43: > > As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. > > > two issues: > > - I can't work out what the proposed new section 7 is saying. > - there are a bunch of problematic edge cases associated with section 5. E.g. what happens if an IXP has a /23 and has 254 IP addresses used after 1Y? They will be obliged to downgrade to a /24, according to the current text. Also I don't know what a special circumstance is. > > The problems in section 5 can be fixed easily, but it depends on how the authors want to handle assignment upgrades / renumberings. I'd suggest either dropping the 1Y utilisation requirement to e.g. 40%, or else that if you reach e.g. 80% current usage, you qualify to receive an assignment of 2x the current, up to /22. Those figures are plucked out of the air btw. The point with them is that they are not 50%, which is obviously a magic number when the natural increase of assignment size would be to double the size of the block. > > Nick > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From adallara at ripe.net Tue May 9 16:31:26 2023 From: adallara at ripe.net (Angela Dall'Ara) Date: Tue, 9 May 2023 16:31:26 +0200 Subject: [address-policy-wg] 2023-02 Extended Review Phase (Minimum Size for IPv4 Temporary Assignments) Message-ID: Dear colleagues, The policy proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments" is now in the extended Review Phase in an updated version. Following up on the feedback received, the wording was simplified without changing the proposal content. This policy proposal recommends setting the minimum assignment size for IPv4 temporary assignments to a /24,while still allowing for a smaller assignment if requested by the End User. This policy proposal also allows routing requirements to justify the request for more than a /24 for research purposes. As per the RIPE Policy Development Process (PDP), the purpose of this Review Phase extension is to continue discussing the proposal taking the impact analysis into consideration, and to review the updated versionof the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. If you support this version of the proposal (v 2.0), please indicate that support with a simple message to the mailing list. If you have objections or would like a change, please provide that feedback to the mailing list. You can find the proposal and impact analysis at: _https://www.ripe.net/participate/policies/proposals/2023-02_ _https://www.ripe.net/participate/policies/proposals/2023-02#impact-analysis_ And the draft document at: _https://www.ripe.net/participate/policies/proposals/2023-02/draft_ We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg at ripe.net before 29May 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameskennedy001 at gmail.com Fri May 12 11:00:18 2023 From: jameskennedy001 at gmail.com (James Kennedy) Date: Fri, 12 May 2023 11:00:18 +0200 Subject: [address-policy-wg] Draft Address Policy WG Agenda - RIPE 86 Message-ID: Dear Address Policy WG, This is the draft agenda for our sessions in Rotterdam at RIPE 86 later this month. If you would like to add a topic for discussion, please send us an email at apwg-chairs at ripe.net. Regards, James (on behalf of the co-chairs) Address Policy Working Group Wednesday, 24 May 10:30 - 11:30 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda A. Introduction [5 mins] B. Chair Selection [5 mins] C. ASO AC Update [10 mins] D. Registry Services Update Followed by Q&A [15 minutes] E. Policy Update Followed by Q&A [15 mins] F. Concept: AGGREGATED-BY-LIR status for IPv4 PA assignments [10 mins] Wednesday, 24 May 11:00 - 12:00 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda G. 2023-01: Reducing IXP IPv4 assignment default size to a /26 [15 mins] H. 2023-02: Minimum Size for IPv4 Temporary Assignments [15 mins] I. IPv6 Policy Review [25 mins] J. AOB [5 mins] From jan at go6.si Fri May 12 14:57:47 2023 From: jan at go6.si (Jan Zorz - Go6) Date: Fri, 12 May 2023 14:57:47 +0200 Subject: [address-policy-wg] Draft Address Policy WG Agenda - RIPE 86 In-Reply-To: References: Message-ID: <23ae005c-abdf-ad8e-bb3d-322b3ec8115d@go6.si> Hey, On 12/05/2023 11:00, James Kennedy wrote: > Wednesday, 24 May 10:30 - 11:30 (UTC+2) > Wednesday, 24 May 11:00 - 12:00 (UTC+2) You may want to fix the start and end time of the second session for publication on the web site :) Cheers, Jan From jameskennedy001 at gmail.com Fri May 12 15:26:53 2023 From: jameskennedy001 at gmail.com (James Kennedy) Date: Fri, 12 May 2023 15:26:53 +0200 Subject: [address-policy-wg] Draft Address Policy WG Agenda - RIPE 86 In-Reply-To: <23ae005c-abdf-ad8e-bb3d-322b3ec8115d@go6.si> References: <23ae005c-abdf-ad8e-bb3d-322b3ec8115d@go6.si> Message-ID: Thanks for flagging, Jan. My Friday morning coffee clearly wasn't strong enough ;) Correct draft agenda below. Regards, James Address Policy Working Group Wednesday, 24 May 10:30 - 11:30 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda A. Introduction [5 mins] B. Chair Selection [5 mins] C. ASO AC Update [10 mins] D. Registry Services Update Followed by Q&A [15 minutes] E. Policy Update Followed by Q&A [15 mins] F. Concept: AGGREGATED-BY-LIR status for IPv4 PA assignments [10 mins] Wednesday, 24 May 12:00 - 13:00 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda G. 2023-01: Reducing IXP IPv4 assignment default size to a /26 [15 mins] H. 2023-02: Minimum Size for IPv4 Temporary Assignments [15 mins] I. IPv6 Policy Review [25 mins] J. AOB [5 mins] On Fri, May 12, 2023 at 2:58?PM Jan Zorz - Go6 wrote: > > Hey, > > On 12/05/2023 11:00, James Kennedy wrote: > > Wednesday, 24 May 10:30 - 11:30 (UTC+2) > > Wednesday, 24 May 11:00 - 12:00 (UTC+2) > > You may want to fix the start and end time of the second session for > publication on the web site :) > > Cheers, Jan > > > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From jlauwers at a2b-internet.com Mon May 15 21:41:21 2023 From: jlauwers at a2b-internet.com (Jeroen Lauwers) Date: Mon, 15 May 2023 19:41:21 +0000 Subject: [address-policy-wg] Checking interest in the community for changing IPv4 assignments policy Message-ID: <79D3C196-D78F-4ED9-895B-86ABDD5D5FFF@a2b-internet.com> Hi Everyone, Now RIPE 86 is around the corner Tore and I would like to check if there is any interest in changing the way of making assignments in the IPv4 policy. At this moment we got 3 major points coming repetitively back from the community. 1. The current policy asks for a lot of repetitive work in making these assignments and it would be nice if, with a policy change, a lot of this repetitive work could be taken away. 2. There is a lot of under and over-assigning in the RIPE DB where a policy change would be beneficial to take some of the reasons away for this. 3. Policy 6.3 ?Network Infrastructure and End User Networks? can be interpreted differently for what the right use case is. Including the feedback from the previous policy proposal, we are thinking about introducing AGGREGATED-BY-LIR status just as in the IPv6 policy. In this way, we can aggregate multiple assignments into one AGGREGATED-BY-LIR assignment which we think would result in improving the above-mentioned points. We would like to check what the community thinks about this plan and if there is enough positive feedback we would like to make a concept proposal from it and present this at RIPE86. Kind regards, Jeroen From ripedenis at gmail.com Tue May 16 02:08:44 2023 From: ripedenis at gmail.com (denis walker) Date: Tue, 16 May 2023 02:08:44 +0200 Subject: [address-policy-wg] Checking interest in the community for changing IPv4 assignments policy In-Reply-To: <79D3C196-D78F-4ED9-895B-86ABDD5D5FFF@a2b-internet.com> References: <79D3C196-D78F-4ED9-895B-86ABDD5D5FFF@a2b-internet.com> Message-ID: Hi Jeroen What is the real reason for this push to dump assignments? I just don't buy these arguments. On Mon, 15 May 2023 at 21:41, Jeroen Lauwers wrote: > > Hi Everyone, > > > Now RIPE 86 is around the corner Tore and I would like to check if there is any interest in changing the way of making assignments in the IPv4 policy. At this moment we got 3 major points coming repetitively back from the community. > > 1. The current policy asks for a lot of repetitive work in making these assignments and it would be nice if, with a policy change, a lot of this repetitive work could be taken away. I know it is an odd thing to consider in this industry, but this is what computers are good at doing. It is 2023. Everyone is talking about how AI is going to take control of humanity soon. But the internet industry cannot automate the syncing of your internal IPAM with the RIPE Database? I don't think we need to worry about AI yet. > > 2. There is a lot of under and over-assigning in the RIPE DB where a policy change would be beneficial to take some of the reasons away for this. We don't need to take away reasons, we just need to automate and do it properly. > > 3. Policy 6.3 ?Network Infrastructure and End User Networks? can be interpreted differently for what the right use case is. I don't see anything in 6.2 that is open to interpretation or relevant to the case for dumping assignments. > > Including the feedback from the previous policy proposal, we are thinking about introducing AGGREGATED-BY-LIR status just as in the IPv6 policy. In this way, we can aggregate multiple assignments into one AGGREGATED-BY-LIR assignment which we think would result in improving the above-mentioned points. I think it is a bad idea to hide the users of blocks of IP addresses from the public in a public registry database. With a modern approach to creating the data in the database, there is no need for AGGREGATED-BY-LIR for either IPv4 or IPv6. The RIPE Database is not just for the benefit of resource holders, it is a public registry. I don't care if we have 10m assignments, 20m assignments as IPv6 gathers momentum. With automated data generation it is not a problem to create the correct data and keep it up to date. With a good query interface anyone interested in information about one IP address can easily and quickly find it. The other 20m entries are not a problem. There is also the issue of responsibility and liability. All resource holders (members) have signed an SSA. In that agreement they accept legal responsibility and liability for any and all usage of their allocated address space. With an updated, automated data generation process the RIPE Database will publicly show the correct details for who this responsibility and liability has been delegated to. Anyone pursuing a civil action or any LEA pursuing a criminal action can apply that action to the most specific user of the address space in question. If you hide the details of the end users, they only have the resource holders details. But as the resource holder has legally accepted full responsibility and liability for any and all usage of this address space, I see no reason why an LEA can't take action against the resource holder for any criminal activity involving their allocated address space. Why would they bother to get court orders in multiple languages and legal jurisdictions to find the end user details when they know who has accepted responsibility and liability...the resource holder. If you hide all your end user details, don't be surprised if you are held accountable. I have also heard the argument that many resource holders don't want to publish details of their customers for fear of another resource holder trying to offer them a better deal. In the IPv4 world there is so little address space available there is not much chance of anyone taking your customers away. Your bigger customers may not want to renumber anyway. But if this is a genuine concern to lots of resource holders, why not add a clause to the SSA forbidding members from direct marketing other member's customers? I see no benefits and lots of downsides to dumping assignments. cheers denis co-chair DB-WG > > We would like to check what the community thinks about this plan and if there is enough positive feedback we would like to make a concept proposal from it and present this at RIPE86. > > Kind regards, > > Jeroen > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From mschmidt at ripe.net Tue May 16 18:12:28 2023 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 16 May 2023 18:12:28 +0200 Subject: [address-policy-wg] 2023-01 - Clarification about the utilisation requirement for IXPs requesting an assignment larger a /24 In-Reply-To: <344a354bead7646932e6056a5c90eea5b460166b.camel@ams-ix.net> References: <281efcf3-c3d2-b8c1-f914-b4969ec12b04@ripe.net> <53dfc57e-dff2-d252-e58b-3cae26ae3373@foobar.org> <6ac522b4caf447ebb752d539ca717d40@de-cix.net> <344a354bead7646932e6056a5c90eea5b460166b.camel@ams-ix.net> Message-ID: <43469f9d-5da9-65aa-512e-f704ad0295f1@ripe.net> Dear colleagues, Reading the comments on this list, I would like to provide some clarification. If the proposal is accepted, it would only change the initial assignment size and offer the option to "jump" directly to a /24 when at least 33 addresses are in use. The utilisation requirements for IXPs requesting assignments larger than a /24 would remain unchanged. When receiving requests for more than a /24, the RIPE NCC checks that the IXP will need more than 50% of the assignment within one year. If their growth rate is too slow and we expect that it will take more than a year to exceed that utilisation threshold, we suggest that they postpone their request. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 08/05/2023 15:56, Steven Bakker via address-policy-wg wrote: > On Thu, 2023-05-04 at 06:21 +0000, Matthias Wichtlhuber via address- > policy-wg wrote: >>> The problems in section 5 can be fixed easily, but it depends on >>> how the authors want to handle assignment upgrades / renumberings. >>> I'd suggest either dropping the 1Y utilisation requirement to e.g. >>> 40%, or else that if you reach e.g. 80% current usage, you qualify >>> to receive an assignment of 2x the current, up to /22.? Those >>> figures are plucked out of the air btw. The point with them is that >>> they are not 50%, which is obviously a magic number when the >>> natural increase of assignment size would be to double the size of >>> the block. >> The goal of this part is to minimize renumberings while avoiding >> greedy requests. Dropping the one year requirement to 40% is >> reasonable if you think 50% is too harsh ("magic numbers"). We can >> incorporate this change. > I believe that what Nick was getting at was that 50% is "magic" in the > sense that it creates a problem: > > * a /24 has 254 usable addresses. > * a /23 has 510 usable addresses -> half of that is 255. > > So, suppose you have used 230 addresses out of your /24. You apply for > and get a /23 and happily renumber. > > Then, after one year, you have used 254 addresses. This is less than > half of the /23 (510/2 = 255), so according to the rules you'd have to > downgrade back to a /24 again. You can now no longer grow, unless you > immediately apply for a /23 again. > > So we either live with this "bug" and trust that whoever has to perform > evaluation is "reasonable", or we find a numbers that don't cause these > kind of edge cases. > > Cheers, > Steven > From erik at bais.name Wed May 17 10:51:55 2023 From: erik at bais.name (Erik Bais) Date: Wed, 17 May 2023 08:51:55 +0000 Subject: [address-policy-wg] Chair re-appointment - RIPE86 Message-ID: Dear Working group, As you might remember, the WG Chairs are appointed for a set term as that reminds us now and then, for both the WG Chair as the WG, to think about if we are still happy with the current chair setup. More insight on the terms can be found at the AP-WG page on the RIPE website: https://www.ripe.net/participate/ripe/wg/active-wg/ap This RIPE86, the first term of both James Kennedy and Leo Vegoda is done and both stated that they would be more than happy to do another term. As the co-Chair of AP-WG, I'm glad that both want to run again for the stability of the WG, however in the end it is up to the WG if you are as well. So during the AP-WG session, we will have time in the agenda to ask the WG if you like to proceed with the current WG Chair setup. If you to replace one or both WG Chairs, please let me know up front and I will contact you to ask a couple questions in regards of introduction .. and we will ask the WG if they would like a WG chair change. We like to hear in the WG if you like to support the current WG chairs (or not) ... this can be done by a reply on this email, or during the meeting. See you all next week in Rotterdam. Regards, Erik Bais Co-Chair AP-WG From tore at fud.no Wed May 17 10:56:12 2023 From: tore at fud.no (Tore Anderson) Date: Wed, 17 May 2023 10:56:12 +0200 Subject: [address-policy-wg] Checking interest in the community for changing IPv4 assignments policy In-Reply-To: References: <79D3C196-D78F-4ED9-895B-86ABDD5D5FFF@a2b-internet.com> Message-ID: <7d4252aaea5495c900f217e49dcd537813508220.camel@fud.no> On Tue, 2023-05-16 at 02:08 +0200, denis walker wrote: > What is the real reason for this push to dump assignments? I just > don't buy these arguments. Hi Denis, The reason / rationale is as stated. There is no "real" reason apart from that. Of course, the formal proposal will elaborate further. I do not quite understand what you mean by "dumping assignments". To be clear, our proposal would not invalidate any existing assignments, nor mandate that LIRs change their current practices, whatever they may be. > I know it is an odd thing to consider in this industry, but this is > what computers are good at doing. It is 2023. Everyone is talking > about how AI is going to take control of humanity soon. But the > internet industry cannot automate the syncing of your internal IPAM > with the RIPE Database? I don't think we need to worry about AI yet. > > (...) > > > We don't need to take away reasons, we just need to automate and do > it properly. Requiring LIRs to create automated systems that export their entire IPAM contents to the RIPE database is out of scope for this proposal. However, I would note that this proposal would not in any way prevent LIRs from building and using such systems, should they prefer to do so. > > 3. Policy 6.3 ?Network Infrastructure and End User Networks? can be > > interpreted differently for what the right use case is. > > I don't see anything in 6.2 that is open to interpretation or > relevant to the case for dumping assignments. The current policy is clear enough, it is the actual implementation of it that is currently somewhat out of sync. In particular, it says that ?IP addresses used ***solely*** for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure?. (Emphasis mine.) This mechanism is widely used in IPv4 in a similar way as AGGREGATED- BY-LIR is in IPv6, i.e., by aggregating multiple customer assignments into a single database object. However, any use of the IP address by the customer beyond the ?connection to the service provider? purpose, would make this mechanism unavailable to the LIR. Consider for example if a home broadband subscriber sets up a public Minecraft server on their home LAN and exposes it on the public IPv4 address using port forwarding functionality in their home gateway. The policy does strictly speaking mandate a separate assignment to be registered for that single IPv4 address, but this requirement is widely ignored (quite understandably). IPv6's AGGREGATED-BY-LIR, on the other hand, does not have this issue. > > Including the feedback from the previous policy proposal, we are > > thinking about introducing AGGREGATED-BY-LIR status just as in the > > IPv6 policy. In this way, we can aggregate multiple assignments > > into one AGGREGATED-BY-LIR assignment which we think would result > > in improving the above-mentioned points. > > I think it is a bad idea to hide the users of blocks of IP addresses > from the public in a public registry database. This proposal is not about "hiding" anything, at least not something that is not already non-public information (e.g., due to GDPR requirements). This is about aggregating bulk assignments made to multiple end users where the LIRs themselves, not the end users, are the point of contact for any technical queries from third parties, such as abuse reports or information requests from law enforcement agencies. Some typical examples are dynamic pools assigned to home broadband subscribers, cloud VPS instances, and so on. Our view is that the AGGREGATED-BY-LIR status found in the IPv6 policy caters to this use case in a more appropriate way than the IPv4 policy does, and that by "backporting" the mechanism we end up with an improved IPv4 policy and, as an additional bonus, more unified IPvX policies. > With a modern approach to creating the data in the database, there is > no need for AGGREGATED-BY-LIR for either IPv4 or IPv6. Removal of the AGGREGATED-BY-LIR mechanism from the IPv6 policy, and the IPv4 bulk assignment mechanism in 6.2 of the IPv4 policy for that matter, is out of scope for this proposal. However, I will note that it appears that quite a lot (likely the majority) of individual IPv6 assignments made are covered by AGGREGATED-BY-LIR inet6num objects, which suggests to me that the community does indeed see the need for a mechanism that allows them to register bulk assignments as aggregated objects in the database. Tore From remco.vanmook at gmail.com Wed May 17 11:02:58 2023 From: remco.vanmook at gmail.com (Remco van Mook) Date: Wed, 17 May 2023 11:02:58 +0200 Subject: [address-policy-wg] Chair re-appointment - RIPE86 In-Reply-To: References: Message-ID: Strong support for both. Thanks Leo and James for your work. Remco On Wed, 17 May 2023, 10:52 Erik Bais, wrote: > Dear Working group, > > As you might remember, the WG Chairs are appointed for a set term as that > reminds us now and then, for both the WG Chair as the WG, to think about if > we are still happy with the current chair setup. > > More insight on the terms can be found at the AP-WG page on the RIPE > website: https://www.ripe.net/participate/ripe/wg/active-wg/ap > > This RIPE86, the first term of both James Kennedy and Leo Vegoda is done > and both stated that they would be more than happy to do another term. > > As the co-Chair of AP-WG, I'm glad that both want to run again for the > stability of the WG, however in the end it is up to the WG if you are as > well. > > So during the AP-WG session, we will have time in the agenda to ask the WG > if you like to proceed with the current WG Chair setup. > > If you to replace one or both WG Chairs, please let me know up front and I > will contact you to ask a couple questions in regards of introduction .. > and we will ask the WG if they would like a WG chair change. > > We like to hear in the WG if you like to support the current WG chairs (or > not) ... this can be done by a reply on this email, or during the meeting. > > See you all next week in Rotterdam. > > Regards, > Erik Bais > Co-Chair AP-WG > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://mailman.ripe.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phessler at theapt.org Fri May 19 10:52:19 2023 From: phessler at theapt.org (Peter Hessler) Date: Fri, 19 May 2023 10:52:19 +0200 Subject: [address-policy-wg] 2023-02 Minimum Size for IPv4 Temporary Assignments Message-ID: I support this proposal. I initially was confused on the second clause of the new text for section 3.3, but it became clear when I read the entire context within the new proposal. -peter -- Weinberg's First Law: Progress is made on alternate Fridays. From tore at fud.no Wed May 24 13:41:04 2023 From: tore at fud.no (Tore Anderson) Date: Wed, 24 May 2023 13:41:04 +0200 Subject: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: Message-ID: On Mon, 2023-04-24 at 09:01 +0200, Angela Dall'Ara wrote: > The policy proposal 2023-01, "Reducing IXP IPv4 assignment default > size to a /26" is now in the extended Discussion Phase. > > This proposal modifies the default size of IPv4 assignments for IXPs > from a /24 to /26 and clarifies the return of the assignments > previously issued for their IXP peering LAN. I believe this proposal is a step in the right direction, so I support advancing it to the review phase. Tore From tore at fud.no Wed May 24 13:41:13 2023 From: tore at fud.no (Tore Anderson) Date: Wed, 24 May 2023 13:41:13 +0200 Subject: [address-policy-wg] 2023-02 Extended Review Phase (Minimum Size for IPv4 Temporary Assignments) In-Reply-To: References: Message-ID: <74e3ea367c2e63cd3090bb95381bd32c81b60696.camel@fud.no> On Tue, 2023-05-09 at 16:31 +0200, Angela Dall'Ara wrote: > The policy proposal 2023-02, "Minimum Size for IPv4 Temporary > Assignments" is now in the extended Review Phase in an updated > version. > > Following up on the feedback received, the wording was simplified > without changing the proposal content. > > This policy proposal recommends setting the minimum assignment size > for IPv4 temporary assignments to a /24, while still allowing for a > smaller assignment if requested by the End User. This policy proposal > also allows routing requirements to justify the request for more than > a /24 for research purposes. Seems sensible to me. Support. Tore From jordi.palet at consulintel.es Wed May 24 16:58:08 2023 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 24 May 2023 16:58:08 +0200 Subject: [address-policy-wg] IPv6 policy Message-ID: As usual, I?m happy to take over the job of drafting a new policy proposal (I?ve already drafted something some months ago). I can do it alone or together with some other folks. (sorry was not able to join this morning, but just looked at the video) 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. From cfriacas at fccn.pt Mon May 29 10:26:37 2023 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Mon, 29 May 2023 09:26:37 +0100 (WEST) Subject: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: Message-ID: Greetings, I would like to express my support to this proposal, as it aims to extend the usability of the IXP reserved pool, without any impact on operations of new IXPs. Regards, CArlos On Wed, 24 May 2023, Tore Anderson wrote: > On Mon, 2023-04-24 at 09:01 +0200, Angela Dall'Ara wrote: > >> The policy proposal 2023-01, "Reducing IXP IPv4 assignment default >> size to a /26" is now in the extended Discussion Phase. >> >> This proposal modifies the default size of IPv4 assignments for IXPs >> from a /24 to /26 and clarifies the return of the assignments >> previously issued for their IXP peering LAN. > > I believe this proposal is a step in the right direction, so I support > advancing it to the review phase. > > Tore > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ > From cfriacas at fccn.pt Mon May 29 10:29:03 2023 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Mon, 29 May 2023 09:29:03 +0100 (WEST) Subject: [address-policy-wg] 2023-02 Extended Review Phase (Minimum Size for IPv4 Temporary Assignments) In-Reply-To: <74e3ea367c2e63cd3090bb95381bd32c81b60696.camel@fud.no> References: <74e3ea367c2e63cd3090bb95381bd32c81b60696.camel@fud.no> Message-ID: <778c7bd-6c63-8e52-e4ec-b2459cea9898@fccn.pt> Greetings, I would like to express my support for 2023-02. While i don't see it as a big priority, it makes sense for me to write in these proposed changes. Regards, Carlos On Wed, 24 May 2023, Tore Anderson wrote: > On Tue, 2023-05-09 at 16:31 +0200, Angela Dall'Ara wrote: > >> The policy proposal 2023-02, "Minimum Size for IPv4 Temporary >> Assignments" is now in the extended Review Phase in an updated >> version. >> >> Following up on the feedback received, the wording was simplified >> without changing the proposal content. >> >> This policy proposal recommends setting the minimum assignment size >> for IPv4 temporary assignments to a /24, while still allowing for a >> smaller assignment if requested by the End User. This policy proposal >> also allows routing requirements to justify the request for more than >> a /24 for research purposes. > > Seems sensible to me. Support. > > Tore > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ >