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 <adall...@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
--
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
