From the Legal Impact section, "the RIPE NCC would like to note that it is solely the responsibility of the member to choose which contact
Colleagues I am so disappointed by this second version of the proposal and the impact analysis. Let's start with the changes to the proposal. The addition of 'Arguments opposing the proposal'. This is completely false and misleading information. This summary of the arguments during the discussion phase is just unbelievably wrong. No one even made the argument that you cannot currently create an object with the mandatory contacts delegated to another party. In regard to these mandatory contacts I proved that the admin-c must be a contact from the End User's enterprise. This is based on the definition of admin-c and the clearly expressed, current version of the address policy. In particular that well quoted 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." Very clear, not subject to interpretation and non negotiable under the current policy and all versions of the policy going back over the last 20 years. In the PDP policy it says "At the end of each phase of the process, one of the chairs of the relevant WG will summarise the state of discussion on the WG mailing list." This still has not been done. Then we have this crazy 'counter argument'. Let's break it down. "It is already possible to create such assignments under the current address policy." No one has disputed that. "The RIPE NCC confirmed that they consider these assignments to be policy compliant and do not require them to be modified during audits." During my detailed arguments I proved that this interpretation by the RIPE NCC of the current IPv4 address policy, and all the versions over the last 20 years, is incorrect. According to the now famous 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 the historic, but still valid, definition of the admin-c, it is clear that the admin-c must be someone from the End User enterprise. Therefore delegating this to another party is a violation of the policy. Many LIRs who create assignment objects in the RIPE Database have understood the current and previous address policy. Even though they sometimes delegate the admin-c they compensate by adding the name and address of the End User in the optional descr attributes. This is not strictly compliant but does adhere to the principle of the policy. This proposal drops this principle. Despite the RIPE Chairs and RIPE NCC CEO's recent policy about RIPE NCC staff being more involved in RIPE community affairs, no one from the RIPE NCC has joined this discussion to explain the NCC's interpretation of the current and previous address policy. "Therefore, the proposed policy change simply leaves the status quo unchanged." This is straight out of the Donald Trump fake news instruction manual. When you say something that is not true, keep repeating it, over and over and over again. Never acknowledge anyone who questions it, never discuss any arguments raised against it, just keep repeating it. Over time some people will start to believe it. I have argued in GREAT detail exactly what this proposal does. By dropping that famous 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." the proposers fundamentally change address policy and the nature of the public registry. I have presented 'walls of text' to explain this, which most people probably have not read. This change allows ALL End Users to be totally anonymised. Even those who technically manage their own network and handle their own abuse complaints, they can still be anonymised and have public contact details available. For LIRs who do not want to put any details of their customers into the public registry, this change allows for this complete anonymity. And there are many LIRs who already follow this philosophy, despite current policy. This change will reduce the RIPE Database public number registry to the same useless level as a domain name registry. ALL details of End Users can be hidden behind a court order firewall. Following the Trump instruction manual, the proposers still refuse to acknowledge that this proposal changes anything. They still refuse to engage with the community in a real discussion on this point. They still keep repeating the fake news. It also says in the PDP policy "In all phases of the RIPE PDP, suggestions for changes to the proposal and objections regarding the proposal must be justified with supporting arguments and then addressed adequately by the proposer or by any supporter of the proposal." The proposers will not even acknowledge my objections, will not discuss them and therefore have not adequately addressed them. Then we move on to the impact analysis (IA). This reads as an 'Impact on the RIPE NCC Analysis'. There is no mention at all of the impact on stakeholders who use the data contained within the RIPE Database. In the PDP policy it does say the IA will contain 'Impact on the registry'. This is interpretable. I would suggest this covers the public registry as well as the RIPE NCC's internal registry databases. But this IA does not even mention the fundamental change to address policy and the potential consequences to the data contained within the public registry or the impact that may have on various stakeholder groups using the RIPE Database. It follows the same line as the proposers by failing to even acknowledge the severity of the change this proposal has on the public registry. details to insert in the INETNUM object." Also from the 'RIPE NCC's Understanding' it says "Acceptance of this proposal will not change the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this will remain their decision." This is also not true. The policy is very clear. "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 the current policy dictates to the LIR the type of the contact details they must enter. Even though the individual contact within that type is their choice. So with the arguments from the discussion phase having not been summarised and the objections not having even been acknowledged by the proposers, and certainly not addressed by them, I still don't see how this proposal can move to the review phase. cheers denis On Tue, 21 Nov 2023 at 11:13, Angela Dall'Ara <adallara@ripe.net> wrote:
Dear colleagues,
Policy proposal 2023-04, “Add AGGREGATED-BY-LIR status for IPv4 PA assignments”, is now in the Review Phase.
The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance.
This proposal has been updated and it is now at version 2.0. The proposed policy text did not change, the only difference is that the section "Arguments opposing the proposal" includes a reference to the last round of discussion.
The RIPE NCC has prepared an impact analysis on this proposal to support the community’s discussion.
You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2023-04 https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis And the draft document at: https://www.ripe.net/participate/policies/proposals/2023-04/draft
As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue the discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg@ripe.net before 20 December 2023.
Kind regards, Angela Dall'Ara Policy Officer RIPE NCC
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg