Hello Denis, As proposers, we cannot address your objections against the RIPE NCC’s Impact Analysis, as we had no hand in producing it. However, we will try to address your points below that have not already been discussed at length. See inline:
Policy is made by the community. If the RIPE NCC's interpretation of a policy point is not correct then the community can require that the RIPE NCC re-evaluates their interpretation.
On this, we agree 100%. The question then becomes: is there someone willing to submit a policy proposal that would require that the RIPE NCC re-evaluate their interpretation? If there is, it would be prudent to put 2023-04 on hold, pending the outcome of that proposal. If not, that essentially amounts to a tacit acceptance by the community that the RIPE NCC’s interpretation of the current policy is correct, and we can proceed with 2023-04.
There is a lot in this paragraph. The practice of documenting End User contact details in the optional "descr:" attributes is already widespread. That is likely because so many LIRs do understand the current policy. They have delegated the contact details in the mandatory attributes. But they realize the policy requires End User contact details so they add those details in other attributes. Given that you have put so much emphasis on the 'manual effort required to create assignment objects in the RIPE Database' I am sure so many LIRs have not entered this optional detail without good reason.
The practice differs greatly between LIRs. Some LIRs create database objects that are rife with optional information not mandated by policy (information about BGP communities, for example), while others prefer to create rather minimal objects that contain only the mandatory attributes. Your assumption that LIRs that include End User contact information in descr: do so because they believe policy compels them to may well be true for some LIRs, but other LIRs might do so out of their own free will. Neither of us can't know with any degree of certainty which is the most common case; trying to quantify the two groups of LIRs would be pure conjecture. That said, it is very easy to demonstrate that the «out of their own free will» group of LIRs does exist and is significant in size. You can do that by downloading the inet6num database contents from the FTP and looking at the objects with the status ASSIGNED. You will find that there are *many* objects that contain the End User’s name, address, and other information in descr: None of that information is there because the LIRs in question have interpreted the policy to require them to publish this information, as the sentence «When an End User has a network using public address space this must be registered separately with the contact details of the End User» does not occur in the IPv6 policy. The LIRs could easily have minimized their assignments, removing all descr: attributes, and/or registered them as part of an AGGREGATED-BY-LIR object. They have chosen not to do so, however. It seems safe to assume, therefore, that at least some of the LIRs that publish the same data in IPv4 inetnum objects do it voluntarily and not because they believe IPv4 policy compels them to.
Just as with the IA you have the 'person' mindset lock. Contacts should be roles, not people. As suggested in the privacy discussion last year, the roles can include optional person names if the people so wish. We should all stop using the term 'contact person' and refer to 'contact role'
The policy needs to apply to assignments made to large enterprises with a dedicated NOC role, and to tiny one-person businesses whose only contact information is the owner’s personal Gmail address and mobile phone number. It is not feasible to require LIRs to only make assignments to End Users in the first category. It needs to also take into account End Users in the second category, whose contact person does not consent to the publication of their personal information in the RIPE database.
You have been very selective here in your interpretation of the stated goals of the registry system. Firstly it does not state that 'uniqueness' and 'troubleshooting' form an exclusive list of the reasons for a public registry. Over the years the registry has evolved to the needs of other stakeholder groups. But if you want to take this wording literally it also says "The provision of a public registry documenting address space allocations and assignments must exist." An aggregation does not document assignments.
Note that the IPv6 policy (section 3.3) contains very similar wording: «Internet address space must be registered in a registry database accessible to appropriate members of the Internet community.» The community has decided that AGGREGATED-BY-LIR is compatible with this goal in the context of IPv6 assignments. Is there something unique about IPv4 assignments that makes «The provision of a public registry documenting address space allocations and assignments must exist» not equally compatible with AGGREGATED-BY-LIR? Best regards, Tore and Jeroen