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

Dear Denis,

If the proposal 2023-04 is accepted, this would not cause any change in 
the way we conduct our audits and evaluate the registration of PA 
assignments.

In IPv4, the mandatory contact information for PA assignments is 
provided by the “admin-c:” and “tech-c:” attributes; these must allow 
the RIPE NCC and other RIPE Database users to contact the End User 
regarding technical or administrative issues. The contacts are 
registered by the LIR as agreed with the End User.

As LIRs are free to choose how to provide services and to who, this 
includes their freedom to take over the responsibility as the point of 
contact for their End User as well as having their maintainer in the 
IPv4 PA assignments they register.
This is in line with the Database Term and Conditions statement in 
“Article 6 - Responsibilities”:
“The Maintainer is responsible for keeping all data maintained by them 
accurate and up-to-date, including correct Contact Details. The data 
must be good enough to allow the RIPE NCC to contact the Maintainer or 
Registrant within a reasonable time without having to get information 
from another source.”

Following the discussion in the Database WG the “descr:” attribute 
became optional for all object types in 2016. Since then, the RIPE NCC 
stopped enforcing the registration of the End User’s organisation name. 
LIRs still have the option to add this information in the “descr: 
attribute, by adding it to the “remarks:” attribute or in the “org:” 
attribute (provided they created an organisation object).
This is reflected in the tutorial and training currently provided by the 
RIPE NCC: https://www.youtube.com/watch?v=w6oUf7j4SME.

PA assignments are not maintained by the RIPE NCC. They are very dynamic 
elements of the resource registration in the RIPE Database, and we do 
not receive any notification about their creation, updates and deletions.
Additionally, the RIPE NCC is not in the position to confirm that the 
"admin-c:" contact is registered following the guidelines of the RIPE 
Database documentation (which is not a RIPE policy) where it is written 
that the “admin-c:” “must be physically located at the site of the 
network” or “must be the contact details of an on-site administrative 
contact”.

I see that this topic is in the agenda of the APWG session at RIPE 87 
and I’m looking forward to follow this interesting discussion.

Kind regards,
Angela

Angela Dall'Ara
Policy Officer
RIPE NCC


On 23/11/2023 07:17, denis walker wrote:
> 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/