From adallara at ripe.net Mon Sep 4 11:54:14 2023 From: adallara at ripe.net (Angela Dall'Ara) Date: Mon, 4 Sep 2023 11:54:14 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Message-ID: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> Dear colleagues, A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 PA assignments" is now available for discussion. This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-04 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. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 We encourage you to review this proposal and send your comments to address-policy-wg at ripe.net before 3 October 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC From registry at apex.dp.ua Mon Sep 4 13:01:00 2023 From: registry at apex.dp.ua (APEX NCC ORG) Date: Mon, 4 Sep 2023 14:01:00 +0300 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> Message-ID: <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> Hello, Team! I read the offer provided: https://www.ripe.net/participate/policies/proposals/2023-04 three times. However, I still don't understand the real reason for introducing the AGGREGATED-BY-LIR status The text of the proposal contains only general provisions. Can you provide a more detailed description and examples? Thank you! Regards. On 9/4/23 12:54, Angela Dall'Ara wrote: > Dear colleagues, > > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for > IPv4 PA assignments" > is now available for discussion. > > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 > PA assignments to reduce LIR efforts in registration and maintenance. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2023-04 > > 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. > > At the end of the Discussion Phase, the proposers, with the agreement > of the WG Chairs, will decide how to proceed with the proposal. > > The PDP document can be found at: > https://www.ripe.net/publications/docs/ripe-781 > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 3 October 2023. > > > Kind regards, > > Angela Dall'Ara > Policy Officer > RIPE NCC > > -- Best wishes, APEX NCC ORG -------------------------------- +38(056)-731-99-11, +38(067)-731-99-11, +38(050)-731-99-11, www.trifle.net From tore at fud.no Mon Sep 4 13:21:31 2023 From: tore at fud.no (Tore Anderson) Date: Mon, 04 Sep 2023 13:21:31 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> Message-ID: <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> * APEX NCC ORG > Hello, Team! > I read the offer provided: > https://www.ripe.net/participate/policies/proposals/2023-04 > three times. > However, I still don't understand the real reason for introducing the > AGGREGATED-BY-LIR status > The text of the proposal contains only general provisions. > Can you provide a more detailed description and examples? Hi Andrii! There are several possible examples, but let me give you just one: Let's say you're a small cloud VPS provider in the business of leasing out virtual machines to small businesses and private individuals. Your cloud management software dynamically assigns IPv4 addresses out of 192.0.2.0/24 to customers, so you have for example: 192.0.2.1/32 = assigned to Alice's first VM - used for a web server 192.0.2.2/32 = assigned to Bob - used for a Minecraft server 192.0.2.3/32 = assigned to Bob's hair salon business = web server 192.0.2.4/32 = assigned to Alice's second VM - mail server ?and so on. Current policy requires you to register four individual INETNUM assignments of size /32 for the above four virtual machines. However, due to the GDPR requirements, you usually cannot put Alice's and Bob's names or contact info into the RIPE database, so instead you typically substitute your own (this is allowed by policy). That means you have now four individual INETNUMs with identical contact information (your own). You need to add or remove these /32 INETNUMs as customer VMs come and go. You can automate this, but it is a pointless exercise in any case. To avoid this, we propose allowing you to create a single INETNUM that covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can already do with any IPv6 assignments made to the same VMs. This aggregated object will cover all customer VMs in your cloud infrastructure, present and future, and makes it so that you don't have to send a RIPE database update every time a customer VM is provisioned or discontinued. Tore From registry at apex.dp.ua Tue Sep 5 12:57:52 2023 From: registry at apex.dp.ua (APEX NCC ORG) Date: Tue, 5 Sep 2023 13:57:52 +0300 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> Message-ID: <6a2aef85-cbbf-46b0-ac1c-51c2dd9363e1@apex.dp.ua> Thank you, Tore, for your quick feedback and time! Everything became clear now. Great thought and proposal. Have a good day! Regards, APEX NCC ORG. On 9/4/23 14:21, Tore Anderson wrote: > * APEX NCC ORG > >> Hello, Team! >> I read the offer provided: >> https://www.ripe.net/participate/policies/proposals/2023-04 >> three times. >> However, I still don't understand the real reason for introducing the >> AGGREGATED-BY-LIR status >> The text of the proposal contains only general provisions. >> Can you provide a more detailed description and examples? > Hi Andrii! > > There are several possible examples, but let me give you just one: > > Let's say you're a small cloud VPS provider in the business of leasing > out virtual machines to small businesses and private individuals. Your > cloud management software dynamically assigns IPv4 addresses out of > 192.0.2.0/24 to customers, so you have for example: > > 192.0.2.1/32 = assigned to Alice's first VM - used for a web server > 192.0.2.2/32 = assigned to Bob - used for a Minecraft server > 192.0.2.3/32 = assigned to Bob's hair salon business = web server > 192.0.2.4/32 = assigned to Alice's second VM - mail server > > ?and so on. > > Current policy requires you to register four individual INETNUM > assignments of size /32 for the above four virtual machines. > > However, due to the GDPR requirements, you usually cannot put Alice's > and Bob's names or contact info into the RIPE database, so instead you > typically substitute your own (this is allowed by policy). > > That means you have now four individual INETNUMs with identical contact > information (your own). You need to add or remove these /32 INETNUMs as > customer VMs come and go. You can automate this, but it is a pointless > exercise in any case. > > To avoid this, we propose allowing you to create a single INETNUM that > covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can > already do with any IPv6 assignments made to the same VMs. This > aggregated object will cover all customer VMs in your cloud > infrastructure, present and future, and makes it so that you don't have > to send a RIPE database update every time a customer VM is provisioned > or discontinued. > > Tore > -- Best wishes, APEX NCC ORG -------------------------------- +38(056)-731-99-11, +38(067)-731-99-11, +38(050)-731-99-11, www.trifle.net From va at meshroom.net Tue Sep 5 15:43:05 2023 From: va at meshroom.net (Viacheslav Adamanov) Date: Tue, 5 Sep 2023 15:43:05 +0200 Subject: [address-policy-wg] Reducing IXP IPv4 assignment default size to a /26 Message-ID: Dear community, The problem with ipv4 network speculation for IXP is exaggerated. RIPE NCC forbids transferring this networks to another company. Have there been cases of transmission of such networks? Kind regards, Viacheslav Adamanov. IXP Mesh Ukraine, Mariupol -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at servperso.com Tue Sep 5 16:02:12 2023 From: ml at servperso.com (Servperso) Date: Tue, 5 Sep 2023 16:02:12 +0200 Subject: [address-policy-wg] Reducing IXP IPv4 assignment default size to a /26 In-Reply-To: References: Message-ID: Hello, Yes, there is some. As an example, what append if you move your activity from sole proprietorship to company and sponsor an ixp ? Another example, small ixp backed by multiple isp. After sometime, one want to stop and move ressource to other one. Blocking PI for IXP transfert is a nonsense for me. Just ripe need to be sure they are still and only used for ixp usage. Also, pruposing a /26 maybe kill some abuse by design. I saw some IXP pi on fullview and they are not a "configuration mistake" from one member. Sarah Le 05-09-23 ? 15:43, Viacheslav Adamanov a ?crit?: > Dear community, > > The problem with ipv4 network speculation for IXP is exaggerated. RIPE > NCC forbids transferring this networks to another company. > > Have there been cases of transmission of such networks? > > Kind regards, > Viacheslav Adamanov. > > IXP Mesh > Ukraine, Mariupol > From michele at blacknight.com Wed Sep 6 18:14:06 2023 From: michele at blacknight.com (Michele Neylon - Blacknight) Date: Wed, 6 Sep 2023 16:14:06 +0000 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> Message-ID: Tore Thanks for the clear explanation of the use case. The proposal seems to be ?sane? so, unless somene can point out a fundamental flaw with it, we?d be supportive. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: address-policy-wg on behalf of Tore Anderson Date: Monday, 4 September 2023 at 12:21 To: Andrii Syrovatko , address-policy-wg at ripe.net , adallara at ripe.net Cc: APEX NCC ORG , Trifle NOC Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. * APEX NCC ORG > Hello, Team! > I read the offer provided: > https://www.ripe.net/participate/policies/proposals/2023-04 > three times. > However, I still don't understand the real reason for introducing the > AGGREGATED-BY-LIR status > The text of the proposal contains only general provisions. > Can you provide a more detailed description and examples? Hi Andrii! There are several possible examples, but let me give you just one: Let's say you're a small cloud VPS provider in the business of leasing out virtual machines to small businesses and private individuals. Your cloud management software dynamically assigns IPv4 addresses out of 192.0.2.0/24 to customers, so you have for example: 192.0.2.1/32 = assigned to Alice's first VM - used for a web server 192.0.2.2/32 = assigned to Bob - used for a Minecraft server 192.0.2.3/32 = assigned to Bob's hair salon business = web server 192.0.2.4/32 = assigned to Alice's second VM - mail server ?and so on. Current policy requires you to register four individual INETNUM assignments of size /32 for the above four virtual machines. However, due to the GDPR requirements, you usually cannot put Alice's and Bob's names or contact info into the RIPE database, so instead you typically substitute your own (this is allowed by policy). That means you have now four individual INETNUMs with identical contact information (your own). You need to add or remove these /32 INETNUMs as customer VMs come and go. You can automate this, but it is a pointless exercise in any case. To avoid this, we propose allowing you to create a single INETNUM that covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can already do with any IPv6 assignments made to the same VMs. This aggregated object will cover all customer VMs in your cloud infrastructure, present and future, and makes it so that you don't have to send a RIPE database update every time a customer VM is provisioned or discontinued. Tore -- 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 sander at steffann.nl Mon Sep 11 02:31:16 2023 From: sander at steffann.nl (Sander Steffann) Date: Mon, 11 Sep 2023 09:31:16 +0900 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> Message-ID: <48FA412B-BB34-4928-B712-23D9D823D9C9@steffann.nl> Hi, > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 PA assignments" > is now available for discussion. > > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. I agree with this proposal. I have used the AGGREGATED-BY-LIR status for IPv6, and I'd love to be able to do the same for IPv4. I am only a small LIR, so I won't have many objects with AGGREGATED-BY-LIR status, but nonetheless it will allow me to express the way I use my allocated IP addresses better. And I hope it will encourage others to do the same :) Cheers, Sander From rodolfo.garciapenas at telefonica.com Mon Sep 11 12:08:46 2023 From: rodolfo.garciapenas at telefonica.com (=?iso-8859-1?Q?RODOLFO_GARCIA_PE=D1AS?=) Date: Mon, 11 Sep 2023 10:08:46 +0000 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> Message-ID: Great proposal. I agree with it. Best Regards, Rodolfo Rodolfo Garc?a Pe?as (kix) Dise?o y Planificaci?n Conectividad IP | Telef?nica Espa?a -----Mensaje original----- De: address-policy-wg En nombre de Angela Dall'Ara Enviado el: lunes, 4 de septiembre de 2023 11:54 Para: RIPE Address Policy Working Group Asunto: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Dear colleagues, A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 PA assignments" is now available for discussion. This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-04 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. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 We encourage you to review this proposal and send your comments to address-policy-wg at ripe.net before 3 October 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o From sebastian at karotte.org Mon Sep 11 15:16:46 2023 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Mon, 11 Sep 2023 15:16:46 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> Message-ID: <20230911131646.vh53ie3betcn2hdo@vimes.home.karotte.org> * Angela Dall'Ara [2023-09-04 11:55]: > Dear colleagues, > > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 > PA assignments" > is now available for discussion. > > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA > assignments to reduce LIR efforts in registration and maintenance. I support this proposal. v4 and v6 should be as feature-equal as possible from a database point of view IMO. Best Regards Sebastian -- 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From boggits at gmail.com Mon Sep 11 15:40:55 2023 From: boggits at gmail.com (boggits) Date: Mon, 11 Sep 2023 14:40:55 +0100 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> Message-ID: On Mon, 4 Sept 2023 at 10:54, Angela Dall'Ara wrote: > > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA > assignments to reduce LIR efforts in registration and maintenance. > That sounds like a great idea, I'm just wondering if external viewers of the RIPEdb might infer things from this status that don't match its actual intent... Has anyone had any issues with the IPv6 version? Thx J -- James Blessing 07989 039 476 -------------- next part -------------- An HTML attachment was scrubbed... URL: From max at rfc2324.org Mon Sep 11 16:06:27 2023 From: max at rfc2324.org (Maximilian Wilhelm) Date: Mon, 11 Sep 2023 16:06:27 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <20230911131646.vh53ie3betcn2hdo@vimes.home.karotte.org> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <20230911131646.vh53ie3betcn2hdo@vimes.home.karotte.org> Message-ID: <20230911140627.GD18189@principal.rfc2324.org> Anno domini 2023 Sebastian Wiesinger scripsit: > * Angela Dall'Ara [2023-09-04 11:55]: > > Dear colleagues, > > > > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 > > PA assignments" > > is now available for discussion. > > > > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA > > assignments to reduce LIR efforts in registration and maintenance. > > I support this proposal. v4 and v6 should be as feature-equal as > possible from a database point of view IMO. +1 Cheers, Max -- "I have to admit I've always suspected that MTBWTF would be a more useful metric of real-world performance." -- Valdis Kletnieks on NANOG From ripe-wgs.cs at schiefner.de Mon Sep 11 16:35:42 2023 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 11 Sep 2023 16:35:42 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> Message-ID: <329693b3-bbc9-34f8-ffc8-0548976f1c56@schiefner.de> Read, understood & absolutely fine with it: +1 Best, -C. On 04.09.2023 11:54, Angela Dall'Ara wrote: > Dear colleagues, > > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for > IPv4 PA assignments" > is now available for discussion. > > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA > assignments to reduce LIR efforts in registration and maintenance. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2023-04 > > 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. > > At the end of the Discussion Phase, the proposers, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > The PDP document can be found at: > https://www.ripe.net/publications/docs/ripe-781 > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 3 October 2023. > > > Kind regards, > > Angela Dall'Ara > Policy Officer > RIPE NCC From Brian.Storey at gamma.co.uk Mon Sep 11 18:09:58 2023 From: Brian.Storey at gamma.co.uk (Brian Storey) Date: Mon, 11 Sep 2023 16:09:58 +0000 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> Message-ID: Hi Tore, Thanks for explaining this particular use case. Reading the proposed New Policy Text, it provides the LIR with an adminsitrative choice. Whilst I understand this choice, the rantionale behind the proposal is to find a reasonable way to fill the gap for the Provider Allocations not registered for the specific exception documented: "IP addresses used solely for the connection of an End User to a service provider... can be registered as part of the service provider's internal infrastructure". Given the choice provided in the proposal, it seems to me like I could go the other way with this and aggregate everything? The end user allocation size distinction no longer looks to apply and I could interprete that the "purpose" of the whole aggregate is consistent (they are all used to reach "stuff") and therefore chose to not register any end user assigned /29s, 28s, /27s etc. Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something? Many thanks, Brian -----Original Message----- From: address-policy-wg On Behalf Of Tore Anderson Sent: Monday, September 4, 2023 12:22 PM To: Andrii Syrovatko ; address-policy-wg at ripe.net; adallara at ripe.net Cc: APEX NCC ORG ; Trifle NOC Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) * APEX NCC ORG > Hello, Team! > I read the offer provided: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ripe.net%2Fparticipate%2Fpolicies%2Fproposals%2F2023-04&data=05%7C01%7 > Cbrian.storey%40gamma.co.uk%7C3a23e9f95d904f83274a08dbad391d6b%7C743a5 > d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638294233043320645%7CUnknown%7CT > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn0%3D%7C3000%7C%7C%7C&sdata=9dEJGnNWdlapbyyzjM5qgJvn%2BB6G%2BGp6jjmu > %2FcDzZPY%3D&reserved=0 > three times. > However, I still don't understand the real reason for introducing the > AGGREGATED-BY-LIR status The text of the proposal contains only > general provisions. > Can you provide a more detailed description and examples? Hi Andrii! There are several possible examples, but let me give you just one: Let's say you're a small cloud VPS provider in the business of leasing out virtual machines to small businesses and private individuals. Your cloud management software dynamically assigns IPv4 addresses out of 192.0.2.0/24 to customers, so you have for example: 192.0.2.1/32 = assigned to Alice's first VM - used for a web server 192.0.2.2/32 = assigned to Bob - used for a Minecraft server 192.0.2.3/32 = assigned to Bob's hair salon business = web server 192.0.2.4/32 = assigned to Alice's second VM - mail server ?and so on. Current policy requires you to register four individual INETNUM assignments of size /32 for the above four virtual machines. However, due to the GDPR requirements, you usually cannot put Alice's and Bob's names or contact info into the RIPE database, so instead you typically substitute your own (this is allowed by policy). That means you have now four individual INETNUMs with identical contact information (your own). You need to add or remove these /32 INETNUMs as customer VMs come and go. You can automate this, but it is a pointless exercise in any case. To avoid this, we propose allowing you to create a single INETNUM that covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can already do with any IPv6 assignments made to the same VMs. This aggregated object will cover all customer VMs in your cloud infrastructure, present and future, and makes it so that you don't have to send a RIPE database update every time a customer VM is provisioned or discontinued. Tore -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Faddress-policy-wg&data=05%7C01%7Cbrian.storey%40gamma.co.uk%7C3a23e9f95d904f83274a08dbad391d6b%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638294233043320645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jtDVwO2J07Os87Tt9U%2BLQ0eg2T%2FDFsDrknEX9fBy41k%3D&reserved=0 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4577 bytes Desc: not available URL: From ripedenis at gmail.com Mon Sep 11 18:23:45 2023 From: ripedenis at gmail.com (denis walker) Date: Mon, 11 Sep 2023 18:23:45 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> Message-ID: On Mon, 11 Sept 2023 at 18:09, Brian Storey wrote: > > Hi Tore, > > Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something? +1 my thoughts exactly cheers denis co-chair DB-WG > > Many thanks, > Brian > > -----Original Message----- > From: address-policy-wg On Behalf Of Tore Anderson > Sent: Monday, September 4, 2023 12:22 PM > To: Andrii Syrovatko ; address-policy-wg at ripe.net; adallara at ripe.net > Cc: APEX NCC ORG ; Trifle NOC > Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) > > * APEX NCC ORG > > > Hello, Team! > > I read the offer provided: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ripe.net%2Fparticipate%2Fpolicies%2Fproposals%2F2023-04&data=05%7C01%7 > > Cbrian.storey%40gamma.co.uk%7C3a23e9f95d904f83274a08dbad391d6b%7C743a5 > > d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638294233043320645%7CUnknown%7CT > > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > > 6Mn0%3D%7C3000%7C%7C%7C&sdata=9dEJGnNWdlapbyyzjM5qgJvn%2BB6G%2BGp6jjmu > > %2FcDzZPY%3D&reserved=0 > > three times. > > However, I still don't understand the real reason for introducing the > > AGGREGATED-BY-LIR status The text of the proposal contains only > > general provisions. > > Can you provide a more detailed description and examples? > > Hi Andrii! > > There are several possible examples, but let me give you just one: > > Let's say you're a small cloud VPS provider in the business of leasing out virtual machines to small businesses and private individuals. Your cloud management software dynamically assigns IPv4 addresses out of > 192.0.2.0/24 to customers, so you have for example: > > 192.0.2.1/32 = assigned to Alice's first VM - used for a web server > 192.0.2.2/32 = assigned to Bob - used for a Minecraft server > 192.0.2.3/32 = assigned to Bob's hair salon business = web server > 192.0.2.4/32 = assigned to Alice's second VM - mail server > > ?and so on. > > Current policy requires you to register four individual INETNUM assignments of size /32 for the above four virtual machines. > > However, due to the GDPR requirements, you usually cannot put Alice's and Bob's names or contact info into the RIPE database, so instead you typically substitute your own (this is allowed by policy). > > That means you have now four individual INETNUMs with identical contact information (your own). You need to add or remove these /32 INETNUMs as customer VMs come and go. You can automate this, but it is a pointless exercise in any case. > > To avoid this, we propose allowing you to create a single INETNUM that covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can already do with any IPv6 assignments made to the same VMs. This aggregated object will cover all customer VMs in your cloud infrastructure, present and future, and makes it so that you don't have to send a RIPE database update every time a customer VM is provisioned or discontinued. > > Tore > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Faddress-policy-wg&data=05%7C01%7Cbrian.storey%40gamma.co.uk%7C3a23e9f95d904f83274a08dbad391d6b%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638294233043320645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jtDVwO2J07Os87Tt9U%2BLQ0eg2T%2FDFsDrknEX9fBy41k%3D&reserved=0 > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From phessler at theapt.org Mon Sep 11 18:33:27 2023 From: phessler at theapt.org (Peter Hessler) Date: Mon, 11 Sep 2023 18:33:27 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> Message-ID: On 2023 Sep 11 (Mon) at 16:09:58 +0000 (+0000), Brian Storey wrote: :Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something? : This behaves the same as the IPv6 version, which has not had this problem yet. -- MESSAGE ACKNOWLEDGED -- The Pershing II missiles have been launched. From ripedenis at gmail.com Mon Sep 11 19:14:05 2023 From: ripedenis at gmail.com (denis walker) Date: Mon, 11 Sep 2023 19:14:05 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> Message-ID: On Mon, 11 Sept 2023 at 18:33, Peter Hessler wrote: > > On 2023 Sep 11 (Mon) at 16:09:58 +0000 (+0000), Brian Storey wrote: > :Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something? > : > > This behaves the same as the IPv6 version, which has not had this > problem yet. Maybe because IPv4 is still dominant for networks... > > > > -- > MESSAGE ACKNOWLEDGED -- The Pershing II missiles have been launched. > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From phessler at theapt.org Mon Sep 11 19:28:25 2023 From: phessler at theapt.org (Peter Hessler) Date: Mon, 11 Sep 2023 19:28:25 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> Message-ID: On 2023 Sep 11 (Mon) at 19:14:05 +0200 (+0200), denis walker wrote: :On Mon, 11 Sept 2023 at 18:33, Peter Hessler wrote: :> :> On 2023 Sep 11 (Mon) at 16:09:58 +0000 (+0000), Brian Storey wrote: :> :Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something? :> : :> :> This behaves the same as the IPv6 version, which has not had this :> problem yet. : :Maybe because IPv4 is still dominant for networks... : That should not be a blocker for this policy. And if a solution is needed/found, then it should be in a different policy that fixes it for both. -- Just remember: when you go to court, you are trusting your fate to twelve people that weren't smart enough to get out of jury duty! From rinse at kindes.nl Mon Sep 11 20:28:29 2023 From: rinse at kindes.nl (Rinse Kloek) Date: Mon, 11 Sep 2023 20:28:29 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> Message-ID: <943e681b-edf4-4c76-9542-0e6d67574a20@kindes.nl> On 4-9-2023 11:54, Angela Dall'Ara wrote: > Dear colleagues, > > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for > IPv4 PA assignments" > is now available for discussion. > > +1 I do support this proposal. Did like the AGGREGATED-BY-LIR for IPv6 and introducing this to IPv4 will make it easier to administrate large group of assignments. Also feature parity between IPv4 and IPv6 in the RIPE database is a good thing. From padnezz at gmail.com Mon Sep 11 20:31:43 2023 From: padnezz at gmail.com (=?UTF-8?Q?Andr=C3=A9_Pettersson?=) Date: Mon, 11 Sep 2023 20:31:43 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> Message-ID: +1 Great proposal. I support this. Kind regards, Andr? Den m?n 4 sep. 2023 kl 11:54 skrev Angela Dall'Ara : > Dear colleagues, > > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for > IPv4 PA assignments" > is now available for discussion. > > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA > assignments to reduce LIR efforts in registration and maintenance. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2023-04 > > 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. > > At the end of the Discussion Phase, the proposers, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > The PDP document can be found at: > https://www.ripe.net/publications/docs/ripe-781 > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 3 October 2023. > > > Kind regards, > > Angela Dall'Ara > Policy Officer > RIPE NCC > > > -- > > 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 me at cynthia.re Tue Sep 12 02:51:18 2023 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Tue, 12 Sep 2023 02:51:18 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> Message-ID: +1 makes sense to me -Cynthia On Mon, Sep 4, 2023 at 11:54?AM Angela Dall'Ara wrote: > > Dear colleagues, > > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for > IPv4 PA assignments" > is now available for discussion. > > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA > assignments to reduce LIR efforts in registration and maintenance. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2023-04 > > 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. > > At the end of the Discussion Phase, the proposers, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > The PDP document can be found at: > https://www.ripe.net/publications/docs/ripe-781 > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 3 October 2023. > > > Kind regards, > > Angela Dall'Ara > Policy Officer > RIPE NCC > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From gert at space.net Tue Sep 12 08:46:46 2023 From: gert at space.net (Gert Doering) Date: Tue, 12 Sep 2023 08:46:46 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> Message-ID: Hi, On Mon, Sep 11, 2023 at 04:09:58PM +0000, Brian Storey wrote: > Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something? Actually it gives the LIR *more* options to properly document their address usage. Anyone unwilling to register proper data is able to do so already today (especially given that the old incentive "if you do not properly document your address blocks, there will not be more IPv4 space from the NCC" is long gone). Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tore at fud.no Tue Sep 12 08:51:56 2023 From: tore at fud.no (Tore Anderson) Date: Tue, 12 Sep 2023 08:51:56 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> Message-ID: <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> Hi Brian, * Brian Storey > Thanks for explaining this particular use case. > > Reading the proposed New Policy Text, it provides the LIR with an > adminsitrative choice. Whilst I understand this choice, the > rantionale behind the proposal is to find a reasonable way to fill > the gap for the Provider Allocations not registered for the specific > exception documented: "IP addresses used solely for the connection of > an End User to a service provider... can be registered as part of the > service provider's internal infrastructure". > > Given the choice provided in the proposal, it seems to me like I > could go the other way with this and aggregate everything? The end > user allocation size distinction no longer looks to apply and I could > interprete that the "purpose" of the whole aggregate is consistent > (they are all used to reach "stuff") and therefore chose to not > register any end user assigned /29s, 28s, /27s etc. It depends on whether or not all your assignments are completely uniform (apart from the prefix value and length). If they are, you will be able to aggregate them. This means that they need to share a single common point of contact, which is often the case for assignments associated with fully managed Internet services provided to private individuals and small businesses. Such assignments would be possible to aggregate. If on the other hand they are not uniform (for example if your customers operate their own NOCs and therefore have different contact information), you will not be able to aggregate them. I will try to explain by example here as well. Let's say you currently have two customer assignments as follows: Customer 1: inetnum: 192.0.2.0 - 192.0.2.128 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: BRIAN-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE Customer 2: inetnum: 192.0.2.128 - 192.0.2.192 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: BRIAN-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE As you can see, except for the 'inetnum' value, they are completely identical. That means you will be able aggregate them into a single object: inetnum: 192.0.2.0 - 192.0.2.192 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: BRIAN-RIPE status: AGGREGATED-BY-LIR mnt-by: BRIAN-MNT source: RIPE The second example concerns the case where the assignments are not uniform. Let's say your customers operate their own NOCs, so your starting point instead is having these two assignments: Customer 1: inetnum: 192.0.2.0 - 192.0.2.128 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: CUST1-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE Customer 2: inetnum: 192.0.2.128 - 192.0.2.192 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: CUST2-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE Note how the 'tech-c' attribute differs between the two assignments. That means that not be able to replace them with an AGGREGATED-BY-LIR object. > Does this not contradict other purposes / objectives of the registry, > including the principles of registering public networks or am I > missing something? We do not believe so. As demonstrated above, only highly redundant data can be aggregated, so very little actual information lost in the process. Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel idea, it has been around in the IPv6 policy for many many years. If it was indeed the case that it contradicted the purposes and/or objectives of the registry, someone ought to have noticed and attempted to fix that problem by now. That has not happened, as far as we know, which we take as a sign that there is no such problem in the first place. Tore From leo at vegoda.org Tue Sep 12 13:55:43 2023 From: leo at vegoda.org (Leo Vegoda) Date: Tue, 12 Sep 2023 04:55:43 -0700 Subject: [address-policy-wg] Consensus - 2023-01 - Reducing IXP IPv4 assignment default size to a /26 Message-ID: Dear Working Group, Two comments were made during the Last Call phase. These comments did not address the subject of the policy proposal. This means the community has achieved a consensus. The RIPE NCC can proceed with implementation. Our thanks to everyone who contributed to this discussion. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs From matthias.wichtlhuber at de-cix.net Tue Sep 12 15:37:34 2023 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Tue, 12 Sep 2023 13:37:34 +0000 Subject: [address-policy-wg] Consensus - 2023-01 - Reducing IXP IPv4 assignment default size to a /26 In-Reply-To: References: Message-ID: Hi Leo, all, on behalf of my co-authors I would like to thank everyone contributing to this proposal with feedback and the chairs and the RIPE NCC team for coordinating the process. Its really great to see such a lively and constructive discussion. We should be proud of this community. Kind regards, Matthias PS: APNIC is discussing a similar idea now (https://www.apnic.net/wp-content/uploads/2023/08/prop-154-v001.txt). -- 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 Leo Vegoda Gesendet: Dienstag, 12. September 2023 13:55:43 An: address-policy-wg at ripe.net Betreff: [address-policy-wg] Consensus - 2023-01 - Reducing IXP IPv4 assignment default size to a /26 Dear Working Group, Two comments were made during the Last Call phase. These comments did not address the subject of the policy proposal. This means the community has achieved a consensus. The RIPE NCC can proceed with implementation. Our thanks to everyone who contributed to this discussion. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From ripedenis at gmail.com Tue Sep 12 16:56:07 2023 From: ripedenis at gmail.com (denis walker) Date: Tue, 12 Sep 2023 16:56:07 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> Message-ID: Hi Tore Your claims are not correct. Your simple example hides a lot of detail. I have given a real life example below taken from the database to illustrate what I mean. My apologies to the resource holder, but it is a perfect example to illustrate several points. On Tue, 12 Sept 2023 at 08:51, Tore Anderson wrote: > > Hi Brian, > > * Brian Storey > > > Given the choice provided in the proposal, it seems to me like I > > could go the other way with this and aggregate everything? The end > > user allocation size distinction no longer looks to apply and I could > > interprete that the "purpose" of the whole aggregate is consistent > > (they are all used to reach "stuff") and therefore chose to not > > register any end user assigned /29s, 28s, /27s etc. > > It depends on whether or not all your assignments are completely > uniform (apart from the prefix value and length). If they are, you will > be able to aggregate them. Your definition of 'completely uniform' seems to only apply to contact details, as you make clear in the next paragraph. Many assignment objects currently contain more information than just contact references. You are making the assumption that the RIPE Database is still nothing more than an operator's contact database for network operational issues. In which case all you need is the tech-c. > > This means that they need to share a single common point of contact, > which is often the case for assignments associated with fully managed > Internet services provided to private individuals and small businesses. > Such assignments would be possible to aggregate. > > If on the other hand they are not uniform (for example if your > customers operate their own NOCs and therefore have different contact > information), you will not be able to aggregate them. > > I will try to explain by example here as well. Let's say you currently > have two customer assignments as follows: > > Customer 1: > > inetnum: 192.0.2.0 - 192.0.2.128 > netname: BRIAN-ISP > country: GB > admin-c: BRIAN-RIPE > tech-c: BRIAN-RIPE > status: ASSIGNED PA > mnt-by: BRIAN-MNT > source: RIPE > > Customer 2: > > inetnum: 192.0.2.128 - 192.0.2.192 > netname: BRIAN-ISP > country: GB > admin-c: BRIAN-RIPE > tech-c: BRIAN-RIPE > status: ASSIGNED PA > mnt-by: BRIAN-MNT > source: RIPE > > As you can see, except for the 'inetnum' value, they are completely > identical. That means you will be able aggregate them into a single > object: But your example is a bare bones object. > > > Does this not contradict other purposes / objectives of the registry, > > including the principles of registering public networks or am I > > missing something? > > We do not believe so. As demonstrated above, only highly redundant data > can be aggregated, so very little actual information lost in the > process. In real life lots of information may be lost. > > Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel > idea, it has been around in the IPv6 policy for many many years. If it > was indeed the case that it contradicted the purposes and/or objectives > of the registry, someone ought to have noticed and attempted to fix > that problem by now. That has not happened, as far as we know, which we > take as a sign that there is no such problem in the first place. This community has very little appetite to fix things properly if a quick fix will do or they can live with existing problems. The constant 'fight' to try to fix many problems with the RIPE Database illustrates this point very well. Now let's look at a real life example. whois -rBm 195.238.192.0 - 195.238.223.255 The first thing to note is that the admin-c and tech-c values are the same in all the more specific assignments. Even the mnt-by is the same, although you make no mention if that is a blokker for aggregation or not. So by your definition these are 'completely uniform' objects and can be aggregated. You will also note that all these objects contain optional descr attributes. These attributes contain name and address details of the end user. That is important information for many stakeholder groups using the RIPE Database public registry. That detail will be lost in an aggregation. Given that current policy requires these assignments to be registered in the public registry, many users do include this detail. Now we all know the RIPE Database design and technology is very old and it does currently require some effort to manage this data. (A problem that all users have noticed but no one has attempted to fix.) Given a 'short cut' option, human nature suggests people will use it, even if it is not the right thing to do for a public registry. So aggregating across the whole database, may result in a massive amount of detail being lost from the public registry. Also note that there are gaps in the more specific assignments for this allocation. For example 195.238.193.224 - 195.238.193.255 is not assigned. Can your aggregated objects span these gaps? If so then we lose sight of what address space is in use or available. It may no longer be needed for further allocations but people do still use that information. The assignments are all randomly sized. Which is why you have dropped the inet6num assignment-size attribute for inetnum objects. So if I am getting abuse from one specific IP address what should I do? I have no idea from the aggregated block what the block size is that includes this one IP address. Is there any other way to find this information, maybe from routing details? If not, should I block and blacklist the entire aggregated block? That could affect hundreds, maybe even thousands, of users in some cases. This is not a problem with IPv6 as you know the size of the block containing that address. cheers denis c0-chair DB-WG > > Tore > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From me at cynthia.re Tue Sep 12 20:41:45 2023 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Tue, 12 Sep 2023 20:41:45 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> Message-ID: After reading denis's response I realized that I responded a bit too hastily with my +1. I am going to retract my support for this proposal as I really don't get why you would need this without the "assignment-size" attribute. I might have missed something but I can't see what possible benefit "AGGREGATED-BY-LIR" has over "SUB-ALLOCATED PA" without it. The only thing that I can think of is if you just want to just comply with the policy without providing any additional info, in which case the policy should just be updated to not require it if that is what the community wants. My reason for saying this is that some LIRs might choose to remove specific inet(6)num objects that they have already created and just create a big "AGGREGATED-BY-LIR" inet(6)num object as you can't have inet(6)num objects under it. Personally I would prefer it if an LIR just chose to document some of their assignments while leaving some undocumented over "documenting" them in a way that really doesn't specify any meaningful information. If I have missed something and there actually is a true benefit[0] to using "AGGREGATED-BY-LIR" without an "assignment-size" attribute then do let me know. I would really prefer if this was considered carefully before implementing it due to the potential risk of losing data currently in the database. -Cynthia [0]: "true benefit" here referring to something beyond just making it compliant with RIPE policy as I think there are better solutions if that is the case. On Tue, Sep 12, 2023 at 4:56?PM denis walker wrote: > > Hi Tore > > Your claims are not correct. Your simple example hides a lot of > detail. I have given a real life example below taken from the database > to illustrate what I mean. My apologies to the resource holder, but it > is a perfect example to illustrate several points. > > On Tue, 12 Sept 2023 at 08:51, Tore Anderson wrote: > > > > Hi Brian, > > > > * Brian Storey > > > > > Given the choice provided in the proposal, it seems to me like I > > > could go the other way with this and aggregate everything? The end > > > user allocation size distinction no longer looks to apply and I could > > > interprete that the "purpose" of the whole aggregate is consistent > > > (they are all used to reach "stuff") and therefore chose to not > > > register any end user assigned /29s, 28s, /27s etc. > > > > It depends on whether or not all your assignments are completely > > uniform (apart from the prefix value and length). If they are, you will > > be able to aggregate them. > > Your definition of 'completely uniform' seems to only apply to contact > details, as you make clear in the next paragraph. Many assignment > objects currently contain more information than just contact > references. You are making the assumption that the RIPE Database is > still nothing more than an operator's contact database for network > operational issues. In which case all you need is the tech-c. > > > > > This means that they need to share a single common point of contact, > > which is often the case for assignments associated with fully managed > > Internet services provided to private individuals and small businesses. > > Such assignments would be possible to aggregate. > > > > If on the other hand they are not uniform (for example if your > > customers operate their own NOCs and therefore have different contact > > information), you will not be able to aggregate them. > > > > I will try to explain by example here as well. Let's say you currently > > have two customer assignments as follows: > > > > Customer 1: > > > > inetnum: 192.0.2.0 - 192.0.2.128 > > netname: BRIAN-ISP > > country: GB > > admin-c: BRIAN-RIPE > > tech-c: BRIAN-RIPE > > status: ASSIGNED PA > > mnt-by: BRIAN-MNT > > source: RIPE > > > > Customer 2: > > > > inetnum: 192.0.2.128 - 192.0.2.192 > > netname: BRIAN-ISP > > country: GB > > admin-c: BRIAN-RIPE > > tech-c: BRIAN-RIPE > > status: ASSIGNED PA > > mnt-by: BRIAN-MNT > > source: RIPE > > > > As you can see, except for the 'inetnum' value, they are completely > > identical. That means you will be able aggregate them into a single > > object: > > But your example is a bare bones object. > > > > > > Does this not contradict other purposes / objectives of the registry, > > > including the principles of registering public networks or am I > > > missing something? > > > > We do not believe so. As demonstrated above, only highly redundant data > > can be aggregated, so very little actual information lost in the > > process. > > In real life lots of information may be lost. > > > > > Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel > > idea, it has been around in the IPv6 policy for many many years. If it > > was indeed the case that it contradicted the purposes and/or objectives > > of the registry, someone ought to have noticed and attempted to fix > > that problem by now. That has not happened, as far as we know, which we > > take as a sign that there is no such problem in the first place. > > This community has very little appetite to fix things properly if a > quick fix will do or they can live with existing problems. The > constant 'fight' to try to fix many problems with the RIPE Database > illustrates this point very well. > > Now let's look at a real life example. > > whois -rBm 195.238.192.0 - 195.238.223.255 > > The first thing to note is that the admin-c and tech-c values are the > same in all the more specific assignments. Even the mnt-by is the > same, although you make no mention if that is a blokker for > aggregation or not. So by your definition these are 'completely > uniform' objects and can be aggregated. > > You will also note that all these objects contain optional descr > attributes. These attributes contain name and address details of the > end user. That is important information for many stakeholder groups > using the RIPE Database public registry. That detail will be lost in > an aggregation. Given that current policy requires these assignments > to be registered in the public registry, many users do include this > detail. Now we all know the RIPE Database design and technology is > very old and it does currently require some effort to manage this > data. (A problem that all users have noticed but no one has attempted > to fix.) Given a 'short cut' option, human nature suggests people will > use it, even if it is not the right thing to do for a public registry. > So aggregating across the whole database, may result in a massive > amount of detail being lost from the public registry. > > Also note that there are gaps in the more specific assignments for > this allocation. For example 195.238.193.224 - 195.238.193.255 is not > assigned. Can your aggregated objects span these gaps? If so then we > lose sight of what address space is in use or available. It may no > longer be needed for further allocations but people do still use that > information. > > The assignments are all randomly sized. Which is why you have dropped > the inet6num assignment-size attribute for inetnum objects. So if I am > getting abuse from one specific IP address what should I do? I have no > idea from the aggregated block what the block size is that includes > this one IP address. Is there any other way to find this information, > maybe from routing details? If not, should I block and blacklist the > entire aggregated block? That could affect hundreds, maybe even > thousands, of users in some cases. This is not a problem with IPv6 as > you know the size of the block containing that address. > > cheers > denis > c0-chair DB-WG > > > > > > Tore > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From tore at fud.no Wed Sep 13 08:59:05 2023 From: tore at fud.no (Tore Anderson) Date: Wed, 13 Sep 2023 08:59:05 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> Message-ID: <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Hello Denis, Let me start off by clearing up a misunderstanding: My brief example did not mean to convey that non-uniform contact information is the only thing that could make a set of objects non- uniform and thus unsuitable for AGGREGATED-BY-LIR. Rather, the exact opposite was the intended meaning - which is that almost any attribute can make a set of objects non-uniform. The tech-c attribute was only used an example to demonstrate this. With that out of the way, my answers to your remaining points follow in-line: * denis walker > Now let's look at a real life example. > > whois -rBm 195.238.192.0 - 195.238.223.255 > > The first thing to note is that the admin-c and tech-c values are the > same in all the more specific assignments. Even the mnt-by is the > same, although you make no mention if that is a blokker for > aggregation or not. So by your definition these are 'completely > uniform' objects and can be aggregated. As I clarified above, these objects are in my view *not* uniform, as they have distinct netname, descr and country attributes (possibly others I missed too, I only skimmed through them quickly). The LIR in question clearly has a policy of publishing the street address of each assignee in the descr attribute. That is totally fine, and will continue to be totally fine after 2023-04 is implemented, but it makes their objects unsuitable for aggregation. > You will also note that all these objects contain optional descr > attributes. These attributes contain name and address details of the > end user. That is important information for many stakeholder groups > using the RIPE Database public registry. That detail will be lost in > an aggregation. Given that current policy requires these assignments > to be registered in the public registry, many users do include this > detail. Now we all know the RIPE Database design and technology is > very old and it does currently require some effort to manage this > data. (A problem that all users have noticed but no one has attempted > to fix.) Given a 'short cut' option, human nature suggests people > will use it, even if it is not the right thing to do for a public > registry. So aggregating across the whole database, may result in a > massive amount of detail being lost from the public registry. It is important to note that the information you mention as "important" here - the assignee's address - is (as you rightly point out) optional to include. An LIR is under no obligation to publish this information, and the inetnum object does not even contain an attribute dedicated to it. (While the organisation object has mandatory org-name and address attributes, the org attribute is optional in inetnum objects.) Thus the LIR in question already has a 'short cut' option available to them, should they feel managing the assignees' address information in the RIPE database is too burdensome - they can simply chose to not include that information in the first place. I want to emphasise that this policy proposal does not grant them this option, it is already there today. > Also note that there are gaps in the more specific assignments for > this allocation. For example 195.238.193.224 - 195.238.193.255 is not > assigned. Can your aggregated objects span these gaps? If so then we > lose sight of what address space is in use or available. It may no > longer be needed for further allocations but people do still use that > information. Yes, just as in IPv6, aggregated objects can span gaps. This is essential, as the primary use case targeted by AGGREGATED-BY-LIR is automated assignment pools with a high churn rate (e.g., a dynamic DHCP pool). In such environments, the .1, .2 and .3 addresses might be assigned before .2 might get de-assigned again - all within seconds, with no operator involvement. We believe it is not necessary to reflect this high level of granularity and rapid churn rate in the RIPE database. > The assignments are all randomly sized. Which is why you have dropped > the inet6num assignment-size attribute for inetnum objects. So if I > amgetting abuse from one specific IP address what should I do? I have > noidea from the aggregated block what the block size is that includes > this one IP address. Is there any other way to find this information, > maybe from routing details? If not, should I block and blacklist the > entire aggregated block? That could affect hundreds, maybe even > thousands, of users in some cases. This is not a problem with IPv6 as > you know the size of the block containing that address. My personal recommendation would be to block the specific IP address you are receiving abusive traffic from and send a complaint to the abuse-c for the inetnum in question. Note that this is not really much different than what you have to do today for abuse coming from customer assignments that are ?registered as part of the service provider's internal infrastructure?, cf. ripe- 708 section 6.2. That said, AGGREGATED-BY-LIR would here have made it clear that the abusive address is indeed assigned to a downstream customer and is not part of the service provider's internal infrastructure. Tore From tore at fud.no Wed Sep 13 09:35:23 2023 From: tore at fud.no (Tore Anderson) Date: Wed, 13 Sep 2023 09:35:23 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> Message-ID: <149185efdc91ce557a56aaf02c4976a21215798a.camel@fud.no> Hello Cynthia, * Cynthia Revstr?m > After reading denis's response I realized that I responded a bit too > hastily with my +1. > I am going to retract my support for this proposal as I really don't > get why you would need this without the "assignment-size" attribute. > I might have missed something but I can't see what possible benefit > "AGGREGATED-BY-LIR" has over "SUB-ALLOCATED PA" without it. > The only thing that I can think of is if you just want to just comply > with the policy without providing any additional info, in which case > the policy should just be updated to not require it if that is what > the community wants. The reason why we took "assignment-size" out, is that we understood its purpose (in the IPv6 policy) to be related to calculating the HD-ratio, which in turn is done to justify subsequent allocations. As I'm sure you're well aware, none of those things exist in IPv4, so there did not appear to be any purpose in keeping it in. > My reason for saying this is that some LIRs might choose to remove > specific inet(6)num objects that they have already created and just > create a big "AGGREGATED-BY-LIR" inet(6)num object as you can't have > inet(6)num objects under it. > Personally I would prefer it if an LIR just chose to document some of > their assignments while leaving some undocumented over "documenting" > them in a way that really doesn't specify any meaningful information. > > If I have missed something and there actually is a true benefit[0] to > using "AGGREGATED-BY-LIR" without an "assignment-size" attribute then > do let me know. > > I would really prefer if this was considered carefully before > implementing it due to the potential risk of losing data currently in > the database. You include inet6num objects here, so I want to make it crystal clear that AGGREGATED-BY-LIR already exists in IPv6 and that this proposal does not in any way change it. Therefore, if there really is something to worry about here, we ought to have seen evidence of it happening already in IPv6. I am not aware of anything like that, though. > [0]: "true benefit" here referring to something beyond just making it > compliant with RIPE policy as I think there are better solutions if > that is the case. We believe policy compliance is a goal worth striving for. As Gert said: ?Anyone unwilling to register proper data is able to do so already today?, but this requires ignoring certain requirements of the policy. This is not a hypothetical situation. As noted in the proposal text: ?As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs? (for the record: this data comes from the RIPE NCC, not us proposers) Our hypothesis is that a fair share of those are used for high-churn and automated small assignments (think cloud VPS instances, customer DHCP pools, etc.) which it is impractical to keep the RIPE database updated with in a synchronous manner. So they don't bother to even try to comply with the registration requirements in the policy. Another set of LIRs of unknown quantity will instead (ab)use the ?solely for the connection? exception to improperly register such assignments as being part of their own infrastructure. While perhaps a lesser evil compared to the above, this approach is not compliant with the policy either. With AGGREGATED-BY-LIR, we want to provide an attainable way for such LIRs to become policy compliant. We do believe there is a "true benefit" in that. Tore From tobias at fiebig.nl Thu Sep 14 12:28:18 2023 From: tobias at fiebig.nl (Tobias Fiebig) Date: Thu, 14 Sep 2023 12:28:18 +0200 Subject: [address-policy-wg] Status IPv6 Policy Draft Message-ID: <26c6b281e56655841fd6dc3201ac09a9869ba098.camel@fiebig.nl> Heho, i am currently scrolling over my inbox, and was wondering what the status of the v6 policy draft is (with 87 coming up). Is anyone already working on a draft to discuss? Otherwise, I could take a shot to have something ready closer to 87 which picks up the major points from prior discussions. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias at fiebig.nl From Brian.Storey at gamma.co.uk Thu Sep 14 14:07:10 2023 From: Brian.Storey at gamma.co.uk (Brian Storey) Date: Thu, 14 Sep 2023 12:07:10 +0000 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> Message-ID: Hi Tore, I'm conscious you've gone to a great deal of effort to respond back to me promptly and I've not come back to you sooner. Sorry to keep you waiting for at least an acknowledgement. Firstly, thank you for taking us through this example. I can see yourself and Dennis have developed this converdation further. Rather than tread on that, I'll perhaps offer a slightly different spin on this which is neither in support or against your proposal, but in respect to how a LIR is supposed to determine what they should or shouldn't do. I'll be honest and say that I'm a relative newcomer to this having taken on the adminsitrative responisbility and compliance here less than 12 months ago. Whilst there is a degree of "This is the way" (from an internal & external perspective) with what I or anyone else takes on, I did want to audit and review as many aspects of what we should be doing as per policies, terms and conditions, RIPE DB Training, assumed best practice etc. What is apparent to me is that whilst a policy may describe a "must", it isn't nessecarily prescriptive on the "how" and is sufficiently narrow leaving how the end result is achieved. Certaintly I don't think this how the policies are intended to be written but there are some leaps you need to make as to what you should perhaps do or not do. A policy alone, in the case of RIPE-733 is a good example of this, in particular when you also consider clause 3.0 bullet 4. I know this isn't a unique problem but:- - Within quick succession I had two end business customers reach out to us to remove their business name from the description of the relevant INET ASSIGNED PA entry. Reasons cited were security. Whilst I looked at what we could possibly do, on balance we determined that it wasn't an option because of policy, other obligations and objectives. To also help support this view, we could see other LIRs providing service for the same end business who have taken the same approach as us, so at least we are collectively consistent! - On the other side, there was another new end business reaching out asking why the assignment with their details hadn't been published yet! Clearly two competing interests! Where does this lead me? Well, clearly we want administrative simplicity. Not only that, a clear way to explain internally and externally downstream to end customers but also up to RIPE NCC why we do it the way we do. Referencing clear policies is important to help justify why we take a certain approach and explain any limitations we may have. With the proposal you have presented, whilst I understand the rationale of it, I'm not quite seeing how without some of the discussion being had here, someone can read it and proceed as intended or take our explanation / interpretation of our obligations and apply them consistently. I recognise the latter part is part of the challenge now and a goal to be addressed. The path of least resistance starts to become very attractive! Perhaps I'm going down a rabbit hole with this. Ultimately I'm looking to make sure I understand how to remain on the right side of things! ?. With regard to AGGREGATED-BY-LIR and its existence with IPV6; yes, it's something which drew some interest when I first started and the different approaches. Feels like there is a bit more subtly to this though. Many thanks, Brian -----Original Message----- From: Tore Anderson Sent: Tuesday, September 12, 2023 7:52 AM To: Brian Storey ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Hi Brian, * Brian Storey > Thanks for explaining this particular use case. > > Reading the proposed New Policy Text, it provides the LIR with an > adminsitrative choice. Whilst I understand this choice, the rantionale > behind the proposal is to find a reasonable way to fill the gap for > the Provider Allocations not registered for the specific exception > documented: "IP addresses used solely for the connection of an End > User to a service provider... can be registered as part of the service > provider's internal infrastructure". > > Given the choice provided in the proposal, it seems to me like I could > go the other way with this and aggregate everything? The end user > allocation size distinction no longer looks to apply and I could > interprete that the "purpose" of the whole aggregate is consistent > (they are all used to reach "stuff") and therefore chose to not > register any end user assigned /29s, 28s, /27s etc. It depends on whether or not all your assignments are completely uniform (apart from the prefix value and length). If they are, you will be able to aggregate them. This means that they need to share a single common point of contact, which is often the case for assignments associated with fully managed Internet services provided to private individuals and small businesses. Such assignments would be possible to aggregate. If on the other hand they are not uniform (for example if your customers operate their own NOCs and therefore have different contact information), you will not be able to aggregate them. I will try to explain by example here as well. Let's say you currently have two customer assignments as follows: Customer 1: inetnum: 192.0.2.0 - 192.0.2.128 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: BRIAN-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE Customer 2: inetnum: 192.0.2.128 - 192.0.2.192 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: BRIAN-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE As you can see, except for the 'inetnum' value, they are completely identical. That means you will be able aggregate them into a single object: inetnum: 192.0.2.0 - 192.0.2.192 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: BRIAN-RIPE status: AGGREGATED-BY-LIR mnt-by: BRIAN-MNT source: RIPE The second example concerns the case where the assignments are not uniform. Let's say your customers operate their own NOCs, so your starting point instead is having these two assignments: Customer 1: inetnum: 192.0.2.0 - 192.0.2.128 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: CUST1-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE Customer 2: inetnum: 192.0.2.128 - 192.0.2.192 netname: BRIAN-ISP country: GB admin-c: BRIAN-RIPE tech-c: CUST2-RIPE status: ASSIGNED PA mnt-by: BRIAN-MNT source: RIPE Note how the 'tech-c' attribute differs between the two assignments. That means that not be able to replace them with an AGGREGATED-BY-LIR object. > Does this not contradict other purposes / objectives of the registry, > including the principles of registering public networks or am I > missing something? We do not believe so. As demonstrated above, only highly redundant data can be aggregated, so very little actual information lost in the process. Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel idea, it has been around in the IPv6 policy for many many years. If it was indeed the case that it contradicted the purposes and/or objectives of the registry, someone ought to have noticed and attempted to fix that problem by now. That has not happened, as far as we know, which we take as a sign that there is no such problem in the first place. Tore -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4577 bytes Desc: not available URL: From adallara at ripe.net Thu Sep 14 14:20:22 2023 From: adallara at ripe.net (Angela Dall'Ara) Date: Thu, 14 Sep 2023 14:20:22 +0200 Subject: [address-policy-wg] 2023-01 Policy Proposal Accepted and Implemented (Reducing IXP IPv4 assignment default size to a /26) Message-ID: <962c587a-903a-3a45-a08a-a6a7cf1bc651@ripe.net> Dear colleagues, Consensus has been reached on 2023-01 ?Reducing IXP IPv4 assignment default size to a /26?. This proposal modifies in the IPv4 Policy the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the assignments previously issued for the IXP peering LAN. The archived policy proposal can be found at: https://www.ripe.net/participate/policies/proposals/2023-01 The new RIPE Document, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is available at: https://www.ripe.net/publications/docs/ripe-804 This proposal is implemented with immediate effect. Thank you to everyone who provided input. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC From tore at fud.no Thu Sep 14 15:30:30 2023 From: tore at fud.no (Tore Anderson) Date: Thu, 14 Sep 2023 15:30:30 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> Message-ID: <769af6d0ca6d7f5fa54d95fb5cd4b2635a468c6b.camel@fud.no> Hi again Brian, * Brian Storey > I'm conscious you've gone to a great deal of effort to respond back > to me promptly and I've not come back to you sooner. Sorry to keep > you waiting for at least an acknowledgement. > > Firstly, thank you for taking us through this example. I can see > yourself and Dennis have developed this converdation further. > > Rather than tread on that, I'll perhaps offer a slightly different > spin on this which is neither in support or against your proposal, > but in respect to how a LIR is supposed to determine what they should > or shouldn't do. I'll be honest and say that I'm a relative newcomer > to this having taken on the adminsitrative responisbility and > compliance here less than 12 months ago. > > Whilst there is a degree of "This is the way" (from an internal & > external perspective) with what I or anyone else takes on, I did want > to audit and review as many aspects of what we should be doing as per > policies, terms and conditions, RIPE DB Training, assumed best > practice etc. > > What is apparent to me is that whilst a policy may describe a "must", > it isn't nessecarily prescriptive on the "how" and is sufficiently > narrow leaving how the end result is achieved. Certaintly I don't > think this how the policies are intended to be written but there are > some leaps you need to make as to what you should perhaps do or not > do. A policy alone, in the case of RIPE-733 is a good example of > this, in particular when you also consider clause 3.0 bullet 4. > > I know this isn't a unique problem but:- > ????????- Within quick succession I had two end business customers > reach out to us to remove their business name from the description of > the relevant INET ASSIGNED PA entry. Reasons cited were security. > Whilst I looked at what we could possibly do, on balance we > determined that it wasn't an option because of policy, other > obligations and objectives. To also help support this view, we could > see other LIRs providing service for the same end business who have > taken the same approach as us, so at least we are collectively > consistent! > ????????- On the other side, there was another new end business > reaching out asking why the assignment with their details hadn't been > published yet! > > Clearly two competing interests! > > Where does this lead me? > > Well, clearly we want administrative simplicity. Not only that, a > clear way to explain internally and externally downstream to end > customers but also up to RIPE NCC why we do it the way we do. > Referencing clear policies is important to help justify why we take a > certain approach and explain any limitations we may have. With the > proposal you have presented, whilst I understand the rationale of it, > I'm not quite seeing how without some of the discussion being had > here, someone can read it and proceed as intended or take our > explanation / interpretation of our obligations and apply them > consistently. I recognise the latter part is part of the challenge > now and a goal to be addressed. The path of least resistance starts > to become very attractive! > > Perhaps I'm going down a rabbit hole with this. Ultimately I'm > looking to make sure I understand how to remain on the right side of > things! ?. > > With regard to AGGREGATED-BY-LIR and its existence with IPV6; yes, > it's something which drew some interest when I first started and the > different approaches. Feels like there is a bit more subtly to this > though. You bring up an interesting debate here. Different LIRs have different policies when it comes to how much and what kind of information should be injected into the RIPE database, and as you point out, even end users might have different expectations here. The actual requirements of the policy is quite clear though - it is mandatory to register all assignments, and it is mandatory to register the end user's contact information (the admin-c and tech-c attributes). ? However, often the LIR/ISP itself will assume the admin-c/tech-c role on behalf of the end user (who might not be very tech-savvy and would therefore prefer to "outsource" this role to the LIR in this manner), so it is actually not mandatory to identify the assignee by name. Additionally, the RIPE database inetnum template makes it mandatory to include one or more country attributes. Other than these mandatory minimums, each individual LIR is free to set its own policies on which additional information to publish, if any. The sky's the limit here - there are not one, but two free-text attributes (descr and remarks), so anything goes! For the record, the full inetnum template can be seen here: https://apps.db.ripe.net/db-web-ui/query?bflag=false&dflag=false&rflag=true&searchtext=-t%20inetnum&source=RIPE Coming back to our 2023-04 proposal, we would like to make it clear that it does not take a position in this larger debate you bring up. 2023-04 does not take away the ability of any LIR to publish any kind of optional information they would like to, nor does it relax the mandatory minimums described above. That is: anything that is currently OK, will be OK after the implementation of 2023-04 too. No LIR will be forced to change their current policies to register AGGREGATED-BY-LIR objects instead of what it is that they are currently doing. Instead, we recognise the current policy for what it is, and see that it in some situations requires LIRs to register large numbers of small and essentially identical objects in the database. We see these as both pointless and labour-intensive to maintain, so our aim is to provide an optional mechanism that can ease this work load significantly. Since the IPv6 policy have for a long time contained a tried'n'true mechanism that does just that, we believe the easiest way is to copy that into IPv4. Tore From jordi.palet at consulintel.es Thu Sep 14 15:42:20 2023 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 14 Sep 2023 22:42:20 +0900 Subject: [address-policy-wg] Status IPv6 Policy Draft In-Reply-To: <26c6b281e56655841fd6dc3201ac09a9869ba098.camel@fiebig.nl> References: <26c6b281e56655841fd6dc3201ac09a9869ba098.camel@fiebig.nl> Message-ID: Hi Tobias, all, I?ve already worked on that, considering a previous proposal which submitted to the chairs around May 2022 (if I recall correctly), but they didn?t accepted because they said the discussion need to happen first. Been too busy the last few months, so was not able to move on. What I?m missing now is to review all the minutes of the discussions that we got, to make sure that I?m not missing anything and also look if other folks want to join the proposal, review among us, etc. I?m this week in the APNIC meeting in Japan and will be able to tackle this next week. If you want to join (also open to others of course), let me know in private - preferred to the actual email jordi.palet at theipv6company.coml, as I only use this one for keeping subscriptions to mailing lists) Regards, Jordi @jordipalet > El 14 sept 2023, a las 19:28, Tobias Fiebig via address-policy-wg escribi?: > > Heho, > i am currently scrolling over my inbox, and was wondering what the > status of the v6 policy draft is (with 87 coming up). > > Is anyone already working on a draft to discuss? > > Otherwise, I could take a shot to have something ready closer to 87 > which picks up the major points from prior discussions. > > With best regards, > Tobias > -- > Dr.-Ing. Tobias Fiebig > T +31 616 80 98 99 > M tobias at fiebig.nl > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ ********************************************** 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 leo at vegoda.org Mon Sep 18 15:25:10 2023 From: leo at vegoda.org (Leo Vegoda) Date: Mon, 18 Sep 2023 06:25:10 -0700 Subject: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down Message-ID: Dear WG, You will have seen the recent announcement that James Kennedy has joined the RIPE NCC as Chief Registry Officer. He's stepping down from his community leadership roles, including as co-chair of the Address Policy WG. Because we still have two co-chairs there is no immediate need to recruit a replacement. Instead, we'd like to encourage anyone considering joining the team to contact us to discuss what is involved. You can write to us and we can schedule a call. You can also approach us at RIPE 87 in Rome. Kind regards, Leo & Erik Address Policy WG Co-Chairs From ripedenis at gmail.com Fri Sep 22 05:52:23 2023 From: ripedenis at gmail.com (denis walker) Date: Fri, 22 Sep 2023 05:52:23 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: Hi Tore I will first answer your points in this email, now I've had more time to think about it. Then I plan to send two longer emails. One on the bigger picture and one specifically about your proposal text. It is disappointing that so many people just said "+1 great proposal". I think they have responded to the headline and not considered the details or the implications. So let's consider some of them... On Wed, 13 Sept 2023 at 08:59, Tore Anderson wrote: > > Hello Denis, > > Let me start off by clearing up a misunderstanding: > > My brief example did not mean to convey that non-uniform contact > information is the only thing that could make a set of objects non- > uniform and thus unsuitable for AGGREGATED-BY-LIR. > > Rather, the exact opposite was the intended meaning - which is that > almost any attribute can make a set of objects non-uniform. The tech-c > attribute was only used an example to demonstrate this. > > With that out of the way, my answers to your remaining points follow > in-line: > > * denis walker > > > Now let's look at a real life example. > > > > whois -rBm 195.238.192.0 - 195.238.223.255 > > > > The first thing to note is that the admin-c and tech-c values are the > > same in all the more specific assignments. Even the mnt-by is the > > same, although you make no mention if that is a blokker for > > aggregation or not. So by your definition these are 'completely > > uniform' objects and can be aggregated. > > As I clarified above, these objects are in my view *not* uniform, as > they have distinct netname, descr and country attributes (possibly > others I missed too, I only skimmed through them quickly). > > The LIR in question clearly has a policy of publishing the street > address of each assignee in the descr attribute. That is totally fine, > and will continue to be totally fine after 2023-04 is implemented, but > it makes their objects unsuitable for aggregation. This is where the implications get interesting. Each of the objects in the example I gave is in itself individually aggregatable. There is nothing in your policy proposal that says an aggregate must cover multiple assignments to multiple End Users. You say: "In case of an audit, the LIR must be able to present statistics showing the number of individual assignments made in all objects with a status of 'AGGREGATED-BY-LIR." So the number 1 is valid. You don't require the block size of the individual assignments to be specified in the audit. So that 1 could be the same size as the aggregate or a single IP address. For every one of the assignments in this example allocation you can change the status to AGGREGATED-BY-LIR and remove all the identification and contact information for the actual end user. Your proposal has dropped the requirement: "When an End User has a network using public address space this must be registered separately with the contact details of the End User." It is not specified in the current policy if those contact details must be the tech-c/admin-c or the address of the company. So the objects in my example comply with the current policy. With the current policy only when an End User is a natural person can you replace the contact details with that of the LIR. With your policy ANY or even ALL End Users can replace their contact details with that of the LIR by changing the status to AGGREGATED-BY-LIR. In theory every ASSIGNED PA object in the RIPE Database can become an AGGREGATED-BY-LIR object with only LIR contact details. Now that won't happen as a lot of responsible End Users will want their contact details in the database for network problem resolution. But we all know there are LIRs who provide services to spammers and other abusers, knowingly or otherwise. You can be sure these End Users' details will disappear from the database. > > > You will also note that all these objects contain optional descr > > attributes. These attributes contain name and address details of the > > end user. That is important information for many stakeholder groups > > using the RIPE Database public registry. That detail will be lost in > > an aggregation. Given that current policy requires these assignments > > to be registered in the public registry, many users do include this > > detail. Now we all know the RIPE Database design and technology is > > very old and it does currently require some effort to manage this > > data. (A problem that all users have noticed but no one has attempted > > to fix.) Given a 'short cut' option, human nature suggests people > > will use it, even if it is not the right thing to do for a public > > registry. So aggregating across the whole database, may result in a > > massive amount of detail being lost from the public registry. > > It is important to note that the information you mention as "important" > here - the assignee's address - is (as you rightly point out) optional > to include. An LIR is under no obligation to publish this information, > and the inetnum object does not even contain an attribute dedicated to > it. > > (While the organisation object has mandatory org-name and address > attributes, the org attribute is optional in inetnum objects.) > > Thus the LIR in question already has a 'short cut' option available to > them, should they feel managing the assignees' address information in > the RIPE database is too burdensome - they can simply chose to not > include that information in the first place. > > I want to emphasise that this policy proposal does not grant them this > option, it is already there today. This again is misleading. The LIR CANNOT do what you suggest with the current policy. The current policy says: "When an End User has a network using public address space this must be registered separately with the contact details of the End User." As I said above, It is not specified if those contact details must be the tech-c/admin-c or the address of the company. In the example I gave the admin-c/tech-c are the details of the LIR. But they comply with the policy by including the address of the companies. They are the End User contact details. If they chose to remove this optional information then they no longer comply with current policy. But you drop this policy condition. Therefore with your policy proposal you allow them to remove this optional info and still comply with the policy. Netname is just a string of LIR defined characters and does not need to be unique. So they can all be set to the same string. Country is also LIR defined and generally meaningless so they can all be set to the same pointless value. So your proposal allows this LIR to make all these assignments 'the same' and replace them all with a single AGGREGATED-BY-LIR object. This is a very significant change to the public registry. With this proposal ANY set of data can be anonymised. There is no longer any requirement for End Users running public networks to be identifiable or contactable. This IS an option granted by this proposal that is NOT there today. I can see a follow up question to the DB-WG, "How do I aggregate a whole allocation?" Which may well replace the current question, "How do I assign a whole allocation?" The consequence of this proposal is the same as a previous suggestion to make assignments optional. Both allow for the mass anonymisation of End Users. > > > Also note that there are gaps in the more specific assignments for > > this allocation. For example 195.238.193.224 - 195.238.193.255 is not > > assigned. Can your aggregated objects span these gaps? If so then we > > lose sight of what address space is in use or available. It may no > > longer be needed for further allocations but people do still use that > > information. > > Yes, just as in IPv6, aggregated objects can span gaps. This is > essential, as the primary use case targeted by AGGREGATED-BY-LIR is > automated assignment pools with a high churn rate (e.g., a dynamic DHCP > pool). This may be your specified primary use case, but it can then be extended to the entire database. > > In such environments, the .1, .2 and .3 addresses might be assigned > before .2 might get de-assigned again - all within seconds, with no > operator involvement. We believe it is not necessary to reflect this > high level of granularity and rapid churn rate in the RIPE database. > > > The assignments are all randomly sized. Which is why you have dropped > > the inet6num assignment-size attribute for inetnum objects. So if I > > amgetting abuse from one specific IP address what should I do? I have > > noidea from the aggregated block what the block size is that includes > > this one IP address. Is there any other way to find this information, > > maybe from routing details? If not, should I block and blacklist the > > entire aggregated block? That could affect hundreds, maybe even > > thousands, of users in some cases. This is not a problem with IPv6 as > > you know the size of the block containing that address. > > My personal recommendation would be to block the specific IP address > you are receiving abusive traffic from and send a complaint to the > abuse-c for the inetnum in question. Are you suggesting that abusers generally work with single IP addresses, rather than cycling through a block of addresses? > > Note that this is not really much different than what you have to do > today for abuse coming from customer assignments that are ?registered > as part of the service provider's internal infrastructure?, cf. ripe- > 708 section 6.2. Just a note that ripe-708 was the address policy of 2018. There have been 5 updates since then. > That said, AGGREGATED-BY-LIR would here have made it > clear that the abusive address is indeed assigned to a downstream > customer and is not part of the service provider's internal > infrastructure. Take a look at these two examples of real data: 82.116.118.0 - 82.116.119.255 88.149.40.0 - 88.149.40.255 One is listed in a remarks as "dynamic DSL address pool" and the other as "DHCP Customers". They are already aggregated. What do we gain by changing the status on these objects from ASSIGNED PA to AGGREGATED-BY-LIR? Suppose one LIR changes the status and the other does not. As you said it is optional. Nothing changes for either LIR in terms of what they must create, modify or delete in the database. They are already aggregates. What can a casual viewer of this data in the database deduce from these two new objects with different status values? Without parsing the remarks they cannot deduce anything. Either could be a single End User or multiple End Users. The status doesn't distinguish either option. Why do we need a new status value? We end up with two values that are completely interchangeable with no way to interpret their different meanings without parsing remarks. The bottom line is that this new status value adds no new benefit, but can be seriously mis-used to cause considerable damage to the RIPE Database as a public registry. It WILL be misused by those operating public networks who wish to keep their details hidden from public view. cheers denis co-chair DB-WG > > Tore From jlauwers at a2b-internet.com Fri Sep 22 09:45:41 2023 From: jlauwers at a2b-internet.com (Jeroen Lauwers) Date: Fri, 22 Sep 2023 07:45:41 +0000 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: <24EEA0CA-297E-4B9C-AB05-F8B2DCA0DF95@a2b-internet.com> Hi Dennis, It is good that you look carefully at the effects of the policy proposal, especially for abusing matters by end users. I only miss the complete pictures for this point. In the hypothetical case l as a LIR would like to help spammers I could use 6.2 as a valid reason for not registering the contact details of the end user. Second I could change quickly the IPs of the spammer and then update this quickly enough in the DB that still no one would be able to get any info. Because before the moment people have time to check the DB the information would be already gone. So as LIR I would be fully complying with the rules of the address policy and still be able to help spammers. And then we not even talking about if abusers would even try to write the proper contact information or privacy laws like GDPR. In a lot of cases, it would be good to have end-user information but I don?t think we can solely trust on the idea that if we can contact end users a problem would be solved. In my experience, even with technical problems most end users won't have enough skills to solve problems by themself. So imagine than a case where the end user is on purpose abusing the IP space. In the end, it is the LIR's responsibility who is using the IP addresses that are assigned to this LIR. So I think in case of that a LIR is accidental or on purpose accommodating a spammer it is more efficient to focus on the LIR than the end user for stopping the abusing end user. We hope that with this proposal more IP space will be covered in the database by making it easier to comply with the rules and give fewer LIRs the overwhelming feeling of repetitive tasks. At the moment the IP space without any child assignment in the database is growing every year. And I think we both agree that how more space is covered in the DB the better it is for the community. Kind regards, Jeroen Op 22 sep. 2023, om 05:52 heeft denis walker > het volgende geschreven: Hi Tore I will first answer your points in this email, now I've had more time to think about it. Then I plan to send two longer emails. One on the bigger picture and one specifically about your proposal text. It is disappointing that so many people just said "+1 great proposal". I think they have responded to the headline and not considered the details or the implications. So let's consider some of them... On Wed, 13 Sept 2023 at 08:59, Tore Anderson > wrote: Hello Denis, Let me start off by clearing up a misunderstanding: My brief example did not mean to convey that non-uniform contact information is the only thing that could make a set of objects non- uniform and thus unsuitable for AGGREGATED-BY-LIR. Rather, the exact opposite was the intended meaning - which is that almost any attribute can make a set of objects non-uniform. The tech-c attribute was only used an example to demonstrate this. With that out of the way, my answers to your remaining points follow in-line: * denis walker Now let's look at a real life example. whois -rBm 195.238.192.0 - 195.238.223.255 The first thing to note is that the admin-c and tech-c values are the same in all the more specific assignments. Even the mnt-by is the same, although you make no mention if that is a blokker for aggregation or not. So by your definition these are 'completely uniform' objects and can be aggregated. As I clarified above, these objects are in my view *not* uniform, as they have distinct netname, descr and country attributes (possibly others I missed too, I only skimmed through them quickly). The LIR in question clearly has a policy of publishing the street address of each assignee in the descr attribute. That is totally fine, and will continue to be totally fine after 2023-04 is implemented, but it makes their objects unsuitable for aggregation. This is where the implications get interesting. Each of the objects in the example I gave is in itself individually aggregatable. There is nothing in your policy proposal that says an aggregate must cover multiple assignments to multiple End Users. You say: "In case of an audit, the LIR must be able to present statistics showing the number of individual assignments made in all objects with a status of 'AGGREGATED-BY-LIR." So the number 1 is valid. You don't require the block size of the individual assignments to be specified in the audit. So that 1 could be the same size as the aggregate or a single IP address. For every one of the assignments in this example allocation you can change the status to AGGREGATED-BY-LIR and remove all the identification and contact information for the actual end user. Your proposal has dropped the requirement: "When an End User has a network using public address space this must be registered separately with the contact details of the End User." It is not specified in the current policy if those contact details must be the tech-c/admin-c or the address of the company. So the objects in my example comply with the current policy. With the current policy only when an End User is a natural person can you replace the contact details with that of the LIR. With your policy ANY or even ALL End Users can replace their contact details with that of the LIR by changing the status to AGGREGATED-BY-LIR. In theory every ASSIGNED PA object in the RIPE Database can become an AGGREGATED-BY-LIR object with only LIR contact details. Now that won't happen as a lot of responsible End Users will want their contact details in the database for network problem resolution. But we all know there are LIRs who provide services to spammers and other abusers, knowingly or otherwise. You can be sure these End Users' details will disappear from the database. You will also note that all these objects contain optional descr attributes. These attributes contain name and address details of the end user. That is important information for many stakeholder groups using the RIPE Database public registry. That detail will be lost in an aggregation. Given that current policy requires these assignments to be registered in the public registry, many users do include this detail. Now we all know the RIPE Database design and technology is very old and it does currently require some effort to manage this data. (A problem that all users have noticed but no one has attempted to fix.) Given a 'short cut' option, human nature suggests people will use it, even if it is not the right thing to do for a public registry. So aggregating across the whole database, may result in a massive amount of detail being lost from the public registry. It is important to note that the information you mention as "important" here - the assignee's address - is (as you rightly point out) optional to include. An LIR is under no obligation to publish this information, and the inetnum object does not even contain an attribute dedicated to it. (While the organisation object has mandatory org-name and address attributes, the org attribute is optional in inetnum objects.) Thus the LIR in question already has a 'short cut' option available to them, should they feel managing the assignees' address information in the RIPE database is too burdensome - they can simply chose to not include that information in the first place. I want to emphasise that this policy proposal does not grant them this option, it is already there today. This again is misleading. The LIR CANNOT do what you suggest with the current policy. The current policy says: "When an End User has a network using public address space this must be registered separately with the contact details of the End User." As I said above, It is not specified if those contact details must be the tech-c/admin-c or the address of the company. In the example I gave the admin-c/tech-c are the details of the LIR. But they comply with the policy by including the address of the companies. They are the End User contact details. If they chose to remove this optional information then they no longer comply with current policy. But you drop this policy condition. Therefore with your policy proposal you allow them to remove this optional info and still comply with the policy. Netname is just a string of LIR defined characters and does not need to be unique. So they can all be set to the same string. Country is also LIR defined and generally meaningless so they can all be set to the same pointless value. So your proposal allows this LIR to make all these assignments 'the same' and replace them all with a single AGGREGATED-BY-LIR object. This is a very significant change to the public registry. With this proposal ANY set of data can be anonymised. There is no longer any requirement for End Users running public networks to be identifiable or contactable. This IS an option granted by this proposal that is NOT there today. I can see a follow up question to the DB-WG, "How do I aggregate a whole allocation?" Which may well replace the current question, "How do I assign a whole allocation?" The consequence of this proposal is the same as a previous suggestion to make assignments optional. Both allow for the mass anonymisation of End Users. Also note that there are gaps in the more specific assignments for this allocation. For example 195.238.193.224 - 195.238.193.255 is not assigned. Can your aggregated objects span these gaps? If so then we lose sight of what address space is in use or available. It may no longer be needed for further allocations but people do still use that information. Yes, just as in IPv6, aggregated objects can span gaps. This is essential, as the primary use case targeted by AGGREGATED-BY-LIR is automated assignment pools with a high churn rate (e.g., a dynamic DHCP pool). This may be your specified primary use case, but it can then be extended to the entire database. In such environments, the .1, .2 and .3 addresses might be assigned before .2 might get de-assigned again - all within seconds, with no operator involvement. We believe it is not necessary to reflect this high level of granularity and rapid churn rate in the RIPE database. The assignments are all randomly sized. Which is why you have dropped the inet6num assignment-size attribute for inetnum objects. So if I amgetting abuse from one specific IP address what should I do? I have noidea from the aggregated block what the block size is that includes this one IP address. Is there any other way to find this information, maybe from routing details? If not, should I block and blacklist the entire aggregated block? That could affect hundreds, maybe even thousands, of users in some cases. This is not a problem with IPv6 as you know the size of the block containing that address. My personal recommendation would be to block the specific IP address you are receiving abusive traffic from and send a complaint to the abuse-c for the inetnum in question. Are you suggesting that abusers generally work with single IP addresses, rather than cycling through a block of addresses? Note that this is not really much different than what you have to do today for abuse coming from customer assignments that are ?registered as part of the service provider's internal infrastructure?, cf. ripe- 708 section 6.2. Just a note that ripe-708 was the address policy of 2018. There have been 5 updates since then. That said, AGGREGATED-BY-LIR would here have made it clear that the abusive address is indeed assigned to a downstream customer and is not part of the service provider's internal infrastructure. Take a look at these two examples of real data: 82.116.118.0 - 82.116.119.255 88.149.40.0 - 88.149.40.255 One is listed in a remarks as "dynamic DSL address pool" and the other as "DHCP Customers". They are already aggregated. What do we gain by changing the status on these objects from ASSIGNED PA to AGGREGATED-BY-LIR? Suppose one LIR changes the status and the other does not. As you said it is optional. Nothing changes for either LIR in terms of what they must create, modify or delete in the database. They are already aggregates. What can a casual viewer of this data in the database deduce from these two new objects with different status values? Without parsing the remarks they cannot deduce anything. Either could be a single End User or multiple End Users. The status doesn't distinguish either option. Why do we need a new status value? We end up with two values that are completely interchangeable with no way to interpret their different meanings without parsing remarks. The bottom line is that this new status value adds no new benefit, but can be seriously mis-used to cause considerable damage to the RIPE Database as a public registry. It WILL be misused by those operating public networks who wish to keep their details hidden from public view. cheers denis co-chair DB-WG Tore -- 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 tore at fud.no Fri Sep 22 10:56:30 2023 From: tore at fud.no (Tore Anderson) Date: Fri, 22 Sep 2023 10:56:30 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: Hi Denis, > This is where the implications get interesting. Each of the objects > in the example I gave is in itself individually aggregatable. There > is nothing in your policy proposal that says an aggregate must cover > multiple assignments to multiple End Users. You say: > "In case of an audit, the LIR must be able to present statistics > showing the number of individual assignments made in all objects with > a status of 'AGGREGATED-BY-LIR." Yes, this requirement is copied verbatim from the IPv6 policy. > So the number 1 is valid. You don't require the block size of the > individual assignments to be specified in the audit. So that 1 could > be the same size as the aggregate or a single IP address. Correct, just as in the IPv6 policy. Though I fail to see the point in "aggregating" only a single assignment. > For every one of the assignments in this example allocation you can > change the status to AGGREGATED-BY-LIR and remove all the > identification and contact information for the actual end user. Your > proposal has dropped the requirement: > "When an End User has a network using public address space this must > be registered separately with the contact details of the End User." Correct, as we are copying the wording from the IPv6 policy, which does not contain that specific sentence. > It is not specified in the current policy if those contact details > must be the tech-c/admin-c or the address of the company. So the > objects in my example comply with the current policy. We might have to agree to disagree on this one, but to me it seems clear that the mandatory contact details referred to by policy *are* admin-c and tech-c, nothing more, nothing less. This follows from the inetnum object template, where admin-c/tech-c are the only mandatory attributes that relates to contact information. In your examples, the LIR included street addresses of the assignees in the unstructured descr fields. This is essentially useless for trying to get in touch with someone about solving operational problems - I mean, when was the last time you physically travelled to someone's office or sent them snailmail in order to troubleshoot a network issue? When reading the requirement to register the End User's contact details with the goal of registration stated in section 3.0.4 of the policy in mind - ?to ensure uniqueness and **to provide information for Internet troubleshooting at all levels**? (emphasis mine) - it seems clear to me that the mandatory contact information referred to by policy must be more immediate and long-distance forms of contact, such as 'phone' in a person object or 'e-mail' from a role object. These are mandatory attributes, and can be used as tech-c/admin-c in inetnum objects, which are also mandatory. Thus, the registration goal and requirement in the policy and the chain of mandatory attributes in the RIPE database ties together very nicely in a structured, machine-readable and logical way: inet[6]num?tech/admin-c?person?phone, alternatively: inet[6]num?tech/admin-c?role?e-mail. > With the current policy only when an End User is a natural person can > you replace the contact details with that of the LIR. With your > policy ANY or even ALL End Users can replace their contact details > with that of the LIR by changing the status to AGGREGATED-BY-LIR. In > theory every ASSIGNED PA object in the RIPE Database can become an > AGGREGATED-BY-LIR object with only LIR contact details. Now that > won't happen as a lot of responsible End Users will want their > contact details in the database for network problem resolution. Well, it depends. Is the LIR' NOC the correct point of contact for network problem resolution, i.e., is there already a single value used for tech-c and admin-c across a set of adjacent assignments? If yes, then the LIR could aggregate those objects. If no, e.g., if the End Users operate their own NOCs, then those objects can not be aggregated. This is of course all the same as in the IPv6 policy today. > But we all know there are LIRs who provide services to spammers and > othe abusers, knowingly or otherwise. You can be sure these End > Users' details will disappear from the database. Are you certain that updated and working contact information of spammers and abusers are correctly registered in the RIPE database today? (Rhetorical question, no answer sought.) > > Thus the LIR in question already has a 'short cut' option available > > to them, should they feel managing the assignees' address > > information in the RIPE database is too burdensome - they can > > simply chose to not include that information in the first place. > > > > I want to emphasise that this policy proposal does not grant them > > this option, it is already there today. > > This again is misleading. The LIR CANNOT do what you suggest with the > current policy. The current policy says: > "When an End User has a network using public address space this must > be registered separately with the contact details of the End User." > As I said above, It is not specified if those contact details must be > the tech-c/admin-c or the address of the company. In the example I > gave the admin-c/tech-c are the details of the LIR. But they comply > with the policy by including the address of the companies. They are > the End User contact details. If they chose to remove this optional > information then they no longer comply with current policy. But you > drop this policy condition. Therefore with your policy proposal you > allow them to remove this optional info and still comply with the > policy. Netname is just a string of LIR defined characters and does > not need to be unique. So they can all be set to the same string. > Country is also LIR defined and generally meaningless so they can all > be set to the same pointless value. So your proposal allows this LIR > to make all these assignments 'the same' and replace them all with a > single AGGREGATED-BY-LIR object. This is a very significant change to > the public registry. With this proposal ANY set of data can be > anonymised. There is no longer any requirement for End Users running > public networks to be identifiable or contactable. > > This IS an option granted by this proposal that is NOT there today. Here are three randomly selected assignments that demonstrates how this option is there today: inetnum: 213.174.234.0 - 213.174.234.31 inetnum: 62.213.192.208 - 62.213.192.223 inetnum: 213.162.203.0 - 213.162.203.255 All of them have netnames ? la ?LIRNAME-CUSTOMER-NUMBER-1234?, strongly suggesting this is a downstream assignment to a specific customer and not made to the LIRs own infrastructure or DHCP pools, and the only thing resembling contact information are the admin-c and tech-c attributes, which refer to the LIR itself. > I can see a follow up question to the DB-WG, "How do I aggregate a > whole allocation?" Which may well replace the current question, "How > do I assign a whole allocation?" The consequence of this proposal is > the same as a previous suggestion to make assignments optional. Both > allow for the mass anonymisation of End Users. This possibility, as demonstrated above, is already there today - both in the IPv4 and IPv6 policies. > Are you suggesting that abusers generally work with single IP > addresses, rather than cycling through a block of addresses? Not really, but I would rather suggest that spammers and abusers are not likely to faithfully and correctly publish their assignments and contact information in the RIPE database in the first place. If you are building your anti-spam/abuse methodology on the assumption that otherwise bad actors are behaving as good actors when it comes to maintaining the RIPE database, I don't think that methodology would work very well. >From the proposal: ?As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs?. What do you do, exactly, if you start receiving abusive traffic from any of these ranges? > > Note that this is not really much different than what you have to > > do today for abuse coming from customer assignments that are > > ?registered as part of the service provider's internal > > infrastructure?, cf. ripe-708 section 6.2. > > Just a note that ripe-708 was the address policy of 2018. There have > been 5 updates since then. My mistake, a Google-snafu there. That particular sentence is unchanged as of ripe-804, though, so the points stands. > > That said, AGGREGATED-BY-LIR would here have made it > > clear that the abusive address is indeed assigned to a downstream > > customer and is not part of the service provider's internal > > infrastructure. > > Take a look at these two examples of real data: > 82.116.118.0 - 82.116.119.255 > 88.149.40.0 - 88.149.40.255 > > One is listed in a remarks as "dynamic DSL address pool" and the > other as "DHCP Customers". They are already aggregated. What do we > gain by changing the status on these objects from ASSIGNED PA to > AGGREGATED-BY-LIR? Suppose one LIR changes the status and the other > does not. As you said it is optional. Nothing changes for either LIR > in terms of what they must create, modify or delete in the database. > They are already aggregates. What can a casual viewer of this data in > the database deduce from these two new objects with different status > values? Without parsing the remarks they cannot deduce anything. > Either could be a single End User or multiple End Users. The status > doesn't distinguish either option. Why do we need a new status value? > We end up with two values that are completely interchangeable with no > way to interpret their different meanings without parsing remarks. If you are a machine, and not a human, free-text remarks such as "dynamic DSL address pool" are essentially meaningless. They are optional too, the LIRs could easily have omitted them. If they had, it would have impossible to tell whether those addresses had been assigned to one or more downstream customers or if they had been assigned to the LIR itself. Furthermore, there is a chance that at least one of the customers in those pools are using his or her assigned address for some purpose like running a MineCraft server, let's say. If, so, that single IP customer assignment is no longer ?used solely for the connection of an End User to a service provider? and would need to registered as a separate assignment. Everybody ignores that requirement, of course, because otherwise the result would have been complete and utter mayhem. Nevertheless, it is a de jure policy violation. AGGREGATED-BY-LIR solves that. > The bottom line is that this new status value adds no new benefit, > but can be seriously mis-used to cause considerable damage to the > RIPE Database as a public registry. It WILL be misused by those > operating public networks who wish to keep their details hidden from > public view. We do not propose to do anything that hasn't already been done in the IPv6 policy and database for years and years and years, and the sky has not fallen. The End Users that want anonymity for whatever reason have ample opportunity to remain anonymous today, even while staying policy compliant (not that bad actors would care about that). Finally, there *is* a benefit to this proposal, an actual itch we're trying to scratch, specifically where there are many identical small assignments being made and removed in a rapid and automated fashion, to End Users that don't operate their own NOCs. I've mentioned the cloud VPS provider example before here. Tore From ripedenis at gmail.com Sun Sep 24 18:12:29 2023 From: ripedenis at gmail.com (denis walker) Date: Sun, 24 Sep 2023 18:12:29 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <24EEA0CA-297E-4B9C-AB05-F8B2DCA0DF95@a2b-internet.com> References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> <24EEA0CA-297E-4B9C-AB05-F8B2DCA0DF95@a2b-internet.com> Message-ID: Hi Jeroen I only used abuse as one example. But as you have picked up on it I'll go with the flow. On Fri, 22 Sept 2023 at 09:45, Jeroen Lauwers wrote: > > Hi Dennis, > > It is good that you look carefully at the effects of the policy proposal, especially for abusing matters by end users. I only miss the complete pictures for this point. In the hypothetical case l as a LIR would like to help spammers I could use 6.2 as a valid reason for not registering the contact details of the end user. No you can't, unless they are a natural person (with contact details replaced in their assignment object with those of the LIR) or only have a single IP address (DSL customer). > Second I could change quickly the IPs of the spammer and then update this quickly enough in the DB that still no one would be able to get any info. Because before the moment people have time to check the DB the information would be already gone. So as LIR I would be fully complying with the rules of the address policy and still be able to help spammers. You might be able to change it faster than a human can read it, but not faster than a machine can process it. The information has not 'gone'. The database has a historical audit trail. Every change you make is logged. I am working on a proposal for a one time post processing of historical data. This will make much more information available from the data without violating privacy or GDPR. This will prevent LIRs from doing tricks like this to hide things. But it is interesting that you seem to think you can make quick changes to the database without too much effort, when it is something you want to do. But one of the cornerstones of your argument for this proposal is that it is too much effort to make quick changes, when it is something you don't want to do, like complying with policy. > And then we not even talking about if abusers would even try to write the proper contact information or privacy laws like GDPR. There are requirements for LIRs to enter correct information into the database. You know who the End Users are as they pay you for services. You have contracts with them. The information in assignment objects is entered by the LIRs not the End Users. > > In a lot of cases, it would be good to have end-user information but I don?t think we can solely trust on the idea that if we can contact end users a problem would be solved. In my experience, even with technical problems most end users won't have enough skills to solve problems by themself. Again you are assuming that the RIPE Database is nothing more than a phone book for operators to solve network problems. It is a public registry; it has evolved beyond a simple phone book for operators. > So imagine than a case where the end user is on purpose abusing the IP space. In the end, it is the LIR's responsibility who is using the IP addresses that are assigned to this LIR. So I think in case of that a LIR is accidental or on purpose accommodating a spammer it is more efficient to focus on the LIR than the end user for stopping the abusing end user. So as an LIR are you accepting responsibility (and liability) for abuse from one of your End Users? > > We hope that with this proposal more IP space will be covered in the database by making it easier to comply with the rules and give fewer LIRs the overwhelming feeling of repetitive tasks. You keep pushing this "overwhelming feeling of repetitive tasks" angle. Machines have been helping with these repetitive tasks since Charles Babbage developed his analytical engine almost 200 years ago. Most LIRs have engineers who understand computers. We are after all the people who manage the global internet. We are running a service used by the biggest tech companies in the world. So are you saying that in 2023 we can't manage a distributed database without overwhelming repetitive tasks? > At the moment the IP space without any child assignment in the database is growing every year. You can manipulate numbers to make any point you like. How many of these 'growing' allocations without assignments are /24 allocations? Not only has the RIPE NCC been making only /24 allocations for quite a few years, but people also buy /24 blocks on the open market which then get registered as allocations. The RIPE NCC /24 allocations were intended to be used by new LIRs who needed some IPv4 address space for their own infrastructure. So you would expect them to have no assignments. But that is not what happened with a lot of them. Many of these /24 allocations are now held by financial investors, managed by brokers and rented out to End Users, many of whom are other LIRs who may then even sub-assign them. None of this is represented in the RIPE Database as the old data model can't match new business models like this. There is nothing wrong with new business models. It is an inevitable consequence of monetizing IP addresses. But the RIPE Database needs to catch up. That is difficult because no one will talk about it. This proposal doesn't help with the bigger picture. You talk about LIRs sometimes being a better option to contact regarding address space usage. When the LIR/resource holder is a financial investor with no knowledge of IT, the broker renting out the space wants to keep a low profile, but they may be providing the LIR services, and the End User may also know nothing, then who do we talk to now in this new chain? > And I think we both agree that how more space is covered in the DB the better it is for the community. ALL address space is covered by allocations. Having lots of the more specific information hidden is not better for the community. Cheers denis co-chair DB-WG > > Kind regards, > > Jeroen > > > Op 22 sep. 2023, om 05:52 heeft denis walker het volgende geschreven: > > Hi Tore > > I will first answer your points in this email, now I've had more time > to think about it. Then I plan to send two longer emails. One on the > bigger picture and one specifically about your proposal text. It is > disappointing that so many people just said "+1 great proposal". I > think they have responded to the headline and not considered the > details or the implications. So let's consider some of them... > > On Wed, 13 Sept 2023 at 08:59, Tore Anderson wrote: > > > Hello Denis, > > Let me start off by clearing up a misunderstanding: > > My brief example did not mean to convey that non-uniform contact > information is the only thing that could make a set of objects non- > uniform and thus unsuitable for AGGREGATED-BY-LIR. > > Rather, the exact opposite was the intended meaning - which is that > almost any attribute can make a set of objects non-uniform. The tech-c > attribute was only used an example to demonstrate this. > > With that out of the way, my answers to your remaining points follow > in-line: > > * denis walker > > Now let's look at a real life example. > > whois -rBm 195.238.192.0 - 195.238.223.255 > > The first thing to note is that the admin-c and tech-c values are the > same in all the more specific assignments. Even the mnt-by is the > same, although you make no mention if that is a blokker for > aggregation or not. So by your definition these are 'completely > uniform' objects and can be aggregated. > > > As I clarified above, these objects are in my view *not* uniform, as > they have distinct netname, descr and country attributes (possibly > others I missed too, I only skimmed through them quickly). > > The LIR in question clearly has a policy of publishing the street > address of each assignee in the descr attribute. That is totally fine, > and will continue to be totally fine after 2023-04 is implemented, but > it makes their objects unsuitable for aggregation. > > > This is where the implications get interesting. Each of the objects in > the example I gave is in itself individually aggregatable. There is > nothing in your policy proposal that says an aggregate must cover > multiple assignments to multiple End Users. You say: > "In case of an audit, the LIR must be able to present statistics > showing the number of individual assignments made in all objects with > a status of 'AGGREGATED-BY-LIR." > So the number 1 is valid. You don't require the block size of the > individual assignments to be specified in the audit. So that 1 could > be the same size as the aggregate or a single IP address. > For every one of the assignments in this example allocation you can > change the status to AGGREGATED-BY-LIR and remove all the > identification and contact information for the actual end user. Your > proposal has dropped the requirement: > "When an End User has a network using public address space this must > be registered separately with the contact details of the End User." > It is not specified in the current policy if those contact details > must be the tech-c/admin-c or the address of the company. So the > objects in my example comply with the current policy. > With the current policy only when an End User is a natural person can > you replace the contact details with that of the LIR. With your policy > ANY or even ALL End Users can replace their contact details with that > of the LIR by changing the status to AGGREGATED-BY-LIR. In theory > every ASSIGNED PA object in the RIPE Database can become an > AGGREGATED-BY-LIR object with only LIR contact details. Now that won't > happen as a lot of responsible End Users will want their contact > details in the database for network problem resolution. But we all > know there are LIRs who provide services to spammers and other > abusers, knowingly or otherwise. You can be sure these End Users' > details will disappear from the database. > > > You will also note that all these objects contain optional descr > attributes. These attributes contain name and address details of the > end user. That is important information for many stakeholder groups > using the RIPE Database public registry. That detail will be lost in > an aggregation. Given that current policy requires these assignments > to be registered in the public registry, many users do include this > detail. Now we all know the RIPE Database design and technology is > very old and it does currently require some effort to manage this > data. (A problem that all users have noticed but no one has attempted > to fix.) Given a 'short cut' option, human nature suggests people > will use it, even if it is not the right thing to do for a public > registry. So aggregating across the whole database, may result in a > massive amount of detail being lost from the public registry. > > > It is important to note that the information you mention as "important" > here - the assignee's address - is (as you rightly point out) optional > to include. An LIR is under no obligation to publish this information, > and the inetnum object does not even contain an attribute dedicated to > it. > > (While the organisation object has mandatory org-name and address > attributes, the org attribute is optional in inetnum objects.) > > Thus the LIR in question already has a 'short cut' option available to > them, should they feel managing the assignees' address information in > the RIPE database is too burdensome - they can simply chose to not > include that information in the first place. > > I want to emphasise that this policy proposal does not grant them this > option, it is already there today. > > > This again is misleading. The LIR CANNOT do what you suggest with the > current policy. The current policy says: > "When an End User has a network using public address space this must > be registered separately with the contact details of the End User." As > I said above, It is not specified if those contact details must be the > tech-c/admin-c or the address of the company. In the example I gave > the admin-c/tech-c are the details of the LIR. But they comply with > the policy by including the address of the companies. They are the End > User contact details. If they chose to remove this optional > information then they no longer comply with current policy. But you > drop this policy condition. Therefore with your policy proposal you > allow them to remove this optional info and still comply with the > policy. Netname is just a string of LIR defined characters and does > not need to be unique. So they can all be set to the same string. > Country is also LIR defined and generally meaningless so they can all > be set to the same pointless value. So your proposal allows this LIR > to make all these assignments 'the same' and replace them all with a > single AGGREGATED-BY-LIR object. This is a very significant change to > the public registry. With this proposal ANY set of data can be > anonymised. There is no longer any requirement for End Users running > public networks to be identifiable or contactable. > > This IS an option granted by this proposal that is NOT there today. > > I can see a follow up question to the DB-WG, "How do I aggregate a > whole allocation?" Which may well replace the current question, "How > do I assign a whole allocation?" The consequence of this proposal is > the same as a previous suggestion to make assignments optional. Both > allow for the mass anonymisation of End Users. > > > Also note that there are gaps in the more specific assignments for > this allocation. For example 195.238.193.224 - 195.238.193.255 is not > assigned. Can your aggregated objects span these gaps? If so then we > lose sight of what address space is in use or available. It may no > longer be needed for further allocations but people do still use that > information. > > > Yes, just as in IPv6, aggregated objects can span gaps. This is > essential, as the primary use case targeted by AGGREGATED-BY-LIR is > automated assignment pools with a high churn rate (e.g., a dynamic DHCP > pool). > > > This may be your specified primary use case, but it can then be > extended to the entire database. > > > In such environments, the .1, .2 and .3 addresses might be assigned > before .2 might get de-assigned again - all within seconds, with no > operator involvement. We believe it is not necessary to reflect this > high level of granularity and rapid churn rate in the RIPE database. > > The assignments are all randomly sized. Which is why you have dropped > the inet6num assignment-size attribute for inetnum objects. So if I > amgetting abuse from one specific IP address what should I do? I have > noidea from the aggregated block what the block size is that includes > this one IP address. Is there any other way to find this information, > maybe from routing details? If not, should I block and blacklist the > entire aggregated block? That could affect hundreds, maybe even > thousands, of users in some cases. This is not a problem with IPv6 as > you know the size of the block containing that address. > > > My personal recommendation would be to block the specific IP address > you are receiving abusive traffic from and send a complaint to the > abuse-c for the inetnum in question. > > > Are you suggesting that abusers generally work with single IP > addresses, rather than cycling through a block of addresses? > > > Note that this is not really much different than what you have to do > today for abuse coming from customer assignments that are ?registered > as part of the service provider's internal infrastructure?, cf. ripe- > 708 section 6.2. > > > Just a note that ripe-708 was the address policy of 2018. There have > been 5 updates since then. > > That said, AGGREGATED-BY-LIR would here have made it > clear that the abusive address is indeed assigned to a downstream > customer and is not part of the service provider's internal > infrastructure. > > > Take a look at these two examples of real data: > 82.116.118.0 - 82.116.119.255 > 88.149.40.0 - 88.149.40.255 > > One is listed in a remarks as "dynamic DSL address pool" and the other > as "DHCP Customers". They are already aggregated. What do we gain by > changing the status on these objects from ASSIGNED PA to > AGGREGATED-BY-LIR? Suppose one LIR changes the status and the other > does not. As you said it is optional. Nothing changes for either LIR > in terms of what they must create, modify or delete in the database. > They are already aggregates. What can a casual viewer of this data in > the database deduce from these two new objects with different status > values? Without parsing the remarks they cannot deduce anything. > Either could be a single End User or multiple End Users. The status > doesn't distinguish either option. Why do we need a new status value? > We end up with two values that are completely interchangeable with no > way to interpret their different meanings without parsing remarks. > > The bottom line is that this new status value adds no new benefit, but > can be seriously mis-used to cause considerable damage to the RIPE > Database as a public registry. It WILL be misused by those operating > public networks who wish to keep their details hidden from public > view. > > cheers > denis > co-chair DB-WG > > > Tore > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ > > From ripedenis at gmail.com Mon Sep 25 09:26:32 2023 From: ripedenis at gmail.com (denis walker) Date: Mon, 25 Sep 2023 09:26:32 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: Hi Tore Sorry guys but this is a very long email. There is a lot at stake here. This policy proposal goes way beyond adding a new status value. It may seem to be only small changes to a couple of paragraphs. But these changes completely undermine the current IPv4 registration principles. You make lots of references to copying wording from the IPv6 policy. So let me point out one statement in ripe-690, the BCOP referenced in that policy. One of the first things it says in the Executive Summary is "IPv6 is not the same as IPv4." You are trying to suggest it is a simple task to retrofit IPv6 registration policy onto IPv4. It may not all be possible and even where it is, there may be significant consequences. You are glossing over some of these consequences. I am trying to highlight them. You are portraying this proposal as a simple addition of an optional construct that would simplify some operations. You are masking the fact that it removes one of the core principles of current IPv4 registration policy..registering of End User networks using public address space..which covers most of the internet. That removal can be applied to the whole dataset, in unpredictable ways, and radically change the public registry. Maybe some people believe it is the right change to make now. I don't claim to be an expert in this field. Personally I don't believe it is. But this is not something that should be decided by a handful of the small group of people who determine most policy in this region with a few "+1 great proposal" comments. A change of this magnitude needs wider consultation. Now I will answer your points below. On Fri, 22 Sept 2023 at 10:56, Tore Anderson wrote: > > Hi Denis, > > This is where the implications get interesting. Each of the objects > > in the example I gave is in itself individually aggregatable. There > > is nothing in your policy proposal that says an aggregate must cover > > multiple assignments to multiple End Users. You say: > > "In case of an audit, the LIR must be able to present statistics > > showing the number of individual assignments made in all objects with > > a status of 'AGGREGATED-BY-LIR." > > > Yes, this requirement is copied verbatim from the IPv6 policy. Which is also loosely written. It should not be permitted to aggregate a single assignment to a single End User. > > > So the number 1 is valid. You don't require the block size of the > > individual assignments to be specified in the audit. So that 1 could > > be the same size as the aggregate or a single IP address. > > > Correct, just as in the IPv6 policy. Though I fail to see the point in > "aggregating" only a single assignment. Actually you are right. By dropping the requirement to include End User contact details from the policy, you have allowed assignment objects to also be anonymised. So all identification and contact details for the end user, which may be in optional attributes, can be removed from the assignment object. Only if they operate their own NOC would you need to include any contacts for the End User. Some LIRs don't comply with current policy because they don't want to publish any details of their customers in a public registry. > > > Your proposal has dropped the requirement: > > "When an End User has a network using public address space this must > > be registered separately with the contact details of the End User." > > > Correct, as we are copying the wording from the IPv6 policy, which does > not contain that specific sentence. But the IPv6 policy also includes this: "When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED'." I don't see your equivalent of this copied from the IPv6 policy into your new IPv4 policy. Maybe more than a /24 might be an equivalent in IPv4 terms. You refer to 'that specific sentence' so casually, yet this is the main element of the current IPv4 assignment policy. Dropping this sentence is a major change to the assignment policy. This has far more consequences than just adding an optional construct. > > > It is not specified in the current policy if those contact details > > must be the tech-c/admin-c or the address of the company. So the > > objects in my example comply with the current policy. > > > We might have to agree to disagree on this one, but to me it seems > clear that the mandatory contact details referred to by policy *are* > admin-c and tech-c, nothing more, nothing less. This follows from the > inetnum object template, where admin-c/tech-c are the only mandatory > attributes that relates to contact information. You might want to disagree with me but on this one you are clearly wrong. Neither policy has any definitions of contacts. In fact I don't believe any policy or other RIPE document defines what a contact is. The IPv6 policy doesn't even mention the word 'contact' anywhere. So you cannot claim that a contact *is* related to some specific attribute(s). Especially some subset of attributes that *you* imagine it is referring to. What about abuse-c, zone-c, maintainers, notifications, remarks, descriptions. Is it a role or a person or some persons referenced from a role or referred to in a comment? There is nothing in the policy connecting a contact with any specific attribute, mandatory or optional. So the only thing you can reasonably deduce is that the term contact refers to what is generally accepted as a contact. A free text name and address is therefore a valid contact for the purposes of this policy. > > In your examples, the LIR included street addresses of the assignees in > the unstructured descr fields. This is essentially useless for trying > to get in touch with someone about solving operational problems - I > mean, when was the last time you physically travelled to someone's > office or sent them snailmail in order to troubleshoot a network issue? Yet again you are assuming this public registry held in the RIPE Database is nothing more than an operator's phone book for troubleshooting network problems. There are stakeholder groups who use the RIPE Database public registry for other purposes. > > When reading the requirement to register the End User's contact details > with the goal of registration stated in section 3.0.4 of the policy in > mind - ?to ensure uniqueness and **to provide information for Internet > troubleshooting at all levels**? (emphasis mine) - it seems clear to me > that the mandatory contact information referred to by policy must be > more immediate and long-distance forms of contact, such as 'phone' in a > person object or 'e-mail' from a role object. These are mandatory > attributes, and can be used as tech-c/admin-c in inetnum objects, which > are also mandatory. First of all the goals in the IPv4 policy are outdated and need revising. For example: "3.0.3 Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks." is no longer even possible with free market constraints. The term 'contact details' can include more than one contact. So the name and address can satisfy the condition for End User contact details and the tech-c can satisfy the goal of troubleshooting at all levels whether it is for the End User or LIR. > > Thus, the registration goal and requirement in the policy and the chain > of mandatory attributes in the RIPE database ties together very nicely > in a structured, machine-readable and logical way: > inet[6]num?tech/admin-c?person?phone, alternatively: > inet[6]num?tech/admin-c?role?e-mail. I would love the data in the RIPE Database to all be structured and machine readable. However the current data model is defined in a way that all data is human readable, unalterable, text blocks. Here you are making assumptions that are not defined and which coincidentally partially support your argument. Apart from the lack of definition of contacts, there is no reference or link to 'mandatory' attributes. You can use many combinations of mandatory and optional attributes that are either machine readable or human readable free text in person/role/inet(6)num objects in order to satisfy the policy registration requirements. > > > With the current policy only when an End User is a natural person can > > you replace the contact details with that of the LIR. With your > > policy ANY or even ALL End Users can replace their contact details > > with that of the LIR by changing the status to AGGREGATED-BY-LIR. In > > theory every ASSIGNED PA object in the RIPE Database can become an > > AGGREGATED-BY-LIR object with only LIR contact details. Now that > > won't happen as a lot of responsible End Users will want their > > contact details in the database for network problem resolution. > > > Well, it depends. Is the LIR' NOC the correct point of contact for > network problem resolution, i.e., is there already a single value used > for tech-c and admin-c across a set of adjacent assignments? > > If yes, then the LIR could aggregate those objects. > > If no, e.g., if the End Users operate their own NOCs, then those > objects can not be aggregated. > > This is of course all the same as in the IPv6 policy today. > > > But we all know there are LIRs who provide services to spammers and > > othe abusers, knowingly or otherwise. You can be sure these End > > Users' details will disappear from the database. > > > Are you certain that updated and working contact information of > spammers and abusers are correctly registered in the RIPE database > today? (Rhetorical question, no answer sought.) In the IPv4 policy Section 4.0 Registration Requirements it says: "Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." As this information in assignments is maintained by the LIR it is their responsibility to ensure it is correct. > > > > Thus the LIR in question already has a 'short cut' option available > > > to them, should they feel managing the assignees' address > > > information in the RIPE database is too burdensome - they can > > > simply chose to not include that information in the first place. > > > > > > I want to emphasise that this policy proposal does not grant them > > > this option, it is already there today. > > > > This again is misleading. The LIR CANNOT do what you suggest with the > > current policy. The current policy says: > > "When an End User has a network using public address space this must > > be registered separately with the contact details of the End User." > > As I said above, It is not specified if those contact details must be > > the tech-c/admin-c or the address of the company. In the example I > > gave the admin-c/tech-c are the details of the LIR. But they comply > > with the policy by including the address of the companies. They are > > the End User contact details. If they chose to remove this optional > > information then they no longer comply with current policy. But you > > drop this policy condition. Therefore with your policy proposal you > > allow them to remove this optional info and still comply with the > > policy. Netname is just a string of LIR defined characters and does > > not need to be unique. So they can all be set to the same string. > > Country is also LIR defined and generally meaningless so they can all > > be set to the same pointless value. So your proposal allows this LIR > > to make all these assignments 'the same' and replace them all with a > > single AGGREGATED-BY-LIR object. This is a very significant change to > > the public registry. With this proposal ANY set of data can be > > anonymised. There is no longer any requirement for End Users running > > public networks to be identifiable or contactable. > > > > This IS an option granted by this proposal that is NOT there today. > > > Here are three randomly selected assignments that demonstrates how this > option is there today: NO it is not there now. > > inetnum: 213.174.234.0 - 213.174.234.31 > inetnum: 62.213.192.208 - 62.213.192.223 > inetnum: 213.162.203.0 - 213.162.203.255 > > All of them have netnames ? la ?LIRNAME-CUSTOMER-NUMBER-1234?, strongly > suggesting this is a downstream assignment to a specific customer and > not made to the LIRs own infrastructure or DHCP pools, and the only > thing resembling contact information are the admin-c and tech-c > attributes, which refer to the LIR itself. The first and third example above may not comply with current policy. They do not include the contact details of the End Users. This is only valid if the End Users are natural persons and have replaced their contact details with that of the LIR. I think you are misunderstanding how the current policy works. Let's go back to that sentence you want to remove: "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users." Suppose an End User is a company who wants the LIR to manage the network for them. The tech-c and possibly the admin-c and also the abuse-c may all be set to the contacts for the LIR. Because they are not a natural person (individual) they don't qualify for the exception in the policy to substitute their contact details with those of the LIR. But all the '-c' contacts refer to the LIR. So they are not complying with policy. There are no contact details of the End User. To comply with the policy in these situations the LIR can include the name and address of the End User company in the optional descr attribute. This satisfies the policy condition of providing the contact details of the End User in the assignment object. Why do you think so many LIRs provide these optional details? They don't do it for fun. They do it to comply with the current policy. Your proposal allows them to dump all this optional information. They no longer need to provide contact details of the End User. This is an option your proposal provides that is not there now. Over time all these optional descr attributes with End User contact details will disappear. That would be a significant loss to the public registry. > > > I can see a follow up question to the DB-WG, "How do I aggregate a > > whole allocation?" Which may well replace the current question, "How > > do I assign a whole allocation?" The consequence of this proposal is > > the same as a previous suggestion to make assignments optional. Both > > allow for the mass anonymisation of End Users. > > > This possibility, as demonstrated above, is already there today - both > in the IPv4 and IPv6 policies. As I have demonstrated above, no it isn't there now in the IPv4 policy. > > > Are you suggesting that abusers generally work with single IP > > addresses, rather than cycling through a block of addresses? > > > Not really, but I would rather suggest that spammers and abusers are > not likely to faithfully and correctly publish their assignments and > contact information in the RIPE database in the first place. All this information is published in the RIPE Database by the LIRs who have a responsibility to ensure it is correct. > > If you are building your anti-spam/abuse methodology on the assumption > that otherwise bad actors are behaving as good actors when it comes to > maintaining the RIPE database, I don't think that methodology would > work very well. > > From the proposal: ?As of August 2023, there were 19,221 PA allocations > without any child PA assignments held by 10,052 LIRs?. What do you do, > exactly, if you start receiving abusive traffic from any of these > ranges? Block and blacklist the whole allocation if no more specific information is available. > > > > Note that this is not really much different than what you have to > > > do today for abuse coming from customer assignments that are > > > ?registered as part of the service provider's internal > > > infrastructure?, cf. ripe-708 section 6.2. Doesn't that suggest they are DSL customers with a single IP address? > > > > Just a note that ripe-708 was the address policy of 2018. There have > > been 5 updates since then. > > > My mistake, a Google-snafu there. That particular sentence is unchanged > as of ripe-804, though, so the points stands. > > > > That said, AGGREGATED-BY-LIR would here have made it > > > clear that the abusive address is indeed assigned to a downstream > > > customer and is not part of the service provider's internal > > > infrastructure. Assuming an LIR has chosen to use this new 'optional' status value. As many LIRs already have aggregated their DSL customers and tagged them as such in remarks attributes, why should they change it? > > > > Take a look at these two examples of real data: > > 82.116.118.0 - 82.116.119.255 > > 88.149.40.0 - 88.149.40.255 > > > > One is listed in a remarks as "dynamic DSL address pool" and the > > other as "DHCP Customers". They are already aggregated. What do we > > gain by changing the status on these objects from ASSIGNED PA to > > AGGREGATED-BY-LIR? Suppose one LIR changes the status and the other > > does not. As you said it is optional. Nothing changes for either LIR > > in terms of what they must create, modify or delete in the database. > > They are already aggregates. What can a casual viewer of this data in > > the database deduce from these two new objects with different status > > values? Without parsing the remarks they cannot deduce anything. > > Either could be a single End User or multiple End Users. The status > > doesn't distinguish either option. Why do we need a new status value? > > We end up with two values that are completely interchangeable with no > > way to interpret their different meanings without parsing remarks. > > > If you are a machine, and not a human, free-text remarks such as > "dynamic DSL address pool" are essentially meaningless. They are > optional too, the LIRs could easily have omitted them. If they had, it > would have impossible to tell whether those addresses had been assigned > to one or more downstream customers or if they had been assigned to the > LIR itself. If it has this new aggregated status you still don't know if it is a block of maybe 1000 DSL customers of a collection of randomly sized assignments to End Users. You still need the free text remarks to avoid confusion. > > Furthermore, there is a chance that at least one of the customers in > those pools are using his or her assigned address for some purpose like > running a MineCraft server, let's say. If, so, that single IP customer > assignment is no longer ?used solely for the connection of an End User > to a service provider? and would need to registered as a separate > assignment. > > Everybody ignores that requirement, of course, because otherwise the > result would have been complete and utter mayhem. Nevertheless, it is a > de jure policy violation. AGGREGATED-BY-LIR solves that. Aggregation is one way to address that issue. There are other ways that don't require dumping the basic principle of registering contact details for End Users. Again looking at the IPv6 policy under the definition of 'Assign' it says: "This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties." We could apply some appropriate wording to the definition of DSL customers to cover situations like running a MineCraft server. Maybe something like: "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. This applies even if the customer allows other people to connect to the internet through their connection." I am sure someone could find more appropriate wording that would more accurately restrict the exception to this type of use case. > > > The bottom line is that this new status value adds no new benefit, > > but can be seriously mis-used to cause considerable damage to the > > RIPE Database as a public registry. It WILL be misused by those > > operating public networks who wish to keep their details hidden from > > public view. > > > We do not propose to do anything that hasn't already been done in the > IPv6 policy and database for years and years and years, and the sky has > not fallen. Your policy proposal is about adding a new status value for IPv4. The title does not propose to retrofit the whole IPv6 policy onto IPv4. Most of the internet has been on IPv4 for years and years and years. Dumbing down IPv4 registration data to the level of IPv6 may well have a significant impact on the registry. > The End Users that want anonymity for whatever reason have > ample opportunity to remain anonymous today, even while staying policy > compliant (not that bad actors would care about that). If you apply the policy correctly they do not have that opportunity now. You have to violate the policy for an End User to be anonymous now. > > Finally, there *is* a benefit to this proposal, an actual itch we're > trying to scratch, specifically where there are many identical small > assignments being made and removed in a rapid and automated fashion, to > End Users that don't operate their own NOCs. I've mentioned the cloud > VPS provider example before here. If this policy proposal only scratched that one itch it might be fine. But it goes WAY beyond that. It completely undermines the current IPv4 registration policy. Again it might be possible to address the cloud VPS situation with a similar exception to DSL customers. You don't need to destroy the entire policy to address a few exceptions. cheers denis co-chair DB-WG > > Tore > From ripedenis at gmail.com Mon Sep 25 16:36:33 2023 From: ripedenis at gmail.com (denis walker) Date: Mon, 25 Sep 2023 16:36:33 +0200 Subject: [address-policy-wg] 2023-04 The bigger picture In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: Colleagues I want to look at the bigger picture here. I apologise again for another long email. There are many issues here that this community has ignored for too long. So I hope some of you will at least read through to the end, think about what I say and comment...maybe even support the general idea... Although this has been a discussion with only a handful of people it has raised some interesting points. Many followers may have missed the significance of some of these points or perhaps not thought deeply about them. These include (in no particular order): -Different registration requirements for IPv4 and IPv6 -Differences in the way IPv4 and IPv6 have been allocated and assigned over time -Block size (fixed or random) -Retro fitting of features -Different levels of adherence to policy by resource holders -Voluntary nature of supplying some details -No consistent approach to supplied data -Confusion for some resource holders about what data to publish -Effort required to maintain data in the RIPE Database -Volatility of some fast changing data -Privacy -Customer confidentiality -Public interest -Public registry -Registering public networks -Addresses defined as free text (sometimes including name) This is a lot of issues wrapped around one policy proposal. This proposal will not address all, or even most, of these issues. I don't believe this is the right way forward. But what is the root problem here and how can we address it? There are also some other points to consider. At recent RIPE Meetings some prominent members of this community have told me in the strongest possible terms that there is no way in hell that they are going to list any of their customer's details in the public RIPE Database. No matter what any policy says. Commercial confidentiality seems to be a very sensitive issue for some resource holders. Of course this is a valid concern. But it needs to be balanced. Policy needs consensus, but when we have a consensus all resource holders must follow it. That is the only way a self regulating industry can work. Another reason of concern is the alignment of handling both IPv4 and IPv6 registrations in the RIPE Database. Where we have two systems that are managed in different ways, there are of course two ways they can be aligned. We can dumb down the IPv4 data to the level of IPv6. Or we can raise the IPv6 data to the level of IPv4. Everyone is focused on the dumbing down option. No one has even considered moving in the other direction. I have never understood why the IPv6 registration policy was not written with the same requirements in mind as the IPv4 in the first instance. Maybe at the time the automation options available then were not as extensive as they are today. Computer power and bandwidth were certainly not comparable to what they are today. Changes to the RIPE Database data model, interfaces, technology and design would make it possible to raise the level of IPv6 information available in the public registry to the same level as IPv4. At the heart of this issue is a public registry. But what is that in 2023? What does it mean? What should be in it? Who is it for? How do we achieve a three way balance between commercial sensitivity, public need and privacy? These are the sort of questions I was hoping the RIPE Database Requirements Task Force would answer when they started their work. The end result was a little disappointing. They didn't answer any of these questions. They focussed most of their attention looking backwards. Many of us know the history. We want to know how to move forwards. These types of proposals are not the right way forward. So where should we be heading? I believe we need a new Task Force to do what I thought the last one would do. To determine the business requirements for the RIPE Database as a public registry in the 2020s and beyond. To answer these fundamental questions. To establish the registration requirements for a public registry that we can have a consensus on and everyone will accept and apply. Daniel said at the BOFF in Iceland, "It's time to stop tinkering around the edges of the RIPE Database". But that is exactly what these policy proposals are doing. Here we are trying to retrofit an IPv6 construct onto IPv4. Straight away assignment-size had to be dropped as it won't fit with the way IPv4 assignments are made or how they could be retrospectively aggregated. Knowing the blocksize has nothing to do with HD ratios and further allocations. It tells you nothing about how many assignments have been made from the aggregate, 1 or 100. It exists for IPv6 for other reasons. The same reasons we need for IPv4 but can't achieve, because the two systems are not the same. We need to start with a full, forward looking Business Requirements document for the RIPE Database, based on accepted business analysis procedures. We can follow that with a Technical Requirements document outlining how things should be done. Not at the level of defining technology or software design, that is for the NCC engineer's to determine. This should include the outline design of the data model and interfaces to commercial IPAM systems. Syncing bits of your internal data, as defined necessary for a public registry, with a database really isn't the problem in 2023. There should be no labour intensive work here. It doesn't matter if the RIPE Database has 5m or 50m or 500m assignment data sets in it. As long as they contain the data defined by the requirements to serve as a balanced public registry. No one should be manually entering this data. No one is going to read this data. We can build tools to provide information from this data in a human understandable format. In terms of registration requirements there should be little or no distinction between IPv4 and IPv6. But that doesn't mean we take the lowest common level. In case anyone is in any doubt, I am suggesting a redesign and rebuild of the RIPE Database, based on an updated understanding of what is needed to maintain and operate a public registry for all stakeholders. I know none of the RIPE community nor the RIPE WG chairs nor the RIPE NCC membership (who pay for it) nor the RIPE NCC executive board or senior management has any appetite for this. In the past whenever I have brought up this subject I have been totally ignored. Replying to emails where I have mentioned this, people have noticeably answered other points and cut out any reference to redesigning the RIPE Database. Many people have gone to extraordinary lengths to avoid even having this conversation. Seriously guys, the time has come to have this conversation. Daniel tried to start it at that BOFF. The RIPE community has just let it drop...again. The current design of the RIPE Database data model and software is about 25 years old. It was a big waterfall project with a big bang release and switch over from version 2 in April 2001. Aspects of the design, including having all data stored in untouched, human readable, text blocks, even predates this. We have had two major rewrites of the software in this time in C and then java. But the underlying design was not changed at all. Much of it is no longer fit for purpose. This attempt to retro fit aggregations from IPv6 to IPv4 highlights some of the cracks. It gets harder and harder to make significant changes to this system over time. Like assigning a whole allocation which cuts to the core of the software design and data model. Just to make this one change would be a very disruptive process for all users. Even if we decide today to set up a new task force to determine the business requirements, then the technical requirements, then redesign and rebuild in small agile chunks, we won't have a new system for at least 5 years. By then we are working with a 30 year old data model and system design. That is the age of dinosaurs in the IT world. Do we really want to wait until it breaks before we do anything? Calm, collective consideration is a better working model than panic, reactive mode. We are long overdue for this. It does not need to be done again in one huge step. It can be done incrementally. Use agile not waterfall methods. The whole system can be easily broken down into subsystems which can be worked on independently and deployed without massive disruption. I'll give some of my own thoughts and ideas on how some of this can be done. Task Force 1 to determine the business requirements of the RIPE Database as a public registry. Task Force 2 to determine the technical requirements of the RIPE Database as a public registry. Redesigned data model dropping the old fashioned requirement to have all data stored in untouched text blocks and be human readable. Stored data should be machine parsable and processable. Tools and interfaces can be provided to offer information based on the stored data or raw data for further machine processing. Accommodate new business models including the acceptance of investors and commercial RIRs operating below the RIPE NCC. Interfaces to commercial IPAM systems so all the required data can be uploaded and synced without human effort. Expand the LIR Portal to a system of user accounts for anyone who enters data into the database and identified/verified power users who consume the data. Notifications are basically an audit trail of changes to your data. This should be configured through the user accounts. No need for it to be spread throughout the entire database at the data set level. There are millions of attributes with duplicated email addresses all over the data. This has no public interest value at all and should not be public data. We should design a new authorisation and authentication scheme, also configured through the user accounts. Again details about the security of your data have no public interest value and should not be public data. I don't know of any other web based system that publishes so much information about how you secure and protect your data. The basic data is composed of hierarchical sets of IP addresses. But only abuse contacts use inheritance. All contact and management data should be inherited. That again could remove millions of items of duplicated, redundant data. Structure of contact and identification data should also be redesigned with privacy and confidentiality in mind. Resource holder and End User name and address details should be properly formatted rather than free text. Requirements for user registration details in a public registry could be re-evaluated and re-designed from the bottom up with a three way balance of privacy, confidentiality and public interest in mind. Language and characterisation of data can be re-evaluated for the whole data set. Routing data could be better structured with usage in mind. Tools could be built in to provide the structured data needed by those who use this data. Geolocation data could be built in rather than relying on external files. Basic, anonymous queries could be limited to bare bones data with no PII. More detailed data could be provided only to verified query users, with accounts, with different levels of detail. Historical data could be subject to a one time post processing to remove PII from public view but still allow anonymised cross referencing that researchers and investigators can do now with the PII data. The whole dataset should be organisation centric. Every piece of data entered into the database should be directly or indirectly linked to an organisation described in the dataset. There is no reason to allow anonymous or orphaned data to be entered. All changes of this nature could be made independently and gradually introduced. But we do need a road map based on a bigger picture so we know where we are heading. Especially for the core changes. If there is one thing I want you to consider from this message it is this: id nunc, aliquo tempore postea fit numquam I am not well know for my language skills so let me say it in English: do it now, sometime later becomes never cheers denis co-chair DB-WG From cfriacas at fccn.pt Mon Sep 25 21:30:42 2023 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Mon, 25 Sep 2023 20:30:42 +0100 (WEST) Subject: [address-policy-wg] 2023-04 The bigger picture In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: <7a927433-f780-6363-2a7-697fdf54fce0@fccn.pt> Greetings Denis, All, Yes, it was a very long message :-) Well, maybe not, if we keep in mind the time you have worked and thought about and around the RIPE database. I obviously don't agree with everything you wrote, while i can agree with most of it. 2023-04 seems a bad idea to me, but at least it doesn't prevent anyone to keep on the registration of their assignments if they wish to do so. This proposal sounds like a "less effort for everyone" proposal, and for me, even if it's unintended, a way to increase opacity. Is it enough for a public registry to have just the association between address space and its direct members? -- i don't believe so. Some LIRs are not registering their assignments (violating current policy, right?), so we change/update the policy to make their lack of action as part of the policy? It sounds very wrong to increase compliance levels artificially by changing the rules. I see "arguments opposing the proposal" = none. I would like to disagree. The quality of publicly available registration data is likely to decrease if this proposal goes through. Regards, Carlos On Mon, 25 Sep 2023, denis walker wrote: > Colleagues > > I want to look at the bigger picture here. I apologise again for > another long email. There are many issues here that this community has > ignored for too long. So I hope some of you will at least read through > to the end, think about what I say and comment...maybe even support > the general idea... > > Although this has been a discussion with only a handful of people it > has raised some interesting points. Many followers may have missed the > significance of some of these points or perhaps not thought deeply > about them. These include (in no particular order): > -Different registration requirements for IPv4 and IPv6 > -Differences in the way IPv4 and IPv6 have been allocated and assigned over time > -Block size (fixed or random) > -Retro fitting of features > -Different levels of adherence to policy by resource holders > -Voluntary nature of supplying some details > -No consistent approach to supplied data > -Confusion for some resource holders about what data to publish > -Effort required to maintain data in the RIPE Database > -Volatility of some fast changing data > -Privacy > -Customer confidentiality > -Public interest > -Public registry > -Registering public networks > -Addresses defined as free text (sometimes including name) > > This is a lot of issues wrapped around one policy proposal. This > proposal will not address all, or even most, of these issues. I don't > believe this is the right way forward. But what is the root problem > here and how can we address it? > > There are also some other points to consider. At recent RIPE Meetings > some prominent members of this community have told me in the strongest > possible terms that there is no way in hell that they are going to > list any of their customer's details in the public RIPE Database. No > matter what any policy says. Commercial confidentiality seems to be a > very sensitive issue for some resource holders. Of course this is a > valid concern. But it needs to be balanced. Policy needs consensus, > but when we have a consensus all resource holders must follow it. That > is the only way a self regulating industry can work. > > Another reason of concern is the alignment of handling both IPv4 and > IPv6 registrations in the RIPE Database. Where we have two systems > that are managed in different ways, there are of course two ways they > can be aligned. We can dumb down the IPv4 data to the level of IPv6. > Or we can raise the IPv6 data to the level of IPv4. Everyone is > focused on the dumbing down option. No one has even considered moving > in the other direction. I have never understood why the IPv6 > registration policy was not written with the same requirements in mind > as the IPv4 in the first instance. Maybe at the time the automation > options available then were not as extensive as they are today. > Computer power and bandwidth were certainly not comparable to what > they are today. Changes to the RIPE Database data model, interfaces, > technology and design would make it possible to raise the level of > IPv6 information available in the public registry to the same level as > IPv4. > > At the heart of this issue is a public registry. But what is that in > 2023? What does it mean? What should be in it? Who is it for? How do > we achieve a three way balance between commercial sensitivity, public > need and privacy? These are the sort of questions I was hoping the > RIPE Database Requirements Task Force would answer when they started > their work. The end result was a little disappointing. They didn't > answer any of these questions. They focussed most of their attention > looking backwards. Many of us know the history. We want to know how to > move forwards. These types of proposals are not the right way forward. > So where should we be heading? I believe we need a new Task Force to > do what I thought the last one would do. To determine the business > requirements for the RIPE Database as a public registry in the 2020s > and beyond. To answer these fundamental questions. To establish the > registration requirements for a public registry that we can have a > consensus on and everyone will accept and apply. > > Daniel said at the BOFF in Iceland, "It's time to stop tinkering > around the edges of the RIPE Database". But that is exactly what these > policy proposals are doing. Here we are trying to retrofit an IPv6 > construct onto IPv4. Straight away assignment-size had to be dropped > as it won't fit with the way IPv4 assignments are made or how they > could be retrospectively aggregated. Knowing the blocksize has nothing > to do with HD ratios and further allocations. It tells you nothing > about how many assignments have been made from the aggregate, 1 or > 100. It exists for IPv6 for other reasons. The same reasons we need > for IPv4 but can't achieve, because the two systems are not the same. > > We need to start with a full, forward looking Business Requirements > document for the RIPE Database, based on accepted business analysis > procedures. We can follow that with a Technical Requirements document > outlining how things should be done. Not at the level of defining > technology or software design, that is for the NCC engineer's to > determine. This should include the outline design of the data model > and interfaces to commercial IPAM systems. Syncing bits of your > internal data, as defined necessary for a public registry, with a > database really isn't the problem in 2023. There should be no labour > intensive work here. It doesn't matter if the RIPE Database has 5m or > 50m or 500m assignment data sets in it. As long as they contain the > data defined by the requirements to serve as a balanced public > registry. No one should be manually entering this data. No one is > going to read this data. We can build tools to provide information > from this data in a human understandable format. In terms of > registration requirements there should be little or no distinction > between IPv4 and IPv6. But that doesn't mean we take the lowest common > level. > > In case anyone is in any doubt, I am suggesting a redesign and rebuild > of the RIPE Database, based on an updated understanding of what is > needed to maintain and operate a public registry for all stakeholders. > I know none of the RIPE community nor the RIPE WG chairs nor the RIPE > NCC membership (who pay for it) nor the RIPE NCC executive board or > senior management has any appetite for this. In the past whenever I > have brought up this subject I have been totally ignored. Replying to > emails where I have mentioned this, people have noticeably answered > other points and cut out any reference to redesigning the RIPE > Database. Many people have gone to extraordinary lengths to avoid even > having this conversation. Seriously guys, the time has come to have > this conversation. Daniel tried to start it at that BOFF. The RIPE > community has just let it drop...again. > > The current design of the RIPE Database data model and software is > about 25 years old. It was a big waterfall project with a big bang > release and switch over from version 2 in April 2001. Aspects of the > design, including having all data stored in untouched, human readable, > text blocks, even predates this. We have had two major rewrites of the > software in this time in C and then java. But the underlying design > was not changed at all. Much of it is no longer fit for purpose. This > attempt to retro fit aggregations from IPv6 to IPv4 highlights some of > the cracks. It gets harder and harder to make significant changes to > this system over time. Like assigning a whole allocation which cuts to > the core of the software design and data model. Just to make this one > change would be a very disruptive process for all users. Even if we > decide today to set up a new task force to determine the business > requirements, then the technical requirements, then redesign and > rebuild in small agile chunks, we won't have a new system for at least > 5 years. By then we are working with a 30 year old data model and > system design. That is the age of dinosaurs in the IT world. Do we > really want to wait until it breaks before we do anything? Calm, > collective consideration is a better working model than panic, > reactive mode. We are long overdue for this. > > It does not need to be done again in one huge step. It can be done > incrementally. Use agile not waterfall methods. The whole system can > be easily broken down into subsystems which can be worked on > independently and deployed without massive disruption. I'll give some > of my own thoughts and ideas on how some of this can be done. > > Task Force 1 to determine the business requirements of the RIPE > Database as a public registry. > > Task Force 2 to determine the technical requirements of the RIPE > Database as a public registry. > > Redesigned data model dropping the old fashioned requirement to have > all data stored in untouched text blocks and be human readable. Stored > data should be machine parsable and processable. Tools and interfaces > can be provided to offer information based on the stored data or raw > data for further machine processing. > > Accommodate new business models including the acceptance of investors > and commercial RIRs operating below the RIPE NCC. > > Interfaces to commercial IPAM systems so all the required data can be > uploaded and synced without human effort. > > Expand the LIR Portal to a system of user accounts for anyone who > enters data into the database and identified/verified power users who > consume the data. > > Notifications are basically an audit trail of changes to your data. > This should be configured through the user accounts. No need for it to > be spread throughout the entire database at the data set level. There > are millions of attributes with duplicated email addresses all over > the data. This has no public interest value at all and should not be > public data. > > We should design a new authorisation and authentication scheme, also > configured through the user accounts. Again details about the security > of your data have no public interest value and should not be public > data. I don't know of any other web based system that publishes so > much information about how you secure and protect your data. > > The basic data is composed of hierarchical sets of IP addresses. But > only abuse contacts use inheritance. All contact and management data > should be inherited. That again could remove millions of items of > duplicated, redundant data. Structure of contact and identification > data should also be redesigned with privacy and confidentiality in > mind. > > Resource holder and End User name and address details should be > properly formatted rather than free text. > > Requirements for user registration details in a public registry could > be re-evaluated and re-designed from the bottom up with a three way > balance of privacy, confidentiality and public interest in mind. > > Language and characterisation of data can be re-evaluated for the > whole data set. > > Routing data could be better structured with usage in mind. Tools > could be built in to provide the structured data needed by those who > use this data. > > Geolocation data could be built in rather than relying on external files. > > Basic, anonymous queries could be limited to bare bones data with no > PII. More detailed data could be provided only to verified query > users, with accounts, with different levels of detail. > > Historical data could be subject to a one time post processing to > remove PII from public view but still allow anonymised cross > referencing that researchers and investigators can do now with the PII > data. > > The whole dataset should be organisation centric. Every piece of data > entered into the database should be directly or indirectly linked to > an organisation described in the dataset. There is no reason to allow > anonymous or orphaned data to be entered. > > All changes of this nature could be made independently and gradually > introduced. But we do need a road map based on a bigger picture so we > know where we are heading. Especially for the core changes. > > > > If there is one thing I want you to consider from this message it is this: > id nunc, aliquo tempore postea fit numquam > > I am not well know for my language skills so let me say it in English: > do it now, sometime later becomes never > > cheers > denis > co-chair DB-WG > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ > From tore at fud.no Tue Sep 26 15:41:10 2023 From: tore at fud.no (Tore Anderson) Date: Tue, 26 Sep 2023 15:41:10 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: Hi Denis, It would appear to me that your opposition to 2023-04 is largely based on the premise that it introduces a new possibility for anonymous assignments, a change which you do not want to see happen. This premise also appears to underpin many of your musings in your ?The bigger picture? message. I disagree with this premise, as I believe this possibility is already there in current policy. Rather than decide to agree to disagree on that point, or endlessly quarrel about it, I realised that it does not really matter what you or I believe the policy requirements are - what matters is the RIPE NCC's?understanding of the policy and how they are implementing it. So I simply asked their Policy Officer (Angela) to clarify this. Her answers, which I with permission quote in full along with my questions below, unequivocally confirms that that current policy does indeed allow assignments to be registered anonymously in the RIPE database. Hence, your opposition to proposal 2023-04 in this regard appears to rest on a fundamentally flawed assumption. Tore: ?The context here is an IPv4 assignment that is not made to an individual and that is not used solely for the connection of an End User to a service provider. 1. Does current address policy as implemented by the NCC allow an End User to delegate/outsource the contact information represented by the mandatory "tech-c" and "admin-c" attributes to another entity, typically (but not necessarily) the issuing LIR? (There does not appear to be any disagreement on this point, but I include this question anyway in case we are both wrong.)? Angela: ?Yes, you are correct. An End User is allowed to delegate/outsource the contact information represented by the mandatory "tech-c" and "admin-c" attributes to another entity, typically (but not necessarily) the issuing LIR.? Tore: ?2. Assuming "yes" to question 1, for an assignment where the "tech-c" and "admin-c" has been delegated in this manner: Does current address policy require the corresponding "inetnum" database object to contain some additional contact information, that is not delegated to a third party, i.e., it must be refer to a point of contact that is handled in-house by the End User him/herself?? Angela: ?The current address policy does not require the corresponding "inetnum" database object to contain some additional contact information that is not delegated to a third party. LIRs can use the ?netname? attribute to link assignments to end users and their contact details in internal records. There is a particular case: when the RIPE NCC receives a request for assigning an AS number to an End User using a PA assignment, the IPv4 network to be announced by the requested AS must be registered in an ?inetnum? object showing the End User?s name. This can be in the "descr? attribute or recursively in the "org" object added as attribute.? Tore: ?3. Assuming "yes" to question 2, what kind of other contact information is required, and in which "inetnum" database attribute(s) must it be located? Here are some possible examples off the top of my head, would any or all of these satisfy the policy requirement for an in-house non-delegated contact information? 1. A street address 2. A (snail) mail address 3. An e-mail address 4. A fax number 5. A phone number? Angela: ?The answer to question 2 was ?no?, however one way to record End Users? contact details is to create an ?org? object to be added as optional attribute in the ?inetnum? object. In ?org? objects name, address and email are mandatory. In ?inetnum? objects the mandatory contact information are ?admin-c? and ?tech-c?.? Tore: ?4. Assuming "yes" to question 2, is it mandatory to identify the End User by name, or would it be sufficient with, e.g., a street address without an organisation name (assuming there is only a single entity located at that address), a post box snail mail address, a generic user123 at gmail.com e-mail address, or a phone/fax number that is not listed in the white or yellow pages?? Angela: ?The answer to question 2 was ?no?,...? Tore (in a new e-mail): ?I will ask you a couple of follow-up questions just to make absolutely, 150%, certain I do not misunderstand you and end up misrepresenting you to the mailing list: 1. When you write ?LIRs can use the ?netname? attribute to link assignments to end users and their contact details in internal records?, this "can" is a MAY, not a MUST, to use IETF lingo? That is, the LIR is free to instead use the "inetnum" attribute, i.e., the IP address(es), to link the assignment to the End User in their internal record? If that is the case, would it be correct to say that the LIR are free to set the "netname" attribute to essentially anything, including a meaningless string of random characters?? Angela: ?Your interpretation is correct, the answer is yes to all three questions. Please also consider that the "netname" is not required to be unique, LIRs can use the same one for multiple assignments.? Tore: ?2. When you write ?one way to record End Users? contact details is to create an ?org? object to be added as optional attribute in the ?inetnum? object?, this is also a MAY, not a MUST? That is, the LIR is free to omit the "org" attribute, even though the only other contact information contained in the object is the (LIR-delegated) "tech-c" and "admin-c" attributes?? Angela: ?Yes, the LIR is free to omit the "org" attribute, even though the only other contact information contained in the object is the (LIR-delegated) "tech-c" and "admin-c" attributes. If the LIR requests an AS number on behalf of an end user to announce a PA assignment, then the PA assignment MUST include the legal name of the end user in the "descr" attribute or in the '"org" object set as "org" attribute in the "inetnum" object.? Tore: ?3. To use a concrete example: Let's say ?SuperLIR GmbH? delegated 192.0.2.0/25 to the End User ?CarFactory GmbH?. (CarFactory GmbH is not an individual, and the assignment is not used solely for the connection to the provider, nor to justify an application for an AS number). SuperLIR inserts the following minimal database object: inetnum: 192.0.2.0 - 192.0.2.128 netname: ABCDEFGHIJKLMNOPQRSTUVWXYZ country: DE admin-c: SUPERLIR-NOC-RIPE tech-c: SUPERLIR-NOC-RIPE status: ASSIGNED PA mnt-by: SUPERLIR-MNT source: RIPE In the event of an audit, SuperLIR GmbH will be able to inform the RIPE NCC auditors that this object has been delegated to CarFactory GmbH. Is the above registration compliant with current IPv4 address policy, or will the auditors demand any kind of changes be made?? Angela: ?The above registration compliant with current IPv4 address policy. During an audit we could ask the LIR whether the assignment is still in use. It does not matter for the RIPE NCC who is using the assignment, as long as the LIR is maintaining the registration up to date and is able to contact the end user. This means that if the LIR moves the assignment delegation from CarFactory GmbH to another end user in the same country for which is acting as "admin- c" and "tech-c", the "inetnum" object would still be valid. It is the LIR's responsibility to keep their internal records up to date accordingly with the new end user.? In light of the above, I hope that you will reconsider your opposing arguments and either withdraw them or restate them in a way that does not rely on this incorrect assumption. Anticipating this, I will only address your remaining points that are not based on the misunderstanding that 2023-04 opens up for anonymous assignments. > It should not be permitted to aggregate a single assignment to a > single End User. While I agree that "aggregating" a single assignment seems like a pointless practice, I do not quite see why it is necessary to introduce policy language to ban it. It is, as I understand it, possible to use AGGREGATED-BY-LIR with an assignment-size identical to the prefix length in the inet6num attribute today, but I cannot find a single example of this being done. (Presumably because it is pointless to do so.) It is also possible today to "aggregate" a single IPv4 assignment under the ?solely for connection? exception. Whether or not that has been done is impossible for me to say, but even if it has I fail to understand why it would constitute an actual problem. I am not being totally dismissive towards adding a condition ? la ?an object with status AGGREGATED-BY-LIR must contain at least two individual assignments? to the proposal, but I would first like to better understand the reasons why you feel this is a necessity. > But the IPv6 policy also includes this: > "When more than a /48 is assigned to an organisation, it must be > registered in the database as a separate object with status > 'ASSIGNED'." > I don't see your equivalent of this copied from the IPv6 policy into > your new IPv4 policy. Maybe more than a /24 might be an equivalent in > IPv4 terms. You refer to 'that specific sentence' so casually, yet > this is the main element of the current IPv4 assignment policy. > Dropping this sentence is a major change to the assignment policy. > This has far more consequences than just adding an optional > construct. In IPv6, /48 is the limit beyond which extra documentation requirements ("need basis") kicks in. Assignments /48 or longer can be freely made by an LIR without any supporting documentation, and this is presumably why such assignments can be freely registered under a single AGGREGATED-BY-LIR object. In other words, assignments shorter than /48 has more stringent documentation requirements, and therefore also more stringent registration requirements. See https://www.ripe.net/publications/docs/ripe-738#assignments_shorter As there is no "need basis" for assignments in IPv4 regardless of size, there simply is no equivalent value, not /24 nor anything else. (Well, I suppose you could say that /0 is the equivalent value.) > > > > > Note that this is not really much different than what you have > > > > to do today for abuse coming from customer assignments that are > > > > ?registered as part of the service provider's internal > > > > infrastructure?, cf. ripe-708 section 6.2. > > Doesn't that suggest they are DSL customers with a single IP address? No, it does not say anything about the number of addresses in the assignment nor the layer-1 technology used. It is very common for point-to-point links (the example given in section 6.2) to be assigned /31 or /30. If the service provider and/or the customer is using a first-hop redundancy protocol such as VRRP, it is necessary to assign a /29 or larger. In any case, there is no technological reason nor any policy limitation that would prevent a service provider from assigning a preposterously large prefix to a point-to-point link, like a /16, let's say. > Assuming an LIR has chosen to use this new 'optional' status value. > As many LIRs already have aggregated their DSL customers and tagged > them as such in remarks attributes, why should they change it? We do not expect the RIPE NCC to start a mass migration project as a result of this policy proposal. It is our intention that assignments made under the old policy would be grandfathered in, similar to how you still see many objects with the obsoleted INFRA-AW tag remain in the database today. LIRs would of course be free to change the status value at any point, should they want to do so. > > If it has this new aggregated status you still don't know if it is a > block of maybe 1000 DSL customers of a collection of randomly sized > assignments to End Users. You still need the free text remarks to > avoid confusion. You do not know that today, either, when it comes to aggregated assignments made under the ?solely for the connection? exception in current IPv4 policy. Such objects do not contain an assignment-size attribute, nor does policy demand that all individual assignments contained within are of a specific and uniform prefix length. Therefore, such assignments may contain a hodgepodge of DSL customers, FTTH customers, business customers, connected with or without VRRP, and so on. This would continue to be permitted with AGGREGATED-BY-LIR. Tore From nick at foobar.org Wed Sep 27 22:57:36 2023 From: nick at foobar.org (Nick Hilliard) Date: Wed, 27 Sep 2023 21:57:36 +0100 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> <24EEA0CA-297E-4B9C-AB05-F8B2DCA0DF95@a2b-internet.com> Message-ID: denis walker wrote on 24/09/2023 17:12: > So are you saying > that in 2023 we can't manage a distributed database without > overwhelming repetitive tasks? yes, correct. People are stuck using the tools that they have. Most off-the-shelf tools don't implement server-client or 2way database synchronisation between the local ipam system and the ripe db, and there's ~zero financial inventive to build this sort of functionality in-house. The outcome is that the ripedb ends up with manual updates, or else with low quality / 1-way synchronisation with little or no cleanup. The result of this is that the ASSIGNED-PA objects in the ripedb are generally of low average accuracy. Nick From ripedenis at gmail.com Thu Sep 28 10:50:58 2023 From: ripedenis at gmail.com (denis walker) Date: Thu, 28 Sep 2023 10:50:58 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> <24EEA0CA-297E-4B9C-AB05-F8B2DCA0DF95@a2b-internet.com> Message-ID: Hi Nick I feel your pain on this one. I can understand that no LIR wants to invest time or money in developing this as a one off, in-house solution. Something like this needs to be done at a higher level. That's why you pay fees to the RIPE NCC. They should be talking to the developers of the commercial IPAM systems about syncing with the RIPE Database. Whether or not it could be done with the current data model and software I don't know. But it is time to consider these things. cheers denis co-chair DB-WG On Wed, 27 Sept 2023 at 22:57, Nick Hilliard wrote: > > denis walker wrote on 24/09/2023 17:12: > > So are you saying > > that in 2023 we can't manage a distributed database without > > overwhelming repetitive tasks? > > yes, correct. People are stuck using the tools that they have. Most > off-the-shelf tools don't implement server-client or 2way database > synchronisation between the local ipam system and the ripe db, and > there's ~zero financial inventive to build this sort of functionality > in-house. The outcome is that the ripedb ends up with manual updates, or > else with low quality / 1-way synchronisation with little or no cleanup. > > The result of this is that the ASSIGNED-PA objects in the ripedb are > generally of low average accuracy. > > Nick From ripe-lists at sebastian-graf.at Thu Sep 28 11:41:16 2023 From: ripe-lists at sebastian-graf.at (Sebastian-Wilhelm Graf) Date: Thu, 28 Sep 2023 11:41:16 +0200 Subject: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> <24EEA0CA-297E-4B9C-AB05-F8B2DCA0DF95@a2b-internet.com> Message-ID: <2bcd78d7-3067-30fc-cfa8-c98cb8662feb@sebastian-graf.at> Dear Denis! I strongly disagree on this notion of derferring everything to the? "higher power" of RIPE. If we want a solution that integrates with IPAM Systems, then we (the community) should organise that, preferably systems that are "open" by design/license. And if only a minority of the community wishes for such a solution, then only said minority should fund that development. Especially if the benefit is mostly towards external commercial organisations.... I also reject the notion that just because the "tooling" is there (theoretically), that the accuracy would improve. But that is a disucssion further up in this thread. And personally i think aggregated-by-lir makes a ton of sense. cheers On 9/28/23 10:50, denis walker wrote: > Hi Nick > > I feel your pain on this one. I can understand that no LIR wants to > invest time or money in developing this as a one off, in-house > solution. Something like this needs to be done at a higher level. > That's why you pay fees to the RIPE NCC. They should be talking to the > developers of the commercial IPAM systems about syncing with the RIPE > Database. Whether or not it could be done with the current data model > and software I don't know. But it is time to consider these things. > > cheers > denis > co-chair DB-WG > > > On Wed, 27 Sept 2023 at 22:57, Nick Hilliard wrote: >> denis walker wrote on 24/09/2023 17:12: >>> So are you saying >>> that in 2023 we can't manage a distributed database without >>> overwhelming repetitive tasks? >> yes, correct. People are stuck using the tools that they have. Most >> off-the-shelf tools don't implement server-client or 2way database >> synchronisation between the local ipam system and the ripe db, and >> there's ~zero financial inventive to build this sort of functionality >> in-house. The outcome is that the ripedb ends up with manual updates, or >> else with low quality / 1-way synchronisation with little or no cleanup. >> >> The result of this is that the ASSIGNED-PA objects in the ripedb are >> generally of low average accuracy. >> >> Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xCB3F9792B5ACD96C.asc Type: application/pgp-keys Size: 3935 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From ripedenis at gmail.com Thu Sep 28 12:31:15 2023 From: ripedenis at gmail.com (denis walker) Date: Thu, 28 Sep 2023 12:31:15 +0200 Subject: [address-policy-wg] 2023-04 Are anonymised assignment objects valid? In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: Colleagues I know this is a very long email and no one has the time to read it, but I have at least put my points on record. This proposal claims to only be about adding a new, optional status value. It is claimed it doesn't permit anything else that isn't already possible with the current address policy. In particular it is claimed you can already have anonymous assignments in the RIPE Database. Some people do create such objects. The RIPE NCC audits don't question such objects. But is that right? There has been so much false and misleading information about this issue. I am going to have one last attempt to put the record straight. Then, if no one else cares, why should I? I have a bathroom to build... We are talking about one sentence in the current address policy that this proposal removes. A sentence that is the heart of assignment policy. The core of the public registry of public IP addresses. An English sentence that is so clear and obvious, it simply cannot be misunderstood or (mis)interpreted. And yet I am having to write an essay to try to explain what this clear sentence means. "When an End User has a network using public address space this must be registered separately with the contact details of the End User." Let me break it down into smaller segments to explain it's meaning: 'End User has a network' - a network for an End User 'using public address space' - the address space for the network is part of the public Internet 'must be' - MUST, not can, should, may, possibly, perhaps...MUST 'registered separately' - registered in the RIPE Database in a separate object, all alone 'contact details' - information that allows you to make contact with 'of the End User' - the End User who you want to contact This sentence only has one possible meaning. And that meaning says you cannot have an End User assignment in the RIPE Database that does not allow you to make contact with the End User (subject to the specified exceptions). This sentence and meaning are so clear it is impossible to write it any clearer. What matters today is the actual wording of the current address policy. But to understand some of that, we need to look at how we got here and some of the early definitions that are no longer included in the policy. So let's start with a history lesson. With my information archeologist's hat on, I've gone all the way back to 1990 to understand what the terminology in the address policy and the RIPE Database means. In the first version of the address policy ripe-065 RIPE NCC Internet Numbers Registration Procedures Publication date: 01 Jul 1992 It says: "This document describes the procedures for the reassignment of IP network numbers from blocks obtained from the RIPE Network Coordination Centre." ... "Full information about reassigned network numbers must be reported back to the RIPE NCC and the US NIC in full RIPE database format (ref ripe-13)." Then in ripe-13 RIPE Databases Publication date: 28 Aug 1990 It describes the network objects to include these attributes: ----------- tc -name of technical contact. This must be the same string as in the corresponding *pn entry. There must be such a person entry! ac -name of administrative contact. This must be the same string as in the corresponding *pn entry. There must be such a person entry! de -description of the network. Give organisation and place. Postal address and country are not needed, they can be found via the contacts. The country is given in *cy. ----------- Then in an example it includes: ----------- *de: CWI Ethernet (Classical) *de: Amsterdam *de: Netherlands ----------- So right from the start of registration we have had description attributes giving information about the name and location of the assignment holder. Then we move a few hops to ripe-136 European Internet Registry Policies And Procedures Publication date: 24 May 1996 This is starting to look a bit like modern address policy. Interestingly it actually defines some of the terms we have lost touch with over time. If you ask most people now what an admin-c contact is they don't know. Which is why many objects have the same entry for both tech-c and admin-c. But that is often wrong. Some definitions: End users are those organizations operating networks in which the address space is used. End users must provide and update registration data for the address space assigned to them. Local IRs are typically operated by Internet Service Providers (ISPs). Local IRs hold allocations of address space for assignment to end users. In some cases, the local IR assigning the address space is not run by the ISP that will provide connectivity. It is important to note that maintenance of the administrative information regarding the assigned address space is the responsibility of the IR that makes the assignment, and not of the ISP providing the connectivity. Requesters - In addition to these key players in the Internet Registry System, there are often consultants who set up and manage networks for end users. netname - a short, but semantically meaningful name descr - A short description of the organisation that will use the assigned addresses, in one or more fields. Typically the name of the organisation. admin-c - administrative contact persons. The administrative person specified in the admin-c field must be physically located at the site of the network. [Clearly the original definition of the admin contact means it must be someone at the site of the end user. This, with the descr fields, identifies and provides contact information for the end user.] tech-c - technical contact persons. The technical person specified in the tech-c field may be a network support person located on site, but could also be a consultant that maintains the network for the organisation. Submission of objects to the database is the final and required step in making an assignment. This step makes the assignment definite, and makes public information regarding the assignment available to anyone seeking it. [Again it is clear from the early days that the public registry was not only an operators phone book for solving network issues. Maybe this will bring to an end those endless arguments about whether LEAs have a right to access and use the information in the RIPE Database. "available to anyone seeking it"] >From ripe-140 European Internet Registry Policies and Procedures Publication date: 06 Sep 1996 Just for further clarity it describes the admin-c of an aut-num object as: "The administrative contact should be physically located at the enterprise requesting the AS number." which further clarifies the difference between the tech-c and admin-c generally. ripe-159 (29 Jul 1997) adds that the admin-c "The person does not have to have technical knowledge of the network." Then we get to ripe-234 IPv4 Address Allocation and Assignment Policies In The RIPE NCC Service Region Publication date: 14 Jun 2002 This is where we first get the differentiation between DSL connections and public networks. "However, four or more addresses (e.g. /30 or more) used on the End User's network need to be registered separately with the contact details of the End User." Almost the exact wording we still use today, 21 years later. Then ripe-288 IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Date: 28 October 2003 We now have the exact wording that we have today (it is even in paragraph 6.2): "When an End User has a network using public address space this must be registered separately with the contact details of the End User." So we have had this principle with the exact same wording for 20 years. Every version of the address policy since then has included this exact line. (Incidentally one of the authors of this document was Leo, now co-chair of this WG) All these documents have been co-written by many people including the RIPE NCC founder, RIPE NCC CEO, RIPE chair, RIPE co-chair, AP-WG co-chair, former DB-WG co-chair, yet we seem to have collectively forgotten what many of these terms mean. So now let's come back to the present. How do these definitions change our perspective? The first thing to note is that these definitions are no longer written into the policy. They disappeared over 20 years ago. But, in the absence of any definitions in the current policy, and no community consensus over that time to change any of these definitions, it seems reasonable to apply those definitions from earlier versions of the same policy document. Especially as the database documentation still makes the clear distinction between a tech-c and an admin-c in line with those early definitions. Let's again look at that typical company operating a network with public address space. They may be technically competent, in which case the tech-c will provide contact details for their own engineers. If they don't have the technical skills someone else will manage the network for them. That could be the LIR, or an ISP (seperate from the LIR) who provides the connectivity services, or an independent consultant. Whoever it is, they should be listed as the tech-c contact person. When it comes to the admin-c, we now know who this is meant to be. It is someone, with or without technical skills, who is physically located at the site of the enterprise operating the network. Having that person's contact details, combined with the descr attributes that optionally specify the name and location of the organisation, we satisfy the current policy requirement "registered separately with the contact details of the End User". When an LIR manages the network for the End User, to replace both the tech-c and admin-c with the LIR's contact details is wrong, according to the current policy. The admin-c should always be a contact from the End User's site. As many LIRs do get that bit wrong, they often compensate by adding full name and address details of the End User in the descr attributes. That makes them still compliant with current policy as the assignment object still has the contact details of the End User. There are so many objects in the database like this. If the labour intensity of maintaining this data is one of the driving forces behind this proposal, why do so many LIRs put all that optional data into their objects? That takes a lot of effort. If an assignment is cancelled then re-assigned to another customer, they have to change the object to update this optional data. Without the optional data the same object would still be valid for the next customer without any update. They do it because they read the policy and understand that line ("When an End User has a network using public address space this must be registered separately with the contact details of the End User.") and knew they must include contact details for the End User. During this debate it has been said that the contacts are "the tech-c and admin-c, nothing more, nothing less". That is just wrong. Nothing in the current or any previous version of the address policy has ever said that. You cannot just invent conditions like this, out of nowhere. The descr attributes are contacts. A referenced organisation object provides contacts. There are other options for contact information. But the bottom line is, the assignment object MUST contain the End User's contacts (subject to the specified exceptions). So it is not policy compliant to have an assignment object that does not have contact details of the End User. If the RIPE NCC does not question this during an audit, they have got it wrong. They may have got it wrong for many years, but it is still wrong. We should not change the policy just because mistakes have not been corrected for a long time. So the answer to the main question is (finally), this proposal makes significant changes to assignment policy and allows the creation of anonymised assignment objects that the current policy does not allow. I will go further than this. If the current policy was correctly applied, it is not possible to aggregate assignments as they will all have different admin-c contacts. That means the question the community needs to consider is if it is now acceptable to allow anonymised assignment objects in the RIPE Database, possibly in significant numbers? If this proposal is accepted and the definition of admin-c is changed to what many people actually think it is, then the only End Users who will be publicly contactable are those who manage their own networks. Potentially ALL others can be anonymised, with or without aggregation. Now just to finish off I will address the Q&A. On Tue, 26 Sept 2023 at 15:41, Tore Anderson wrote: > > Hi Denis, > > It would appear to me that your opposition to 2023-04 is largely based > on the premise that it introduces a new possibility for anonymous > assignments, a change which you do not want to see happen. This premise > also appears to underpin many of your musings in your ?The bigger > picture? message. Then you didn't read it. > I disagree with this premise, as I believe this > possibility is already there in current policy. "When an End User has a network using public address space this must be registered separately with the contact details of the End User." > > Rather than decide to agree to disagree on that point, or endlessly > quarrel about it, I realised that it does not really matter what you or > I believe the policy requirements are - what matters is the RIPE > NCC's understanding of the policy and how they are implementing it. So > I simply asked their Policy Officer (Angela) to clarify this. What matters is are they implementing it correctly? > > Her answers, which I with permission quote in full along with my > questions below, unequivocally confirms that that current policy does > indeed allow assignments to be registered anonymously in the RIPE > database. Hence, your opposition to proposal 2023-04 in this regard > appears to rest on a fundamentally flawed assumption. "When an End User has a network using public address space this must be registered separately with the contact details of the End User." > > > Tore: ?The context here is an IPv4 assignment that is not made to an > individual and that is not used solely for the connection of an End > User to a service provider. > > 1. Does current address policy as implemented by the NCC allow an End > User to delegate/outsource the contact information represented by the > mandatory "tech-c" and "admin-c" attributes to another entity, > typically (but not necessarily) the issuing LIR? (There does not appear > to be any disagreement on this point, but I include this question > anyway in case we are both wrong.)? > > Angela: ?Yes, you are correct. An End User is allowed to > delegate/outsource the contact information represented by the mandatory > "tech-c" and "admin-c" attributes to another entity, typically (but not > necessarily) the issuing LIR.? No it is not correct. The administrative person specified in the admin-c field must be physically located at the site of the network. Therefore it cannot be outsourced. > > Tore: ?2. Assuming "yes" to question 1, for an assignment where the > "tech-c" and "admin-c" has been delegated in this manner: Does current > address policy require the corresponding "inetnum" database object to > contain some additional contact information, that is not delegated to a > third party, i.e., it must be refer to a point of contact that is > handled in-house by the End User him/herself?? > > Angela: ?The current address policy does not require the corresponding > "inetnum" database object to contain some additional contact > information that is not delegated to a third party. > LIRs can use the ?netname? attribute to link assignments to end users > and their contact details in internal records. "When an End User has a network using public address space this must be registered separately with the contact details of the End User." > > There is a particular case: when the RIPE NCC receives a request for > assigning an AS number to an End User using a PA assignment, the IPv4 > network to be announced by the requested AS must be registered in an > ?inetnum? object showing the End User?s name. This can be in the > "descr? attribute or recursively in the "org" object added as > attribute.? This does not apply to most of the assignments in the database where the optional descr attributes have been added with name and address of the End User > > Tore: ?3. Assuming "yes" to question 2, what kind of other contact > information is required, and in which "inetnum" database attribute(s) > must it be located? Here are some possible examples off the top of my > head, would any or all of these satisfy the policy requirement for an > in-house non-delegated contact information? > 1. A street address > 2. A (snail) mail address > 3. An e-mail address > 4. A fax number > 5. A phone number? > > Angela: ?The answer to question 2 was ?no?, however one way to record > End Users? contact details is to create an ?org? object to be added as > optional attribute in the ?inetnum? object. > In ?org? objects name, address and email are mandatory. > In ?inetnum? objects the mandatory contact information are ?admin-c? > and ?tech-c?.? "When an End User has a network using public address space this must be registered separately with the contact details of the End User." > > Tore: ?4. Assuming "yes" to question 2, is it mandatory to identify the > End User by name, or would it be sufficient with, e.g., a street > address without an organisation name (assuming there is only a single > entity located at that address), a post box snail mail address, a > generic user123 at gmail.com e-mail address, or a phone/fax number that is > not listed in the white or yellow pages?? > > Angela: ?The answer to question 2 was ?no?,...? "When an End User has a network using public address space this must be registered separately with the contact details of the End User." > > Tore (in a new e-mail): ?I will ask you a couple of follow-up questions > just to make absolutely, 150%, certain I do not misunderstand you and > end up misrepresenting you to the mailing list: > > 1. When you write ?LIRs can use the ?netname? attribute to link > assignments to end users and their contact details in internal > records?, this "can" is a MAY, not a MUST, to use IETF lingo? That > is, the LIR is free to instead use the "inetnum" attribute, i.e., > the IP address(es), to link the assignment to the End User in their > internal record? If that is the case, would it be correct to say > that the LIR are free to set the "netname" attribute to essentially > anything, including a meaningless string of random characters?? > > Angela: ?Your interpretation is correct, the answer is yes to all > three questions. > Please also consider that the "netname" is not required to be > unique, LIRs can use the same one for multiple assignments.? > > Tore: ?2. When you write ?one way to record End Users? contact > details is to create an ?org? object to be added as optional > attribute in the ?inetnum? object?, this is also a MAY, not a MUST? > That is, the LIR is free to omit the "org" attribute, even though > the only other contact information contained in the object is the > (LIR-delegated) "tech-c" and "admin-c" attributes?? > > Angela: ?Yes, the LIR is free to omit the "org" attribute, even > though the only other contact information contained in the object is > the (LIR-delegated) "tech-c" and "admin-c" attributes. > If the LIR requests an AS number on behalf of an end user to > announce a PA assignment, then the PA assignment MUST include the > legal name of the end user in the "descr" attribute or in the '"org" > object set as "org" attribute in the "inetnum" object.? > "When an End User has a network using public address space this must be registered separately with the contact details of the End User." The administrative person specified in the admin-c field must be physically located at the site of the network. > Tore: ?3. To use a concrete example: Let's say ?SuperLIR GmbH? > delegated 192.0.2.0/25 to the End User ?CarFactory GmbH?. > (CarFactory GmbH is not an individual, and the assignment is not > used solely for the connection to the provider, nor to justify an > application for an AS number). SuperLIR inserts the following > minimal database object: > > inetnum: 192.0.2.0 - 192.0.2.128 > netname: ABCDEFGHIJKLMNOPQRSTUVWXYZ > country: DE > admin-c: SUPERLIR-NOC-RIPE > tech-c: SUPERLIR-NOC-RIPE > status: ASSIGNED PA > mnt-by: SUPERLIR-MNT > source: RIPE > > In the event of an audit, SuperLIR GmbH will be able to inform the > RIPE NCC auditors that this object has been delegated to CarFactory > GmbH. > > Is the above registration compliant with current IPv4 address > policy, or will the auditors demand any kind of changes be made?? > > Angela: ?The above registration compliant with current IPv4 address > policy. During an audit we could ask the LIR whether the assignment > is still in use. It does not matter for the RIPE NCC who is using > the assignment, as long as the LIR is maintaining the registration > up to date and is able to contact the end user. This means that if > the LIR moves the assignment delegation from CarFactory GmbH to > another end user in the same country for which is acting as "admin- > c" and "tech-c", the "inetnum" object would still be valid. It is > the LIR's responsibility to keep their internal records up to date > accordingly with the new end user.? "When an End User has a network using public address space this must be registered separately with the contact details of the End User." The above object is not compliant and the audit should pick that up > > > In light of the above, I hope that you will reconsider your opposing > arguments and either withdraw them or restate them in a way that does > not rely on this incorrect assumption. Anticipating this, I will only > address your remaining points that are not based on the > misunderstanding that 2023-04 opens up for anonymous assignments. > My assumption is correct. cheers denis co-chair DB-WG From nick at foobar.org Fri Sep 29 15:46:20 2023 From: nick at foobar.org (Nick Hilliard) Date: Fri, 29 Sep 2023 14:46:20 +0100 Subject: [address-policy-wg] 2023-04 Are anonymised assignment objects valid? In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: denis walker wrote on 28/09/2023 11:31: > We are talking about one sentence in the current address policy that > this proposal removes. that's ok: the RIPE Community is entitled to voice an opinion on changing RIPE policy. If this policy nullifies the requirement to register end-user PA assignments in the RIPE DB, I don't necessarily view this as a bad thing, given the poor quality of the existing data, and the fact that fixing this is - whether we accept this or not - a largely intractable problem. That said, it's important that any change of this scope should be done with the community's eyes open so that we can make an informed decision based on merit. Nick From me at cynthia.re Fri Sep 29 21:07:39 2023 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Fri, 29 Sep 2023 21:07:39 +0200 Subject: [address-policy-wg] 2023-04 Are anonymised assignment objects valid? In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: I think I mostly agree with Nick here and I feel like Tore is a bit dismissive of the concerns raised by denis. I don't really feel that strongly about this policy proposal in itself but I do now see that it is a significantly larger change than Tore suggests that it is. I wouldn't be surprised if more people who have said "+1" to this proposal did so without realizing that it's not such a minor change. As such, I really think that there needs to be more discussion about this in the context of changing a meaningful part of the policy. -Cynthia P.S. I want to make it clear that I don't think that Tore is being malicious in any way here but rather just focusing too much on the current RIPE NCC interpretation of the policy rather than what the policies actually say. On Fri, Sep 29, 2023 at 3:46?PM Nick Hilliard wrote: > > denis walker wrote on 28/09/2023 11:31: > > We are talking about one sentence in the current address policy that > > this proposal removes. > > that's ok: the RIPE Community is entitled to voice an opinion on > changing RIPE policy. > > If this policy nullifies the requirement to register end-user PA > assignments in the RIPE DB, I don't necessarily view this as a bad > thing, given the poor quality of the existing data, and the fact that > fixing this is - whether we accept this or not - a largely intractable > problem. > > That said, it's important that any change of this scope should be done > with the community's eyes open so that we can make an informed decision > based on merit. > > Nick > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From Brian.Storey at gamma.co.uk Sat Sep 30 01:03:14 2023 From: Brian.Storey at gamma.co.uk (Brian Storey) Date: Fri, 29 Sep 2023 23:03:14 +0000 Subject: [address-policy-wg] 2023-04 Are anonymised assignment objects valid? In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: Hi all, Outside of the detail from Denis and Tore, the discussion on this one seems quite limited, yet there is more than a hint that the proposed change conflicts with some core fundamental goals of the registry and the overarching purpose of the policy as is today. This is clearly an area of contention. I'm more than comfortable in saying that the policy interpretation by the RIPE NCC as detailed in the dialog between Tore and Angela is VERY surprising to me. It appears to go against conventional or widely accepted interpretation of the current policy (and those before it) and as an example the direction / sentiment set out within their own Database Training materials or videos:- https://www.youtube.com/watch?v=0RI5W3hqBug&list=PLC964CD89C4AE0337 https://www.youtube.com/watch?v=w6oUf7j4SME&list=PLC964CD89C4AE0337&index=7 As I've mentioned before, the policy as-is does appear open to interpretation in terms of what CONTENT goes into an End User Assignment INETNUM registration. I'm not saying that's wrong but I think it's important to distinguish between that and those who choose not to register anything; the latter being non-compliance or at least not able to adequately demonstrate that their assignments are regularly maintained. So whilst the policy isn't prescriptive in how you achieve the "must", it does seems like many have found a common approach with using a blend of the mandatory and optional attributes to satisfy the requirements of End user registration, in particular for each non-individual & non-P2P assignments. However contrary to this, it seems like there is a developing/developed view that if the attribute isn't mandatory, it doesn't count in the wider context. Whereas in reality the accepted convention is more a case of "if this mandatory attribute is populated this way", "use this optional attribute this way". It's not strict compliance but fulfils the objective. Yet, if we aren't actually required to publish end user names (based on the Q&A transcript provided by Tore), why are so many doing so? Rightly or wrongly, it would suggest to me there is some form of compliance or enforcement drift and therefore quite a gulf between the INTENT of the policy and what the enforced minimum requirements actually are. Or perhaps that same many have got it wrong, overreaching on what needs to be published, yet they don't think they have which emphasises the problem (if this discussion alone doesn't already prove that!). For me it comes down to this. As a community & considering the permitted exceptions (individuals & P2P assignments):- 1) Is the publication of End User entities for an assignment important? 2) Is the publication of a prefix assignment boundary between end users important? If the answer to either of those is yes, then I don't think this proposal should go forward in its current form & the current RIPE NCC interpretation of the current policy as shared by Tore should be challenged. If the answer to both is no, then it has legs but only for those reasons. Justifying it because some LIRs don't do what they are supposed to do isn't sufficient. That's what the Assisted Audit is for right? I recognise that the time between assignment & reassignment for some service providers is now substantially shorter, but arguably the likes of Virtual Service providers are better equiped than most to deal with that. Spinning things up and tearing them down is afterall their day to day. In either case, does consideration toward best practice & holding to higher standards have any weight? https://datatracker.ietf.org/doc/html/rfc3013#section-4.1 There is a side piece to this too & an area I commented on a couple of weeks ago regarding End User interests on the publication or not of their Business Name. Armed with the information now that publication of the End user names isn't mandatory (although previously believed to be a requirement - arguments challenging this aside) does explicit consent now need to be obtained to continue with that practice, if the LIR choses to continue with that approach? If the publication of an End User isn't backed up by a policy which we are bound to comply with contract / Terms & Conditions then continuing creates an exposure for new and existing entries? Given what is being discussed, the proposal or even the existing policy should be modified to be clear as to whether there is a condition here or not and in what form(s) this must take. I say this because the discussion being had here and the efforts made on those INETNUM entries which are there now (ours included) would indicate it isn't as clear as we thought it was. This discussion has made me feel uncertain about the existing policy but also juding the proposal because of it. The answers to those 2 questions is key. Either way, I want to make sure I'm falling on the right side of the policy & be able to justify how much or little effort we put in to the registry entries. Referencing some of the detail in this discussion as a means to determine that doesn't feel adequate. Many thanks, Brian -----Original Message----- From: address-policy-wg On Behalf Of denis walker Sent: Thursday, September 28, 2023 11:31 AM To: Tore Anderson Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid? Colleagues I know this is a very long email and no one has the time to read it, but I have at least put my points on record. This proposal claims to only be about adding a new, optional status value. It is claimed it doesn't permit anything else that isn't already possible with the current address policy. In particular it is claimed you can already have anonymous assignments in the RIPE Database. Some people do create such objects. The RIPE NCC audits don't question such objects. But is that right? There has been so much false and misleading information about this issue. I am going to have one last attempt to put the record straight. Then, if no one else cares, why should I? I have a bathroom to build... We are talking about one sentence in the current address policy that this proposal removes. A sentence that is the heart of assignment policy. The core of the public registry of public IP addresses. An English sentence that is so clear and obvious, it simply cannot be misunderstood or (mis)interpreted. And yet I am having to write an essay to try to explain what this clear sentence means. "When an End User has a network using public address space this must be registered separately with the contact details of the End User." Let me break it down into smaller segments to explain it's meaning: 'End User has a network' - a network for an End User 'using public address space' - the address space for the network is part of the public Internet 'must be' - MUST, not can, should, may, possibly, perhaps...MUST 'registered separately' - registered in the RIPE Database in a separate object, all alone 'contact details' - information that allows you to make contact with 'of the End User' - the End User who you want to contact This sentence only has one possible meaning. And that meaning says you cannot have an End User assignment in the RIPE Database that does not allow you to make contact with the End User (subject to the specified exceptions). This sentence and meaning are so clear it is impossible to write it any clearer. What matters today is the actual wording of the current address policy. But to understand some of that, we need to look at how we got here and some of the early definitions that are no longer included in the policy. So let's start with a history lesson. With my information archeologist's hat on, I've gone all the way back to 1990 to understand what the terminology in the address policy and the RIPE Database means. In the first version of the address policy ripe-065 RIPE NCC Internet Numbers Registration Procedures Publication date: 01 Jul 1992 It says: "This document describes the procedures for the reassignment of IP network numbers from blocks obtained from the RIPE Network Coordination Centre." ... "Full information about reassigned network numbers must be reported back to the RIPE NCC and the US NIC in full RIPE database format (ref ripe-13)." Then in ripe-13 RIPE Databases Publication date: 28 Aug 1990 It describes the network objects to include these attributes: ----------- tc -name of technical contact. This must be the same string as in the corresponding *pn entry. There must be such a person entry! ac -name of administrative contact. This must be the same string as in the corresponding *pn entry. There must be such a person entry! de -description of the network. Give organisation and place. Postal address and country are not needed, they can be found via the contacts. The country is given in *cy. ----------- Then in an example it includes: ----------- *de: CWI Ethernet (Classical) *de: Amsterdam *de: Netherlands ----------- So right from the start of registration we have had description attributes giving information about the name and location of the assignment holder. Then we move a few hops to ripe-136 European Internet Registry Policies And Procedures Publication date: 24 May 1996 This is starting to look a bit like modern address policy. Interestingly it actually defines some of the terms we have lost touch with over time. If you ask most people now what an admin-c contact is they don't know. Which is why many objects have the same entry for both tech-c and admin-c. But that is often wrong. Some definitions: End users are those organizations operating networks in which the address space is used. End users must provide and update registration data for the address space assigned to them. Local IRs are typically operated by Internet Service Providers (ISPs). Local IRs hold allocations of address space for assignment to end users. In some cases, the local IR assigning the address space is not run by the ISP that will provide connectivity. It is important to note that maintenance of the administrative information regarding the assigned address space is the responsibility of the IR that makes the assignment, and not of the ISP providing the connectivity. Requesters - In addition to these key players in the Internet Registry System, there are often consultants who set up and manage networks for end users. netname - a short, but semantically meaningful name descr - A short description of the organisation that will use the assigned addresses, in one or more fields. Typically the name of the organisation. admin-c - administrative contact persons. The administrative person specified in the admin-c field must be physically located at the site of the network. [Clearly the original definition of the admin contact means it must be someone at the site of the end user. This, with the descr fields, identifies and provides contact information for the end user.] tech-c - technical contact persons. The technical person specified in the tech-c field may be a network support person located on site, but could also be a consultant that maintains the network for the organisation. Submission of objects to the database is the final and required step in making an assignment. This step makes the assignment definite, and makes public information regarding the assignment available to anyone seeking it. [Again it is clear from the early days that the public registry was not only an operators phone book for solving network issues. Maybe this will bring to an end those endless arguments about whether LEAs have a right to access and use the information in the RIPE Database. "available to anyone seeking it"] >From ripe-140 European Internet Registry Policies and Procedures Publication date: 06 Sep 1996 Just for further clarity it describes the admin-c of an aut-num object as: "The administrative contact should be physically located at the enterprise requesting the AS number." which further clarifies the difference between the tech-c and admin-c generally. ripe-159 (29 Jul 1997) adds that the admin-c "The person does not have to have technical knowledge of the network." Then we get to ripe-234 IPv4 Address Allocation and Assignment Policies In The RIPE NCC Service Region Publication date: 14 Jun 2002 This is where we first get the differentiation between DSL connections and public networks. "However, four or more addresses (e.g. /30 or more) used on the End User's network need to be registered separately with the contact details of the End User." Almost the exact wording we still use today, 21 years later. Then ripe-288 IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region Date: 28 October 2003 We now have the exact wording that we have today (it is even in paragraph 6.2): "When an End User has a network using public address space this must be registered separately with the contact details of the End User." So we have had this principle with the exact same wording for 20 years. Every version of the address policy since then has included this exact line. (Incidentally one of the authors of this document was Leo, now co-chair of this WG) All these documents have been co-written by many people including the RIPE NCC founder, RIPE NCC CEO, RIPE chair, RIPE co-chair, AP-WG co-chair, former DB-WG co-chair, yet we seem to have collectively forgotten what many of these terms mean. So now let's come back to the present. How do these definitions change our perspective? The first thing to note is that these definitions are no longer written into the policy. They disappeared over 20 years ago. But, in the absence of any definitions in the current policy, and no community consensus over that time to change any of these definitions, it seems reasonable to apply those definitions from earlier versions of the same policy document. Especially as the database documentation still makes the clear distinction between a tech-c and an admin-c in line with those early definitions. Let's again look at that typical company operating a network with public address space. They may be technically competent, in which case the tech-c will provide contact details for their own engineers. If they don't have the technical skills someone else will manage the network for them. That could be the LIR, or an ISP (seperate from the LIR) who provides the connectivity services, or an independent consultant. Whoever it is, they should be listed as the tech-c contact person. When it comes to the admin-c, we now know who this is meant to be. It is someone, with or without technical skills, who is physically located at the site of the enterprise operating the network. Having that person's contact details, combined with the descr attributes that optionally specify the name and location of the organisation, we satisfy the current policy requirement "registered separately with the contact details of the End User". When an LIR manages the network for the End User, to replace both the tech-c and admin-c with the LIR's contact details is wrong, according to the current policy. The admin-c should always be a contact from the End User's site. As many LIRs do get that bit wrong, they often compensate by adding full name and address details of the End User in the descr attributes. That makes them still compliant with current policy as the assignment object still has the contact details of the End User. There are so many objects in the database like this. If the labour intensity of maintaining this data is one of the driving forces behind this proposal, why do so many LIRs put all that optional data into their objects? That takes a lot of effort. If an assignment is cancelled then re-assigned to another customer, they have to change the object to update this optional data. Without the optional data the same object would still be valid for the next customer without any update. They do it because they read the policy and understand that line ("When an End User has a network using public address space this must be registered separately with the contact details of the End User.") and knew they must include contact details for the End User. During this debate it has been said that the contacts are "the tech-c and admin-c, nothing more, nothing less". That is just wrong. Nothing in the current or any previous version of the address policy has ever said that. You cannot just invent conditions like this, out of nowhere. The descr attributes are contacts. A referenced organisation object provides contacts. There are other options for contact information. But the bottom line is, the assignment object MUST contain the End User's contacts (subject to the specified exceptions). So it is not policy compliant to have an assignment object that does not have contact details of the End User. If the RIPE NCC does not question this during an audit, they have got it wrong. They may have got it wrong for many years, but it is still wrong. We should not change the policy just because mistakes have not been corrected for a long time. So the answer to the main question is (finally), this proposal makes significant changes to assignment policy and allows the creation of anonymised assignment objects that the current policy does not allow. I will go further than this. If the current policy was correctly applied, it is not possible to aggregate assignments as they will all have different admin-c contacts. That means the question the community needs to consider is if it is now acceptable to allow anonymised assignment objects in the RIPE Database, possibly in significant numbers? If this proposal is accepted and the definition of admin-c is changed to what many people actually think it is, then the only End Users who will be publicly contactable are those who manage their own networks. Potentially ALL others can be anonymised, with or without aggregation. Now just to finish off I will address the Q&A. On Tue, 26 Sept 2023 at 15:41, Tore Anderson wrote: > > Hi Denis, > > It would appear to me that your opposition to 2023-04 is largely based > on the premise that it introduces a new possibility for anonymous > assignments, a change which you do not want to see happen. This > premise also appears to underpin many of your musings in your bigger picture> message. Then you didn't read it. > I disagree with this premise, as I believe this possibility is already > there in current policy. "When an End User has a network using public address space this must be registered separately with the contact details of the End User." > > Rather than decide to agree to disagree on that point, or endlessly > quarrel about it, I realised that it does not really matter what you > or I believe the policy requirements are - what matters is the RIPE > NCC's understanding of the policy and how they are implementing it. So > I simply asked their Policy Officer (Angela) to clarify this. What matters is are they implementing it correctly? > > Her answers, which I with permission quote in full along with my > questions below, unequivocally confirms that that current policy does > indeed allow assignments to be registered anonymously in the RIPE > database. Hence, your opposition to proposal 2023-04 in this regard > appears to rest on a fundamentally flawed assumption. "When an End User has a network using public address space this must be registered separately with the contact details of the End User." > > > Tore: individual and that is not used solely for the connection of an End > User to a service provider. > > 1. Does current address policy as implemented by the NCC allow an End > User to delegate/outsource the contact information represented by the > mandatory "tech-c" and "admin-c" attributes to another entity, > typically (but not necessarily) the issuing LIR? (There does not appear > to be any disagreement on this point, but I include this question > anyway in case we are both wrong.)> > > Angela: delegate/outsource the contact information represented by the mandatory > "tech-c" and "admin-c" attributes to another entity, typically (but not > necessarily) the issuing LIR.> No it is not correct. The administrative person specified in the admin-c field must be physically located at the site of the network. Therefore it cannot be outsourced. > > Tore: <2. Assuming "yes" to question 1, for an assignment where the > "tech-c" and "admin-c" has been delegated in this manner: Does current > address policy require the corresponding "inetnum" database object to > contain some additional contact information, that is not delegated to a > third party, i.e., it must be refer to a point of contact that is > handled in-house by the End User him/herself?> > > Angela: "inetnum" database object to contain some additional contact > information that is not delegated to a third party. > LIRs can use the "netname" attribute to link assignments to end users > and their contact details in internal records. "When an End User has a network using public address space this must be registered separately with the contact details of the End User." > > There is a particular case: when the RIPE NCC receives a request for > assigning an AS number to an End User using a PA assignment, the IPv4 > network to be announced by the requested AS must be registered in an > "inetnum" object showing the End User's name. This can be in the > "descr" attribute or recursively in the "org" object added as > attribute.> This does not apply to most of the assignments in the database where the optional descr attributes have been added with name and address of the End User > > Tore: <3. Assuming "yes" to question 2, what kind of other contact > information is required, and in which "inetnum" database attribute(s) > must it be located? Here are some possible examples off the top of my > head, would any or all of these satisfy the policy requirement for an > in-house non-delegated contact information? > 1. A street address > 2. A (snail) mail address > 3. An e-mail address > 4. A fax number > 5. A phone number> > > Angela: End Users' contact details is to create an "org" object to be added as > optional attribute in the "inetnum" object. > In "org" objects name, address and email are mandatory. > In "inetnum" objects the mandatory contact information are "admin-c" > and "tech-c".> "When an End User has a network using public address space this must be registered separately with the contact details of the End User." > > Tore: <4. Assuming "yes" to question 2, is it mandatory to identify the > End User by name, or would it be sufficient with, e.g., a street > address without an organisation name (assuming there is only a single > entity located at that address), a post box snail mail address, a > generic user123 at gmail.com e-mail address, or a phone/fax number that is > not listed in the white or yellow pages?> > > Angela: "When an End User has a network using public address space this must be registered separately with the contact details of the End User." > > Tore (in a new e-mail): just to make absolutely, 150%, certain I do not misunderstand you and > end up misrepresenting you to the mailing list: > > 1. When you write assignments to end users and their contact details in internal > records>, this "can" is a MAY, not a MUST, to use IETF lingo? That > is, the LIR is free to instead use the "inetnum" attribute, i.e., > the IP address(es), to link the assignment to the End User in their > internal record? If that is the case, would it be correct to say > that the LIR are free to set the "netname" attribute to essentially > anything, including a meaningless string of random characters?> > > Angela: three questions. > Please also consider that the "netname" is not required to be > unique, LIRs can use the same one for multiple assignments.> > > Tore: <2. When you write details is to create an "org" object to be added as optional > attribute in the "inetnum" object>, this is also a MAY, not a MUST? > That is, the LIR is free to omit the "org" attribute, even though > the only other contact information contained in the object is the > (LIR-delegated) "tech-c" and "admin-c" attributes?> > > Angela: though the only other contact information contained in the object is > the (LIR-delegated) "tech-c" and "admin-c" attributes. > If the LIR requests an AS number on behalf of an end user to > announce a PA assignment, then the PA assignment MUST include the > legal name of the end user in the "descr" attribute or in the '"org" > object set as "org" attribute in the "inetnum" object.> > "When an End User has a network using public address space this must be registered separately with the contact details of the End User." The administrative person specified in the admin-c field must be physically located at the site of the network. > Tore: <3. To use a concrete example: Let's say > delegated 192.0.2.0/25 to the End User . > (CarFactory GmbH is not an individual, and the assignment is not > used solely for the connection to the provider, nor to justify an > application for an AS number). SuperLIR inserts the following > minimal database object: > > inetnum: 192.0.2.0 - 192.0.2.128 > netname: ABCDEFGHIJKLMNOPQRSTUVWXYZ > country: DE > admin-c: SUPERLIR-NOC-RIPE > tech-c: SUPERLIR-NOC-RIPE > status: ASSIGNED PA > mnt-by: SUPERLIR-MNT > source: RIPE > > In the event of an audit, SuperLIR GmbH will be able to inform the > RIPE NCC auditors that this object has been delegated to CarFactory > GmbH. > > Is the above registration compliant with current IPv4 address > policy, or will the auditors demand any kind of changes be made?> > > Angela: policy. During an audit we could ask the LIR whether the assignment > is still in use. It does not matter for the RIPE NCC who is using > the assignment, as long as the LIR is maintaining the registration > up to date and is able to contact the end user. This means that if > the LIR moves the assignment delegation from CarFactory GmbH to > another end user in the same country for which is acting as "admin- > c" and "tech-c", the "inetnum" object would still be valid. It is > the LIR's responsibility to keep their internal records up to date > accordingly with the new end user.> "When an End User has a network using public address space this must be registered separately with the contact details of the End User." The above object is not compliant and the audit should pick that up > > > In light of the above, I hope that you will reconsider your opposing > arguments and either withdraw them or restate them in a way that does > not rely on this incorrect assumption. Anticipating this, I will only > address your remaining points that are not based on the > misunderstanding that 2023-04 opens up for anonymous assignments. > My assumption is correct. cheers denis co-chair DB-WG -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe .net%2Fmailman%2Flistinfo%2Faddress-policy-wg&data=05%7C01%7Cbrian.storey%40 gamma.co.uk%7C2da065f0adae46dcb9c308dbc00e1fc3%7C743a5d9f11234f3f8fcf5766b8a d8bf9%7C0%7C0%7C638314939120399679%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fXEe nEm7tmtgXCFJsgLGbcHyJMjOjghY%2F29nKvjUf5s%3D&reserved=0 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4577 bytes Desc: not available URL: From nick at foobar.org Sat Sep 30 13:49:56 2023 From: nick at foobar.org (Nick Hilliard) Date: Sat, 30 Sep 2023 12:49:56 +0100 Subject: [address-policy-wg] 2023-04 Are anonymised assignment objects valid? In-Reply-To: References: <3a34fcfa-89eb-5008-fe5b-adff38ca03c3@ripe.net> <3789901f-13c2-4432-a990-260c754d3ba6@apex.dp.ua> <8ed395a5710513f8a135eb04bfea38e25118acc6.camel@fud.no> <20e0e06594a555f3780f262e0f29ed38cad32eac.camel@fud.no> <195a063ef4b9582c7558370755a82b0740f255bd.camel@fud.no> Message-ID: <050e8868-decb-6b08-20fd-29a5cc7b7cd4@foobar.org> Brian Storey wrote on 30/09/2023 00:03: > For me it comes down to this. As a community & considering the permitted > exceptions (individuals & P2P assignments):- > > 1) Is the publication of End User entities for an assignment important? > 2) Is the publication of a prefix assignment boundary between end users > important? Brian, thanks for this thoughtful analysis of this proposal. These two questions are indeed the crux of this issue. I'm also surprised at Angela's answers, but let's deal with the intent of the policy for the time being, namely whether the RIPEDB should or shouldn't include information about end user assignments and the entities to which they are assigned. My take is that, in theory, there would be a good deal of merit in publishing both if there were some way of ensuring that this data was accurate and well-maintained. However, from a practical point of view, there's a large amount of inaccurate and stale data in the RIPE database. A lot of effort has been expended over the last 30 years to attempt to address this problem, but no good solutions have been found and the outcome If we haven't solved this problem in 30 years, and if there are no proposals on the table to address data quality issue, I'd speculate that it's unlikely we'll solve the RIPE DB's data quality issues any time soon, and maybe now it would be appropriate to have a good, hard think about whether it's worth keeping this policy at all. But, speculation is not an appropriate substitute for fact. A better starting point for addressing the underlying data quality issue might be to formally measure it. There's ~4.7m inetnum/inet6num PA assignment registrations in the database. A quick check with a sample size calculator suggests that examining around 500 random inetnums / inet6nums for an a/b data quality outcome would give a result with 98% confidence, ~5% error margin. Is there an appetite for examining this in the DB-WG + the RIPE NCC? Nick