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

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 <address-policy-wg-bounces@ripe.net> On Behalf Of Tore Anderson Sent: Monday, September 4, 2023 12:22 PM To: Andrii Syrovatko <andrey_syrovatko@trifle.net>; address-policy-wg@ripe.net; adallara@ripe.net Cc: APEX NCC ORG <registry@apex.dp.ua>; Trifle NOC <noc@trifle.net> 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

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.

On 2023 Sep 11 (Mon) at 19:14:05 +0200 (+0200), denis walker wrote: :On Mon, 11 Sept 2023 at 18:33, Peter Hessler <phessler@theapt.org> 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!

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

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 <ripedenis@gmail.com> 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 <tore@fud.no> 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://lists.ripe.net/mailman/listinfo/address-policy-wg

--

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

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

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 <ripedenis@gmail.com<mailto:ripedenis@gmail.com>> 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 <tore@fud.no<mailto:tore@fud.no>> 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://lists.ripe.net/mailman/listinfo/address-policy-wg

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

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 <nick@foobar.org> wrote:

...

...

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

denis walker wrote on 24/09/2023 17:12: 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

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 <tore@fud.no> 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

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://lists.ripe.net/mailman/listinfo/address-policy-wg

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 <tore@fud.no> 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@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

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 <nick@foobar.org> 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://lists.ripe.net/mailman/listinfo/address-policy-wg

Hi, and sorry for not engaging in this discussion at an earlier point in time. On Mon, Oct 2, 2023 at 6:09 PM Sander Steffann <sander@steffann.nl> wrote:

I personally have no problem with this change. I recognise the importance of documenting every end-user’s contact details, as end-users were often actively involved in running their network. But in this day and age of outsourcing, the value of the information is much lower than it used to be.

I’m not saying that there is no value anymore! There are many cases where resource holders are actually network operators with relevant information in the DB, but I don’t think that changing the policy will cause them to suddenly stop creating DB objects. And for those who don’t *want* to document things, they have already found ways around that in the current implementation of the policy.

I sort of agree with the reasoning, however: sloppy contact details have real world consequences. They result in blocklisting of entire IP ranges, for email, or even for other kinds of network traffic, because the contacts listed are "dummy" contacts. Denis is, although wordy and repetitive, pretty much dead on with the reasoning. However, I do not think it is necessary to require person names or other direct PII. Roles and role addresses could be encouraged. In some parts of the Internet, there are regulatory requirements that abuse departments answer and deal with complaints in a timely manner. These time limits are fairly short. Just because e.g. Google and Microsoft laugh in the face of such requirements and provide dysfunctional contact points, does not make it okay, nor an obvious matter of policy change to remove the requirement.

I think the best way forward would be: - encourage operators to document *useful* contact info (a SHOULD) - don’t require what we don’t/won’t/can’t enforce (no MUST)

I disagree, the MUST should be there.

- realise that the current internet is not the internet that this DB was designed for

Might as well stop issuing policy at all, then.

- align IPv4 and IPv6 requirements/standards where possible

I see no reason why policyregarding contact details should differ between IP versions. -- Cheers, Jan

On Tue, 3 Oct 2023 at 17:00, Sander Steffann <sander@steffann.nl> wrote:

...

- realise that the current internet is not the internet that this DB was designed for

Might as well stop issuing policy at all, then.

The thought did cross my mind ;)

or redesign the DB to fit the internet we have today!!! An option that still, nobody will even discuss. How much more proof do we need that this 25 year old design needs attention? (Well you could read Ed's latest impact analysis on a small DB feature change to assignments.) cheers denis co-chair DB-WG

Cheers! Sander

--

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

Hi Denis, Thank you for explaining how you see your role. I would like to clarify a few things you mentioned in your mail. I hope this will be useful especially for RIPE community members who might not have the long history in the community that some of us have. 1. Regarding the role of the RIPE Community: The fact that the RIPE community is not a legal entity and that it is open to anyone who wants to participate, does not mean it is "undefined". From the beginning, the RIPE community has agreed to document its decisions and processes as RIPE documents that are publicly accessible. In the RIPE Terms of Reference (ripe-001) [1] the mission and scope of RIPE is defined. We have a clearly defined policy development process and clearly defined governance processes that the community agrees to follow. Decisions are made by consensus and RIPE documents go through a defined community review. 2. Regarding the relation between RIPE and the RIPE NCC: The RIPE NCC clearly states its role as the secretariat of RIPE in its mission, activity plan and budget. These are formal documents the RIPE NCC members vote on. Also, there is a long track record of the RIPE NCC following guidance from the RIPE community. 3. Regarding the role of a chair: It is the responsibility of a chair to listen and to guide discussions, to summarise and to actively build consensus. Those of us who serve in a special function or have a leadership role are aware of the fact that people tend to see us as being in that role. Therefore we need to take extra care if and when we decide to participate in a discussion as an individual. Kind regards, Mirjam (RIPE Chair) [1] RIPE Terms of Reference https://www.ripe.net/publications/docs/ripe-001

Denis, Yes, you are correct that that signing your emails saying you are co-chair of DB tells the reader that you are speaking on behalf of the working group. That may or may not be your intention, but that is how people are reading it. No longer signing your emails "co-chair" would be a dramatic improvement, for sure. You could also sign them as "not speaking as co-chair" to be explicit. A lot of the critisim against you has been based on the understanding that you are acting as a dictator and pushing your agenda. You might not agree, but that is how I view your behaviour as co-chair. -peter On 2023 Oct 16 (Mon) at 21:09:47 +0200 (+0200), denis walker wrote: :Hi Mirjam : :Thanks for the clarifications. On points 1 and 2 I bow to your better :judgements. : :For point 3 I see your view. But I think I get singled out for unfair :criticism here. During my reappointment as co-chair of the DB-WG some :people heavily criticised me for taking part in discussions on mailing :lists whilst being a co-chair. I believe that was personal and not :objective criticism. It was suggested that 'I' am doing something no :other chair has ever done and it is wrong. They have short memories. :The previous chairs to the current set for the DB-WG were often :heavily involved in discussion on the database and other mailing :lists. The chairs before them (including the original chair) were also :often involved in discussions on multiple lists. So I haven't started :a new trend. The (co) chairs of the DB-WG (and perhaps other WGs) have :been involved in discussions on various mailing lists since the lists :started in 1992. : :Another interesting observation is that before the current chairs of :the DB-WG, ALL previous chairs only ever signed any email with their :first name. None of them ever signed anything 'as' a co-chair. Looking :at other mailing lists, including this AP-WG, most chairs :intermittently sign emails (at least on their own list) with or :without the chair title suffix. Again this goes back to the beginning :of time. So there doesn't seem to be any convention on how chairs sign :emails. Maybe I'll just sign with my name (as many others do), then I :can't be criticised for wearing the wrong hat. : :cheers :denis : :On Mon, 16 Oct 2023 at 16:44, Mirjam Kuehne <mir@zu-hause.nl> wrote: :> :> Hi Denis, :> :> Thank you for explaining how you see your role. :> :> I would like to clarify a few things you mentioned in your mail. I hope :> this will be useful especially for RIPE community members who might not :> have the long history in the community that some of us have. :> :> 1. Regarding the role of the RIPE Community: :> :> The fact that the RIPE community is not a legal entity and that it is :> open to anyone who wants to participate, does not mean it is "undefined". :> :> From the beginning, the RIPE community has agreed to document its :> decisions and processes as RIPE documents that are publicly accessible. :> In the RIPE Terms of Reference (ripe-001) [1] the mission and scope of :> RIPE is defined. We have a clearly defined policy development process :> and clearly defined governance processes that the community agrees to :> follow. :> :> Decisions are made by consensus and RIPE documents go through a defined :> community review. :> :> 2. Regarding the relation between RIPE and the RIPE NCC: :> :> The RIPE NCC clearly states its role as the secretariat of RIPE in its :> mission, activity plan and budget. These are formal documents the RIPE :> NCC members vote on. :> :> Also, there is a long track record of the RIPE NCC following guidance :> from the RIPE community. :> :> 3. Regarding the role of a chair: :> :> It is the responsibility of a chair to listen and to guide discussions, :> to summarise and to actively build consensus. :> :> Those of us who serve in a special function or have a leadership role :> are aware of the fact that people tend to see us as being in that role. :> Therefore we need to take extra care if and when we decide to :> participate in a discussion as an individual. :> :> Kind regards, :> Mirjam :> (RIPE Chair) :> :> :> [1] RIPE Terms of Reference :> https://www.ripe.net/publications/docs/ripe-001

We simply cannot get many people to talk about many of the RIPE Database issues.

perhaps wg members are deterred by the walls of text with strong directives and opinions from a dominating co-chair (who lost the election but somehow is still here)? nothing the db wg does is worth the effort and pain, so we just go have coffee and get back to work. randy

People, could we take a minute and reflect on this thread's subject? "[address-policy-wg] 2023-04 Who do I speak for?" — this is the AP wg's mailing list, and the discussion is not at all about something related to Address Policy. All the prior talk about the RIPE DB doesn't belong here, either. If changes to the (operation or design of the) RIPE DB require changes to Address Policies, let's discuss about it here. Anything else, AFAICS, belongs into its own wg and accompanied mailing list. Thanks, -kai (writing as a netizen)

Am 17.10.23 um 11:50 schrieb Jim Reid:

IMO a WG for this isn't necessary or desirable.

Well, those two sentences were not intended to be read nor understood independently of another. But since you did, please be reminded about https://lists.ripe.net/mailman/listinfo/ripe-list — Reply-To is set appropriately. Regards, -kai

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 <address-policy-wg-bounces@ripe.net> On Behalf Of denis walker Sent: Thursday, September 28, 2023 11:31 AM To: Tore Anderson <tore@fud.no> Cc: address-policy-wg@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 <tore@fud.no> 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@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 -- 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

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 <tore@fud.no> Sent: Tuesday, September 12, 2023 7:52 AM To: Brian Storey <Brian.Storey@gamma.co.uk>; address-policy-wg@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