[address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

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.

>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
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 at 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 at 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://mailman.ripe.net/