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

Hi Angela

Thanks for your response. Some of your comments are valid as
individual points, some less so. But putting these comments together
does not create a complete story to support this proposal. As always I
will go through them below one point at a time.

On Thu, 23 Nov 2023 at 18:06, Angela Dall'Ara <adallara at ripe.net> wrote:
>
> 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.

If the RIPE NCC has misinterpreted current address policy and the way
assignment information is currently evaluated is not correct, then not
changing anything is not an improvement.

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

And the "admin-c:" was defined in the early days of the registry to be
someone from the End Users enterprise. As far as I can see there has
never been any discussion or consensus on changing that definition.

> The contacts are
> registered by the LIR as agreed with the End User.

...and must be in accordance with RIPE policy which says the
assignment must contain the End User's contact details.

>
> 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

The LIR does have the freedom to offer themselves as a point of
contact for their End User. BUT the policy is still clear, the
assignment MUST contain the contact details of the End User.

> as well as having their maintainer in the
> IPv4 PA assignments they register.

It is normal practice for ALL pa assignment objects to have only the
LIR's mntner on them. This is a matter of managing the data set in the
database rather than related to responsibilities implied by that data.

> 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.”

I wrote the T&C so I know exactly what I had in mind when I wrote each
article. I also know what I did not take into account because, at the
time, I wasn't aware of it. There are mistakes in the T&C, which I
accept responsibility for. But I have stopped criticising documents as
I get personally attacked for doing so. Probably also for documents
that I wrote. I am not allowed to even criticise my own mistakes. This
is one of those paragraphs that is completely wrong, for several
reasons. But that is for another day...a day that will never come as
no one cares about mistakes in documents...even though there are so
many of them.

But as for this issue it is irrelevant. Even as written, it is
concerned about maintaining the data set in the database, not what
that data means.

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

OK this is a bit confused. First of all the RIPE NCC never enforced
the End User’s organisation name in the mandatory "descr:" attributes.
This was only for allocations and PI assignments. LIRs still have the
option to add this data for End Users in the now optional descr
attributes, and many still do so in order to comply with current
policy.
(btw the video is wrong. It implies that an assignment object is
created by webupdates, which only a very small LIR is likely to
do...but that is another story)

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

A lot of assignments have not changed in the last 10 or 20 years. Some
of the assignment data is very static. There are some more recent
network arrangements, like cloud systems, where they have become very
dynamic.

> 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”.

The database documentation is based on other documents. The current
address policy clearly states that assignments MUST be registered with
the End User's contact details. Also many documents refer to the
"admin-c:" attribute. The first definition that seems to exist of the
'admin-c' is in ripe-136 that defines it as someone who "must be
physically located at the site of the network".  Then ripe-140
clarified it in the context of an aut-num as someone who  "should be
physically located at the enterprise requesting the AS number.". Then
ripe-159 added to the definition of admin-c that "The person does not
have to have technical knowledge of the network." This definition of
admin-c has never been discussed since or changed by any community
consensus.

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

So am I :)

cheers
denis

>
> 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/
>