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

On Wed, 2023-11-29 at 12:28 +0100, Peter Hessler wrote:

I mentioned this during the WG session but want to bring it up on the mailing list, what is the definition of assignment-size.

In the IPv6 implementation of AGGREGATED-BY-LIR there is an assignment-size attribute, which is proposed to be optional for the IPv4 version.

From the inet6num documentation:  "assignment-size:" - This specifies the common size of all  individual assignments aggregated into one block with the status  'AGGREGATED-BY-LIR'. This attribute is required to be present if the  inet6num object has this status. The individual assignments do not need  to be represented in the RIPE Database. But one or more assignments may  be included if the member wishes to specify them for any reason.

While there is no definition of what "size" means, my understanding is that the technical implementation follows the implemention requirements of inet6num objects, which is the CIDR size.

However, in IPv4 it is allowed to do CIDR _or_ an arbitrary range of addresses.  So if one were to create this inetnum object:

  inetnum: 192.0.2.0 - 192.0.2.255   netname: customers of example   status: AGGREGATED-BY-LIR   assignment-size: 32   ...

Here the assignment size is ambiguous.  Is it 32 addresses aka a /27, or is it a /32 aka 1 address.

I propose that we define this to be a CIDR assignment and they put in the number of bits of the netmask, so the above example would be assignment-size of /32.

Hi Peter, Agreed 100%, that is the intuitive understanding, especially considering that it is already in use like that for inet6num. I propose that we simply ask the RIPE NCC (hello Angela!) to confirm that their intended implementation of assignment-size for IPv4 inetnum is a CIDR prefix length. If it is, and there are no opposing voices against defining it in that way, I believe there should be no need to do a v3 of the proposal just to state this explicitly. (I also suggest that while the NCC is at it, they should document assignment-size as being a CIDR prefix length for inet6num as well. As you point the formal definition is not crystal clear there either, which was a bit of a surprise to me, honestly. But all current inet6num objects have an assignment-size within the range 31-128, so I guess LIRs simply get it - unless the database software enforces it by rejecting updates with values above 128.) Tore

Hi, On Wed, Nov 29, 2023 at 12:28:04PM +0100, Peter Hessler wrote:

I propose that we define this to be a CIDR assignment and they put in the number of bits of the netmask, so the above example would be assignment-size of /32.

Seconded. Well spotted. Maybe even make the syntax require the "/", at all times, so it's visually clear right away. "This is a /32, not a 32 which might be either" gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Colleagues Here we go again. Let me start by saying that the emphasis and phrasing of both this email that I am replying to and the impact analysis seem to have been carefully chosen to show this proposal in a good way. What I mean by this will become apparent as you read on. Just to be clear, I object to this proposal. The discussion at RIPE 87 on the need for assignments in the RIPE Database and what contacts they should contain was very inconclusive. What it did show was that no one really understands what contacts are needed and what the current policy required contacts actually mean. Until we have a clear picture of what this data means and what different stakeholder groups require, we should not be considering changes on this scale. The RIPE NCC's impact analysis also completely ignored the impact of this proposal on the registry system. On Wed, 13 Dec 2023 at 19:14, Jeroen Lauwers <jlauwers@a2b-internet.com> wrote:

Dear colleagues,

Though we recognise that most of you are probably busy preparing for the upcoming holidays, we would like to ask you to share your opinion on proposal 2023-04. Remember that Policy Development Process requires any comments made during the Discussion phase must be repeated during the Review phase in order to count towards or against rough consensus, as your views can now take the RIPE NCC’s Impact Analysis into account.

Let's look at the RIPE NCC's impact analysis (IA). The IA seems to focus mostly on the impact this proposal has on the RIPE NCC and its operations. I accept that the PDP (ripe-781) does suggest most of the IA will be about the impact on the NCC. But it does also mention the " registry and addressing systems". In Section A of the IA 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 too vague. It is true that it is the LIRs decision if they add contact A or contact B. However, the current policy says, as we all know now, an assignment MUST include the contact details of the End User. The RIPE NCC can and should enforce this policy requirement. The type of contact should be enforced, but not the specific contact. Section B of the IA has the title "Impact of Policy on Registry and Addressing System". The IA only refers to the impact on the addressing system. It says nothing about the impact on the registry. The registry has two parts. There is the internal, private registry. This is where the RIPE NCC stores things like contact details for the NCC to contact their members, the LIRs. This proposal probably doesn't have any impact on this part of the registry. The IA should still say that. The other part is the public registry, the RIPE Database. This proposal potentially has a huge impact on the public registry, but nothing has been said about this in the IA. So this raises a question about the PDP policy itself. Should the RIPE NCC focus ONLY on the impact the proposal has on the RIPE NCC or should it discuss wider implications for the Internet and other stakeholders? In the legal impact (Section D) it says: "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". This has the same vagueness as the comment in Section A. It then confuses the issue by talking about personal data. As I pointed out in my first attempt at a privacy policy last year, 'contact data NOT EQUAL personal data'. In 99% of INETNUM objects the End User contact details can be included without making any reference to personal data. The IA even refers to "contact person". As I pointed out last year, all contacts should be roles and not people. We are still locked into the mindset of referring to people.

Here are some questions for the WG to get the discussion started: Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way? Does 2023-04 address this use case well in its current form, or could you think of any potential improvements?

'Convenience' is not the best parameter for determining internet policy. The idea of aligning IPv4 and IPv6 registrations is becoming an obsession. We should talk about aligning the two registration systems 'where appropriate'. Also as I said early on in this discussion, where two systems are mis-aligned, there are two ways to bring them into alignment. We can make IPv6 registrations work the same way as IPv4, with suitable technical improvements.

We hope you will find the time to let your voice be heard!

The Policy Development Process requires the proposers to adequately address any suggestions for changes or objections to the proposal in each phase, which we will do below.

1. Does 2023-04 change the contact registration requirements for assignments?

The argument made is that the statement «When an End User has a network using public address space this must be registered separately with the contact details of the End User» found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy), implicitly requires LIRs to register non-delegated/outsourced contact information for the End User in the RIPE database, not necessarily in the mandatory «admin-c» or «tech-c» attributes, but possibly in an optional attribute like «descr», «org» or «remarks».

Fundamentally changing registration policy requirements "in order to bring the wording in line with that of the IPv6 policy" is absolutely the wrong reason to make such a change.

Proposers’ response:

We do not believe so, for the following reasons, and keeping the current practice and policies in consideration:

The RIPE NCC does not consider that 2023-04 changes the contact registration requirements in any way[1][2][3]. Absent any (rough) consensus in the Working Group to the contrary, we defer to the RIPE NCC’s judgement on this point.

I answered ref [1] here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013... ref [2] (the IA) makes no comment regarding the impact on the registry and I answered ref [3] here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/0138... "we defer to the RIPE NCC’s judgement on this point". Policy is made by the community. If the RIPE NCC's interpretation of a policy point is not correct then the community can require that the RIPE NCC re-evaluates their interpretation.

The practice of creating assignments with all contact information delegated is already widespread. If this was a policy violation made possible due to the RIPE NCC implementing RIPE policy incorrectly, we would have expected the community to take action to correct this situation. However, no such policy proposal has been put forward by the community.

There is a lot in this paragraph. The practice of documenting End User contact details in the optional "descr:" attributes is already widespread. That is likely because so many LIRs do understand the current policy. They have delegated the contact details in the mandatory attributes. But they realize the policy requires End User contact details so they add those details in other attributes. Given that you have put so much emphasis on the 'manual effort required to create assignment objects in the RIPE Database' I am sure so many LIRs have not entered this optional detail without good reason. "we would have expected the community to take action to correct this situation". The fact that 'the community' did not even realise this mis-interpretation of address policy by the RIPE NCC for so long, perhaps says more about the community than the RIPE NCC. There is no doubt that this is a policy violation. There are many other issues with the way address policy has been interpreted in recent years that I could talk about, but no one is interested. The reality is that much of 'the community' does not pay much attention to the fine detail of policy or the way it is interpreted.

Outsourcing and delegation of contact information is a common practice across many industries, including in networking and information technology. There is no policy language that explicitly prohibits this for IPv4 assignments. Absent that, we believe any implicit prohibition found “between the lines” is essentially «void for vagueness»[4].

You are correct that the policy does not prohibit the delegation of contact details. But the policy still clearly requires that End User contact details MUST be included 'somewhere'. The two points are not mutually exclusive. (Your ref to US criminal law is irrelevant.)

An obligation to publish the End User’s contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User’s contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence).

Just as with the IA you have the 'person' mindset lock. Contacts should be roles, not people. As suggested in the privacy discussion last year, the roles can include optional person names if the people so wish. We should all stop using the term 'contact person' and refer to 'contact role'.

The policy’s stated goal of registering assignments is «to ensure uniqueness and to provide information for Internet troubleshooting at all levels»[7]. Requiring LIRs to publish the contact information of End Users who often will not have any knowledge or capability to aid with troubleshooting does work towards this attaining goal. On the contrary, delegating the contact information to the LIR/ISP may well be the only way to attain this goal.

You have been very selective here in your interpretation of the stated goals of the registry system. Firstly it does not state that 'uniqueness' and 'troubleshooting' form an exclusive list of the reasons for a public registry. Over the years the registry has evolved to the needs of other stakeholder groups. But if you want to take this wording literally it also says "The provision of a public registry documenting address space allocations and assignments must exist." An aggregation does not document assignments. It simply documents that a block of address space has been used for assignments. It is not documenting the actual assignments as required by these defined goals. You cannot take one sentence literally and then be flexible in your interpretation of the other sentence. cheers denis

[1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013... [2] https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/0138... [4] https://www.law.cornell.edu/wex/void_for_vagueness [5] https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms [6] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1... [7] https://www.ripe.net/publications/docs/ripe-804#3

2. The «assignment-size» attribute should be a CIDR prefix length

Leaving it undefined could result in some LIRs using it to represent an IPv4 address count, while others would use it to represent a CIDR prefix length.

Proposers’ response:

We agree «assignment-size» should be a CIDR prefix length. We understand that, if proposal 2023-04 would be accepted, the RIPE NCC could implement the «assignment-size» attribute for IPv4 inetnum objects to be a CIDR prefix length, and document it as such. Therefore we do not believe it is necessary to spell this out explicitly in the policy document (it is not spelled out in the IPv6 policy document either).

Thank you for your attention and enjoy your holidays!

Best regards, Jeroen and Tore

Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara <adallara@ripe.net> het volgende geschreven:

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

Hello Denis, As proposers, we cannot address your objections against the RIPE NCC’s Impact Analysis, as we had no hand in producing it. However, we will try to address your points below that have not already been discussed at length. See inline:

Policy is made by the community. If the RIPE NCC's interpretation of a policy point is not correct then the community can require that the RIPE NCC re-evaluates their interpretation.

On this, we agree 100%. The question then becomes: is there someone willing to submit a policy proposal that would require that the RIPE NCC re-evaluate their interpretation? If there is, it would be prudent to put 2023-04 on hold, pending the outcome of that proposal. If not, that essentially amounts to a tacit acceptance by the community that the RIPE NCC’s interpretation of the current policy is correct, and we can proceed with 2023-04.

There is a lot in this paragraph. The practice of documenting End User contact details in the optional "descr:" attributes is already widespread. That is likely because so many LIRs do understand the current policy. They have delegated the contact details in the mandatory attributes. But they realize the policy requires End User contact details so they add those details in other attributes. Given that you have put so much emphasis on the 'manual effort required to create assignment objects in the RIPE Database' I am sure so many LIRs have not entered this optional detail without good reason.

The practice differs greatly between LIRs. Some LIRs create database objects that are rife with optional information not mandated by policy (information about BGP communities, for example), while others prefer to create rather minimal objects that contain only the mandatory attributes. Your assumption that LIRs that include End User contact information in descr: do so because they believe policy compels them to may well be true for some LIRs, but other LIRs might do so out of their own free will. Neither of us can't know with any degree of certainty which is the most common case; trying to quantify the two groups of LIRs would be pure conjecture. That said, it is very easy to demonstrate that the «out of their own free will» group of LIRs does exist and is significant in size. You can do that by downloading the inet6num database contents from the FTP and looking at the objects with the status ASSIGNED. You will find that there are *many* objects that contain the End User’s name, address, and other information in descr: None of that information is there because the LIRs in question have interpreted the policy to require them to publish this information, as the sentence «When an End User has a network using public address space this must be registered separately with the contact details of the End User» does not occur in the IPv6 policy. The LIRs could easily have minimized their assignments, removing all descr: attributes, and/or registered them as part of an AGGREGATED-BY-LIR object. They have chosen not to do so, however. It seems safe to assume, therefore, that at least some of the LIRs that publish the same data in IPv4 inetnum objects do it voluntarily and not because they believe IPv4 policy compels them to.

Just as with the IA you have the 'person' mindset lock. Contacts should be roles, not people. As suggested in the privacy discussion last year, the roles can include optional person names if the people so wish. We should all stop using the term 'contact person' and refer to 'contact role'

The policy needs to apply to assignments made to large enterprises with a dedicated NOC role, and to tiny one-person businesses whose only contact information is the owner’s personal Gmail address and mobile phone number. It is not feasible to require LIRs to only make assignments to End Users in the first category. It needs to also take into account End Users in the second category, whose contact person does not consent to the publication of their personal information in the RIPE database.

You have been very selective here in your interpretation of the stated goals of the registry system. Firstly it does not state that 'uniqueness' and 'troubleshooting' form an exclusive list of the reasons for a public registry. Over the years the registry has evolved to the needs of other stakeholder groups. But if you want to take this wording literally it also says "The provision of a public registry documenting address space allocations and assignments must exist." An aggregation does not document assignments.

Note that the IPv6 policy (section 3.3) contains very similar wording: «Internet address space must be registered in a registry database accessible to appropriate members of the Internet community.» The community has decided that AGGREGATED-BY-LIR is compatible with this goal in the context of IPv6 assignments. Is there something unique about IPv4 assignments that makes «The provision of a public registry documenting address space allocations and assignments must exist» not equally compatible with AGGREGATED-BY-LIR? Best regards, Tore and Jeroen

Hi Jan, On Fri, 2023-12-15 at 14:58 +0100, Jan Ingvoldstad wrote:

Can the proposers please clarify how a change, that is claimed to change nothing, is a necessary change?

Unless this is resolved, I oppose the change.

Certainly - we are happy to clarify. We believe we are actually talking about two different changes here. The first one is intentional, as it is the actual intended goal of the proposal – namely to allow LIRs to aggregate multiple assignments with the same purpose and contact details into a single aggregated object. For example, if you are an LIR/ISP that today have the following two customer assignments in the database: inetnum: 192.0.2.0 - 192.0.2.127 netname: JAN-ISP country: NO admin-c: JAN-RIPE tech-c: JAN-RIPE status: ASSIGNED PA mnt-by: JAN-MNT source: RIPE inetnum: 192.0.2.128 - 192.0.2.255 netname: JAN-ISP country: NO admin-c: JAN-RIPE tech-c: JAN-RIPE status: ASSIGNED PA mnt-by: JAN-MNT source: RIPE If 2023-04 passes, you will be able to (but will not be required to) replace your above two objects in the database with the following aggregated object, similar to what you already can do in IPv6: inetnum: 192.0.2.0 - 192.0.2.255 netname: JAN-ISP country: NO admin-c: JAN-RIPE tech-c: JAN-RIPE status: AGGREGATED-BY-LIR mnt-by: JAN-MNT source: RIPE You cannot create such aggregated objects today, so that is clearly an intentional change that 2023-04 will bring about. There is no dispute that this change will take place. The second – alleged – change is the one that has been discussed the most on the mailing list. The argument here is that your two ASSIGNED PA objects above are actually in violation of *current* policy, because they delegate all the contact information to you (the ISP/LIR). The claim is that current policy requires non-delegated contact information for the End User to be published in the object (not necessarily in admin-c/tech-c, but “somewhere”). If 2023-04 passes, your two ASSIGNED PA assignments above will definitely be policy compliant (even before they are possibly replaced with an AGGREGATED-BY-LIR object). There is no disagreement about this, as far as we know. So the question is whether or not your two ASSIGNED PA objects are permitted under *current* policy. If they are, then 2023-04 does not change anything in this regard; the “legal status” of your objects will remain the same – i.e., they are not violating policy – after 2023-04 passes (or fails) as it is under current policy. We believe your two objects are not in violation of today’s policy, which means 2023-04 will exact no change to their “legal status”. We have elaborated on why in this message, under the heading «Does 2023-04 change the contact registration requirements for assignments?»: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/0139... We hope this provides the clarification you requested. Best regards, Jeroen and Tore

Hi Jan, On 09/01/24 10:51, Jan Ingvoldstad wrote:

On Sat, Dec 16, 2023 at 7:55 PM Tore Anderson <tore@fud.no> wrote:

The second – alleged – change is the one that has been discussed the most on the mailing list. The argument here is that your two ASSIGNED PA objects above are actually in violation of *current* policy, because they delegate all the contact information to you (the ISP/LIR). The claim is that current policy requires non-delegated contact information for the End User to be published in the object (not necessarily in admin-c/tech-c, but “somewhere”).

If 2023-04 passes, your two ASSIGNED PA assignments above will definitely be policy compliant (even before they are possibly replaced with an AGGREGATED-BY-LIR object). There is no disagreement about this, as far as we know.

So the question is whether or not your two ASSIGNED PA objects are permitted under *current* policy. If they are, then 2023-04 does not change anything in this regard; the “legal status” of your objects will remain the same – i.e., they are not violating policy – after 2023-04 passes (or fails) as it is under current policy.

We believe your two objects are not in violation of today’s policy, which means 2023-04 will exact no change to their “legal status”. We have elaborated on why in this message, under the heading «Does 2023-04 change the contact registration requirements for assignments?»:

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/0139...

We hope this provides the clarification you requested.

Regrettably it does not, and it also raises the question of whether you have forgotten the definition of "end user" and confused it with "private person".

4. An obligation to publish the End User’s contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User’s contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence).

This is misleading, as posting the contact details of an end user **does not necessarily require that you post PII** (person identifying information). You can use a company role and a company role's email address. This is also quite common in the RIPE database today, as far as I can tell.

It is important to also consider the cases where the End Users are organisations that do not have non-PII role addresses. Consider for example a small one-person business, let's say a farm owned by «Farmer Fred». This End User would be a company, not an individual, yet the company is often given the same name as the person owning it (at least here in Norway). The e-mail address might well be farmer.fred@gmail and the phone number might be the Farmer Fred's personal mobile. This would mean that both the name and the contact information for this End User *is* PII and is in scope of the GDPR. Therefore, if Farmer Fred exercises his rights under the GDPR to object against / not give consent to the publishing of his PII in the RIPE DB, you (the LIR) have a problem. Proceeding to publish this contact information over Farmer Fred's objections opens you up to legal risk (not to mention souring the relationship with your customer).

Additionally, this is what we in the registrar business consider a solved problem. In the event that the end user is a private person, you instead by default post anonymized information and e-mail addresses. In the case of e-mail addresses, the typical solution is to post a randomized e-mail address that acts as a forwarding address, and that this address is rotated according to the registrar's internal criteria. In the case of RIPE, it would be the LIR's responsibility, I guess.

Precisely. The LIR, like a domain name registrar, can simply serve as a proxy between the wider Internet community and its End Users. This voids any policy requirement to (possibly illegally) publish Farmer Fred's PII in the RIPE DB. As stated in the Impact Analysis, the RIPE NCC is of the opinion that this (already widespread) practice is permitted by current policy, and will continue to be permitted after 2023-04 is implemented. In other words, just like in the registrar business, this is an already solved problem, which will continue to be solved after 2023-04 is implemented. It is in this respect that we say that 2023-04 will not bring about any change – it ain't broken, and we're not fixing it. The claim that has been made is that *current* policy does not allow LIRs to serve as proxies in this manner, and that the RIPE NCC has not been implementing current policy correctly by allowing it. It is further claimed that 2023-04 will bring about an (undesired) change in that it will allow LIRs to serve as proxies. However, for the reasons already discussed we are of the opinion the premise this argument rests on is incorrect, hence we do not believe 2023-04 will effect any change. We hope this clarifies the clarification. :-) Tore & Jeroen

Hi again Jan, On 09/01/24 13:38, Jan Ingvoldstad wrote:

It is important to also consider the cases where the End Users are organisations that do not have non-PII role addresses.

Consider for example a small one-person business, let's say a farm owned by «Farmer Fred». This End User would be a company, not an individual, yet the company is often given the same name as the person owning it (at least here in Norway).

The e-mail address might well be farmer.fred@gmail and the phone number might be the Farmer Fred's personal mobile. This would mean that both the name and the contact information for this End User *is* PII and is in scope of the GDPR.

The current interpretation of this part of the GDPR is that "Farmer Fred" is permissible to publish.

Whose interpretation? According to the EU Commission: «Personal data is any information that relates to an identified or identifiable living individual. Different pieces of information, which collected together can lead to the identification of a particular person, also constitute personal data.» https://commission.europa.eu/law/law-topic/data-protection/reform/what-perso... «Farmer Fred» – the name of an individual – clearly falls within this definition. So does his e-mail address and telephone number. Publishing this information requires a lawful basis, e.g., consent. If consent was refused, it is not permissible to publish. This is presumably the reason why the RIPE NCC states the following in the 2023-04 Impact Analysis: «Inserting any personal data in the RIPE Database must be in compliance with the RIPE Database Terms and Conditions, even when it relates to the contact details of the member’s own contact person(s). In particular, before anyone updates the RIPE Database with personal data, they must obtain the contact person’s informed and expressed consent and ensure this data is kept accurate and up-to-date.» https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis

Therefore, if Farmer Fred exercises his rights under the GDPR to object against / not give consent to the publishing of his PII in the RIPE DB, you (the LIR) have a problem. Proceeding to publish this contact information over Farmer Fred's objections opens you up to legal risk (not to mention souring the relationship with your customer).

The solution here would be to not publish (and not require the publication of) personal phone numbers (or personal addresses), and to clearly make this a requirement in the policy regarding what End User information is published.

Indeed, and it is our opinion that this solution is already available today, as the RIPE NCC has confirmed that according to their current policy interpretation and procedures, not publishing Farmer Fred's PII in the RIPE DB is compliant with today's policy. This will continue to be the case after 2023-04 is implemented, so no change there.

Similarly, that requirement must be there for *any* contact object, not just End Users.

You cannot know if the LIR's phone numbers are personal or not, or can you?

LIRs' contact information is definitively out of scope of 2023-04. 2023-04 only concerns itself with *assignments* (made by LIRs to End Users), not *allocations* (made by the RIPE NCC to LIRs). (That said, LIRs' contact information is also subject to the RIPE Database Terms and Conditions.)

Precisely. The LIR, like a domain name registrar, can simply serve as a proxy between the wider Internet community and its End Users.

No, that is not what I wrote.

This is about an automatic email forwarding scheme, not about a registration by proxy scheme.

E.g. you register the domainname ripe-example.shop with a registrar within the EEA, your email address is published (for EEA-based domainnames, anyway) as e.g. qaobuaidbvsas@privacy.example, which is a valid email address that is automatically forwarded to e.g. tore+ripe-example@fud.no <mailto:tore%2Bripe-example@fud.no>.

The policy is technology agnostic in this respect. An automatic e-mail forwarding scheme such as the one you describe is one example of a policy- (and presumably GDPR-) compliant way to do it, but that's not the only possible option. The LIR could instead opt for operating a human-staffed help desk that receives and forwards messages to End Users as appropriate.

This voids any policy requirement to (possibly illegally) publish Farmer Fred's PII in the RIPE DB. As stated in the Impact Analysis, the RIPE NCC is of the opinion that this (already widespread) practice is permitted by current policy, and will continue to be permitted after 2023-04 is implemented. In other words, just like in the registrar business, this is an already solved problem, which will continue to be solved after 2023-04 is implemented. It is in this respect that we say that 2023-04 will not bring about any change – it ain't broken, and we're not fixing it.

The claim that has been made is that *current* policy does not allow LIRs to serve as proxies in this manner, and that the RIPE NCC has not been implementing current policy correctly by allowing it. It is further claimed that 2023-04 will bring about an (undesired) change in that it will allow LIRs to serve as proxies. However, for the reasons already discussed we are of the opinion the premise this argument rests on is incorrect, hence we do not believe 2023-04 will effect any change.

We hope this clarifies the clarification. :-)

I was kindof trying to avoid that argument again.

But sure, as you bring it up again.

This opinion is obviously a logical impossibility.

There is no way that you can change something and at the same way legitimately claim that the change is not a change.

If it is true that the current practice is both widespread and accepted, then *no change is necessary*.

If a change is necessary, it is logically because there is a widespread and accepted practice of publishing End Users' contact information.

The argument is therefore nonsensical, sorry.

I think that because the WG discussion has almost exclusively revolved around this alleged changing of policy requirements to publish End User contact information (which may or may not be PII), it is easy to lose track of what this proposal is *actually* all about. We are talking about two different things: 1) The actual intention behind the proposal: Making it possible to aggregate multiple IPv4 End User assignments that have consistent contact information and purpose into a single database object. This is not possible today, and that is what we want to make that possible, in the same way it is already possible in IPv6. 2) The *alleged* change to what kind of End User contact information is required to be published in the RIPE database. We have never had any intention of changing this in any way, and the Impact Analysis and other statements from the RIPE NCC confirm that the proposal does not change it either. In short: 1) is an intentional and desired change from today, while 2) is *not* a change from today – intentionally so. So maybe we could discuss 1) instead of 2) going forward? :-)

You have not actually addressed this concern and objection, you have merely restated claims and opinions that do not actually do so.

I therefore again urge you to resubmit the proposal *without* this removal.

As noted in 2) above, the proposal in its current form does not cause any «removal» of any End User contact information publishing requirement compared to current policy. It merely upholds the status quo, which has been confirmed by the RIPE NCC on multiple occasions. However, if you are dismissing the RIPE NCC's clarifications on this subject in the Impact Analysis and elsewhere as not factual, then there is not much more to discuss and we would simply have to agree to disagree.

Then, if this part of the policy change is of importance, resubmit it as a separate proposal, and preferably clearing up the PII mess a bit more. I have no beef with clearing that up.

Any effort to «clearing up the PII mess» has always been outside the scope of this proposal. This proposal is simply not about PII or contact information. That could be a subject for another policy proposal, of course, but one thing at a time. Tore & Jeroen

Hello again Jan, On 10/01/24 11:25, Jan Ingvoldstad wrote:

Basically, any public company register would be illegal according to the interpretation you lean on here.

Public company registries also need a lawful basis for processing. The Norwegian public company registry, for example, uses the lawful basis «exercise of official authority» – Article 6(1)(e) GDPR – as its lawful basis, see https://www.brreg.no/en/privacy-statement/. I would assume that to be the case in most other countries as well. (Most) LIRs are not official authorities, so unlike public company registries LIRs cannot use this lawful basis for publishing PII in the RIPE Database. In any case, all of this is rather off-topic. 2023-04 does not change the legal obligations on the LIRs relating to the publication of End User contact information, nor does it change the RIPE Database Terms and Conditions. If you want to publish PII in the RIPE Database, you need a lawful basis. That's true today, and that will continue to be true if 2023-04 passes.

Or you could take the other stance and stop publishing *any* contact details regarding an object, because you cannot know whether the information is personal data or not.

Exactly. LIRs may (but are not required to) chose this approach already *today*. This is a common and long-standing practice which the RIPE NCC has repeatedly clarified as compliant with today's policy. It will continue to be compliant with the policy after 2023-04 passes, as well. Thus, 2023-04 effects no change on the LIRs' obligations in this regard.

I think that because the WG discussion has almost exclusively revolved around this alleged changing of policy requirements to publish End User contact information (which may or may not be PII), it is easy to lose track of what this proposal is *actually* all about. We are talking about two different things:

1) The actual intention behind the proposal: Making it possible to aggregate multiple IPv4 End User assignments that have consistent contact information and purpose into a single database object. This is not possible today, and that is what we want to make that possible, in the same way it is already possible in IPv6.

2) The *alleged* change to what kind of End User contact information is required to be published in the RIPE database. We have never had any intention of changing this in any way, and the Impact Analysis and other statements from the RIPE NCC confirm that the proposal does not change it either.

In short: 1) is an intentional and desired change from today, while 2) is *not* a change from today – intentionally so.

This (regarding item 2) is simply not true. Any change in text *is a change*.

We are not making the claim that the policy text does not change. That it clearly does – in order to achieve the desired change described in item 1 above. We are however claiming that the *meanings* of the old and the new policy texts are exactly the same, with regards to how they translate into operational procedures and requirements for the publication of End User contact information (item 2). As the RIPE NCC writes in the Impact Analysis (emphasis added):     «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.» So, once again: which End User contact details LIRs publish (if any) is their decision today, and it will be continue to be their decision if 2023-04 passes. Hence, 2023-04 does not effect any change in this regard.

So maybe we could discuss 1) instead of 2) going forward? :-)

I have no problem with 1), as already stated.

We're happy to hear that!

I do agree with you that this is distracting from the proper meat of your proposal. Which is why I suggest that you drop this part of it. Again, drop the part of the proposal that people have a beef with.

Don't make the change that you claim is not a change.

This «beef» is based on reading current policy to mean that which End User contact details LIRs publish in the database (if any) is *not* the LIRs' decision today. But the RIPE NCC has repeatedly clarified that that is simply not the case: it *is* the LIRs' decision today, and it will continue to be LIRs' decision should 2023-04 pass. Given that, it is hard to see how we could possibly amend the proposal to change this particular point to an even lesser extent than what is already the case? Tore & Jeroen

Hi Denis, On 11/01/24 03:20, denis walker wrote:

On Wed, 10 Jan 2024 at 13:02, Tore Anderson <tore@fud.no> wrote:

...

On 10/01/24 11:25, Jan Ingvoldstad wrote:

...

Or you could take the other stance and stop publishing *any* contact details regarding an object, because you cannot know whether the information is personal data or not. Exactly. LIRs may (but are not required to) chose this approach already *today*. This is a common and long-standing practice which the RIPE NCC has repeatedly clarified as compliant with today's policy.

This is one of your biggest false statements. The ONLY person repeatedly saying this is YOU. Let's do a fact check here.

Yes, let us indeed do a fact check: Exhibit 1: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013... Exhibit 2: https://www.ripe.net/participate/policies/proposals/2023-04 (specifically the «counter-argument», which the RIPE NCC Policy Officer confirmed to the proposers and the WG chairs as correctly representing the RIPE NCC's interpretation) Exhibit 3: https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis Exhibit 4: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/0138... Four repetitions so far, all saying the same thing. How many more do you need? We note that you have requested further clarifications from the RIPE NCC tonight, which we of course look forward to.

This is total madness. You keep saying you have no intention of changing anything else. You keep saying the wording change actually changes nothing in practice. Some other people don't agree with you. Just don't change wording that you claim changes NOTHING and has nothing to do with aggregation and everyone is happy. The fact that you are pushing so hard to make this wording change, you refuse to back down or compromise, you insist on changing wording that changes nothing and has nothing to do with aggregation...proves that you don't believe that yourself. The fact is, I suspect that this is the real change you want. You want to drop the current policy requirement to define assignments with End User contacts. It is the aggregation that is the side issue here. There is no other explanation for why you are insisting so strongly on changing wording that changes nothing.

Here we find ourselves in conspiracy theory land, frankly. It makes zero sense, too: If our ulterior goal was to remove the End User contacts from our own assignments we can just go ahead and do so, right now. The RIPE NCC is already on the record saying that's totally OK, and we would be following in the footsteps of many other LIRs who have already done so. Why on Earth would we waste our time on a policy proposal? If our ulterior goal was to remove the End User contacts from other LIRs' assignments, 2023-04 simply doesn't accomplish this goal, because it conveys no requirement on LIRs to remove anything from the database whatsoever. The RIPE NCC has not identified any unintended or ulterior side effect caused by 2023-04 either, does that mean they are a part of the conspiracy too?

...

As the RIPE NCC writes in the Impact Analysis (emphasis added):

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

So, once again: which End User contact details LIRs publish (if any) is their decision today, and it will be continue to be their decision if 2023-04 passes. Hence, 2023-04 does not effect any change in this regard. This really does make me cry. The wording in the IA is poor. You have applied an interpretation to this which I do not believe is what was meant. Then the RIPE NCC legal team has remained silent. So I am asking the RIPE NCC legal team to clearly explain what they meant by this wording.

The explanation you request was posted two days after the Impact Analysis was: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/0138... «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 explanation aligns perfectly with our interpretation of the statement in the Impact Analysis.

...

Given that, it is hard to see how we could possibly amend the proposal to change this particular point to an even lesser extent than what is already the case? Let me help you. Do NOT remove a sentence that has nothing to do with the stated goal of the proposal to aggregate assignments and that you claim does not change anything.

This sentence also has a lot to do with the stated goal of aggregating assignments, because it mandates that assignments must be «registered separately». That is clearly incompatible with aggregation. It would of course be possible to retain the old sentence as-is by combining it with the new one copied from the IPv6 policy by using an either/or construct, e.g.: «When an End User has a network using public address space this must be registered separately with the contact details of the End User or by inserting an object with a status value of 'AGGREGATED-BY-LIR'». That said, the actual policy outcome would as far as we can tell be exactly the same as 2023-04 in its current form, so we assume you would object to this language as well? Tore & Jeroen

Hi Jan, On 11/01/24 10:19, Jan Ingvoldstad wrote:

On Thu, Jan 11, 2024 at 9:45 AM Tore Anderson <tore@fud.no> wrote:

On 11/01/24 03:20, denis walker wrote:

> This is total madness. You keep saying you have no intention of > changing anything else. You keep saying the wording change actually > changes nothing in practice. Some other people don't agree with you. > Just don't change wording that you claim changes NOTHING and has > nothing to do with aggregation and everyone is happy. The fact that > you are pushing so hard to make this wording change, you refuse to > back down or compromise, you insist on changing wording that changes > nothing and has nothing to do with aggregation...proves that you don't > believe that yourself. The fact is, I suspect that this is the real > change you want. You want to drop the current policy requirement to > define assignments with End User contacts. It is the aggregation that > is the side issue here. There is no other explanation for why you are > insisting so strongly on changing wording that changes nothing.

Here we find ourselves in conspiracy theory land, frankly.

Uh. While questioning your motives is perhaps a bit rude, this is WAY over the top, Tore.

Please retract this weird accusation, I really don't understand your motives for trying to label this as having to do with a conspiracy theory. It tarnishes the discussion.

This goes far beyond «questioning our motives». There is an assertion of "proof" that Jeroen deliberately make statements that we do not believe ourselves, in other words that we are lying to the working group. It is suggested that we are maliciously attempting to deceive the working group as to our true motives for submitting the policy proposal and what changes it will effect, and that the stated motive – introducing AGGREGATED-BY-LIR – is a mere "side issue" which is not our true, hidden, motive. Presumably the RIPE NCC must also be actively participating in this deception, or at the very least turn a blind eye to it. This ticks all the boxes in the Wikipedia definition of a conspiracy theory, with the possible exception that Jeroen and I could not reasonably be classified as a «powerful group». That said, labels are unimportant, so consider the statement retracted. Let us instead say that we vehemently disagree with the allegation that there are any ulterior motives behind 2023-04 and that we are actively attempting to deceive the working group in any way.

While you seem to argue that the RIPE NCC is both omniscient and omnicompetent, I do not think it is that easy.

I simply think that the RIPE NCC and you are mistaken.

That is fair enough. We note your disagreement with the RIPE NCC as well, which we take to mean you do not allege that we are actively and intentionally misrepresenting the RIPE NCC's position in our messages. That is something, at least.

Continously appealing to RIPE NCC as the authority of policy and policy interpretation is not a good thing.

The RIPE NCC is the secretariat of the RIPE Community and is delegated the task of implementing and enforcing the RIPE Community policies, as well as to providing training to the LIRs on how to operationalise said policies. If that is not an authority worth paying attention to, I do not know what is. After all, any LIR which prefers the RIPE NCC interpretation of the policy in this regard is may simply adhere to it and act accordingly, and this is commonly done today. Thus the RIPE NCC's interpretation of the policy – mistaken or not – ends up becoming the (de facto) way the policy is implemented anyway. Tore & Jeroen

Hi Jan, On 11/01/24 13:27, Jan Ingvoldstad wrote:

On Thu, Jan 11, 2024 at 1:11 PM Tore Anderson <tore@fud.no> wrote:

After all, any LIR which prefers the RIPE NCC interpretation of the policy in this regard is may simply adhere to it and act accordingly, and this is commonly done today. Thus the RIPE NCC's interpretation of the policy – mistaken or not – ends up becoming the (de facto) way the policy is implemented anyway.

This statement basically renders the point of a policy working group moot.

Not at all. Any working group member who is of the opinion that the RIPE NCC is interpreting a RIPE Community policy incorrectly, is free to at any point submit a policy proposal that clarifies the allegedly misinterpreted policy text with the aim to make the RIPE NCC change its procedures accordingly. The RIPE NCC's Impact Analysis will then reveal whether or not the proposed new policy text does attain its goal and that the RIPE NCC will change its procedures as desired, should the proposal pass. Finally, the proposal will need to reach (rough) consensus in order to confirm that the RIPE Community does indeed concur with the proposer's opinion that the old policy was interpreted incorrectly, and that the RIPE NCC's procedures ought to change. Absent this, the RIPE NCC's operationalisation of the policy will stay as-is. Tore & Jeroen

Good morning Jan, On 12/01/24 07:25, Jan Ingvoldstad wrote:

I also do not understand what makes it so hard to say that: "Yes, the current policy does state something else than NCC's interpretation of it does, (…)

We do not make statements that we do not believe to be true. In our opinion, the RIPE NCC implements current policy correctly. Tore & Jeroen

On Fri, Jan 12, 2024 at 8:57 AM Sebastian Graf <ripe-lists@sebastian-graf.at> wrote:

Dear Jan!

Dear Sebastian, thanks for chiming in!

As mentioned in my previous e-mail: Would you please post the section of the policy that you belive has the NCC's interpretation differ from the actual wording/language used?

https://www.ripe.net/participate/policies/proposals/2023-04 6.2 Network Infrastructure and End User Networks … "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users." The removal of this text has seen many strange arguments, such as GDPR (which is already covered by the text being removed). Because i have yet to find a section that states explicitly what is

considered valid vs invalid contact information (other than being out of date or information that does not provide a contact to the user in a timely manner). Or a section that restricts what kind of data is permissable for "contact information".

As I understand it, the RIPE NCC's interpretation, and the one that Tore leans on, is that the text does not mean that organisation End User contact details must be published, even though they are not individual users. The argument therefore appears to be that the text "When an End User has a network using public address space this must be registered separately with the contact details of the End User." should be read as "" in the current policy document, and that changing "When an End User has a network using public address space this must be registered separately with the contact details of the End User." to "" changes nothing in the policy. My stance is that this changes the policy, but that it changes the policy to be in line with current practice. (As a side note, 10-15 years ago, my employer received quite a lot of flak for NOT publishing contact details for every single customer that had the use of single, dedicated IP addresses, as part of web hosting or colocation services, with rerference to this very policy. How times change.) -- Jan

On Fri, Jan 12, 2024 at 9:28 AM Sebastian Graf <ripe-lists@sebastian-graf.at> wrote:

Dear Jan!

Dear Sebastian,

Thank you for your reply. But you have not answerred my question.

I answered your question, but I did not understand that you intended your ancillary comment as an additional question. Sorry about that.

We are all clear/well aware on the fact that the policy states (paraphrasing here: resources need to be registered and the registions need to have contact information).

We are looking for the DEFINITION of "contact details of the End User.". This is not directly defined (as far as i can tell) and is therefore open for interpretation.

Unless i missed something?

As I understand it, this comes from how contact objects are defined in the database, and this is what RIPE-804 references.

Denis has provided more detailed context. RIPE-705 sets specific requirements regarding abuse contact details. -- Jan

Colleagues I am back!! Thanks to those who agreed I should never have been away. I am not going to focus on that for now. I do have a lot to say around that issue. But that is for another day, on another mailing list. I won't discuss it here and I will wait until we conclude the discussion on this proposal. I want people to focus on the message rather than the messenger. There hasn't been much conversation while I have been away, but still several significant points that seemed to have been missed by most observers. I have answered all points raised by several people in this single email. In these days of uncertainty, who knows how long any of us will be around. So it is more of an article than an email. But I do end with a positive recommendation. Let's start with a comment by Leo: "We encourage everyone to focus comments on the proposal and its potential impact. Do not comment on individuals, their characteristics, or motivations." The co-chairs have no authority to determine what constitutes part of this discussion. If individuals use tactics that may confuse the community or repeatedly make comments that are not true, they make themselves part of the discussion. The co-chairs have no right to try to prevent these issues from being highlighted and discussed. People need to understand that personal criticism is not a personal attack, even if it is strong criticism. When an individual repeatedly says something that is not true, to highlight this issue and ask them why they keep saying this is not a personal attack. Criticism is part of life, especially in business. Throughout this discussion there has been lots of criticism thrown at me. My characteristics have been heavily criticised and commented on. Even who I speak for has been questioned. No one has questioned if an employee speaks on behalf of their employer. My motivations have also been questioned. It was suggested that I should not talk about the RIPE Database on the Address Policy WG. Even though the old design and technology of the database is one of the key elements used to support the need for aggregation. So much criticism aimed at me and yet the co-chairs saw no reason to intervene. They only intervene when I criticise someone. Then there is motivation. Is it questionable? A lot of the discussion on policy is political, commercial and self interest based. In these contexts I believe it is acceptable to question motivation. The co-chairs never asked what I meant by what I said. Of course the proposal is about aggregation. It's in the title and the text. But it is about a lot more than that. There are two main aspects to this proposal. An inconsequential, minor feature change that people may or may not use. And a major change to the handling of End User details, which people also may or may not take advantage of. The two aspects combined can make a massive change to the available information in the RIPE Database. But the proposal did not even mention the change to End User details. Is it important? Well after I pointed it out, some people who had said "+1 I agree with this proposal" changed their mind and withdrew their support. So for them it was highly relevant. There are sections in the proposal template for supporting and opposing issues relating to the proposal. Depending on your point of view this major change should have been listed in one of those sections. But it wasn't. So did the proposers fully understand the implications of this change or not? I must be allowed to ask that question as part of this discussion. If they did understand it, why did they not mention it? Did they overlook it, or was there some other reason? Again I have to be able to ask these questions. This is all about motivation. To ask these questions and understand what happened is not a personal attack. It is a reasonable line of inquiry. Enough about the messenger, let's get back to the message. ------------------------ On Mon, 18 Dec 2023 at 16:49, Edwin Verheul via address-policy-wg < address-policy-wg@ripe.net> wrote:

I support this proposal.

Since this policy introduces convenience for LIR by aligning ipv4 object

policy to the ipv6 policy, unclear usage of the admin contact should not prevent this improvement in policy. This pretty much sums up a lot of people's view of this proposal. It is 'convenient' for the operators. Who cares if it is the right thing to do or not, it is convenient. It doesn't align v4 and v6, there are significant differences in the defined aggregations. Never mind if we don't understand what the data means, let's just change it anyway as it is convenient. Maybe a few of you should watch John Curran's keynote speech at NANOG on internet governance: https://www.youtube.com/watch?v=U1Ip39Qv-Zk He talks about phases of the internet and how we are now moving from the 'commercial' internet to the 'public' internet. With this public internet, civil society has/wants a much bigger say in how things work. Organisations that represent civil society and civil order are more concerned about how things work. Politicians are concerned about what their voters think. Do you think civil society cares about operator convenience? They are more likely to think 'it's your job, do it. That's what we pay you for'. I think civil society will be more interested in knowing who is spamming them or attacking their network and can the police catch them, rather than operator convenience. Now let's think a bit more about what this data means and how to interpret it. ------------------------ On Fri, 12 Jan 2024 at 08:56, Alex Le Heux <alexlh@funk.org> wrote:

During the discussion about AGGREGATED-BY-LIR status for IPv4 PA

assignments the argument has been raised that this proposal would substantially change the registration requirements for end-user assignments in the RIPE DB and the discussion has been going around in circles ever since.

We would like to point out the following:

From the RIPE NCC Impact Analysis:

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 completely out of context. I have asked the RIPE NCC legal team to clarify what this means but I guess by their silence they declined. To me this sentence says the member can choose to enter the details of Contact A or Contact B and choose what the details are. Which one (A or B) and the details (email or phone) they enter will be their decision. The RIPE NCC cannot enforce if they enter A or B or email or phone. WHO these contacts represent is a matter of policy. The current policy says they MUST be representatives of the End User. That can be enforced by the RIPE NCC, but they choose not to enforce it.

As well as:

It is fact that the RIPE NCC has interpreted the current policy to not

require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time.

This is completely false. I know Alex well and will give him the benefit of the doubt that he has not picked up on the detail here. He signed this email 'for the Address Policy WG co-chairs'. A lot was said about who I speak for, so I assume Alex was speaking 'for' all the chairs. I was told that signing as 'co-chair DB-WG' gives what I say more weight and has more influence on the community. The same must apply when the co-chairs of this WG collectively sign an email. The community will assume that statement carries more validity. Let's look at the detail. Address policy from the early 1990s has made it clear that assignments must include contact details of the End User. But ripe-288, 28 Oct 2003 is particularly interesting. The authors of this version of the address policy were: Mirjam Kühne, Paul Rendek, Sabrina Wilmot, Leo Vegoda At that time they were all current or former NCC staff. Leo was the operations manager of the RIPE NCC Registration Services (RS). Paul was the senior manager responsible for RS. In this version, these authors added the exact wording that we have today: "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." The wording was very different before this. The document was restructured and the wording changed. So they must have thought about what this meant. I cannot believe that when these words were added to the policy by the RS manager and RS senior manager they were not enforced by RS. Maybe Leo can give some background to this. Nothing in this industry changes quickly. So if these newly worded requirements were enforced just 20 years ago, they must have been enforced for at least 5 to 10 years. That means the RIPE NCC's interpretation of this wording, written by the RS manager, has only changed in the last 5 to 10 years. I have been told by some former members of RS that they stopped enforcing these requirements at runout of IPv4. They told me that when they had no more address space to allocate, they had no power to enforce these rules. So they simply stopped enforcing them. This paints a very different picture. We are not changing policy to match a common practice. We are dropping policy because it is difficult to enforce, regardless of the reasons why the policy was introduced. It is also interesting that, no matter how many times you read something, you don't always see what it says. A lot has been said about replacing the admin-c and tech-c contacts in an assignment with the contacts of the LIR. It has been said that the RIPE NCC now considers this acceptable. But look at what the current policy actually says: "Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." So this substitution is only allowed by policy where the End User is an individual. You cannot do it for all End Users. This actually makes sense to me. If I want to contact the LIR's tech or admin contacts, they are already available in the RIPE Database in the allocation object. Why duplicate the data in the assignment. The policy says the assignment must have the End User's contacts. So that is another misinterpretation of the current policy.

In its impact analysis the RIPE NCC has indicated that this proposal does

not change this interpretation.

It should therefore be clear that 2023-04 does not in fact change

anything regarding how end-user details will actually be registered in PA Assignments. Interesting choice of words. It may not change how some End User details 'will' actually be registered, but it changes how they 'should' be registered enormously.

However, is has been argued that this interpretation is wrong and that PA

Assignments in the RIPE DB must include the actual end-user details. And even though this is out of scope for the 2023-04 discussion, it is still something that is worth resolving. As changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects, we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one.

I agree this needs further clarification. But you can't write a policy proposal on something you don't understand. We don't know what much of the data means now or in the past, or why we have these rules, or what we need now. Until we have the business requirements for the RIPE Database as a public registry any such policy proposal, including this one, is just a dangerous stab in the dark.

Kind regards,

Alex Le Heux, for the Address Policy WG co-chairs

It is interesting that this email was signed 'for' all the co-chairs of this WG. How can the co-chairs approve this policy proposal (2023-04) while accepting that another proposal is needed to clarify if the RIPE Database must include the actual End User contact details? Are they going to approve a policy proposal that potentially removes this End User detail requirement and then consider a policy proposal that would require them to put this detail back into the RIPE Database? ------------------------ On Thu, 11 Jan 2024 at 09:40, Tore Anderson <tore@fud.no> wrote:

Hello Denis,

On 11/01/24 01:40, denis walker wrote:

...

So personal data does not always need consent of the data subject. But you only ever refer to (a) consent.

There are indeed other possible lawful bases than consent, and this fact is precisely why I wrote (emphasis added):

«Publishing this information requires *a* lawful basis, *e.g.*, consent.»

Consent is however the only lawful basis singled out by the RIPE NCC in the RIPE Database Terms and Conditions and in the 2023-04 Impact Analysis, so it seems reasonable to assume that some LIRs will seek

consent. I wrote the T&C before GDPR was in place. That's why it doesn't refer to any of the other lawful options. I questioned the IA but the legal team chose not to respond.

Therefore we need to examine what that actually means in practice. You sum it up quite accurately below:

...

If we take the latest revelation in the IA on 2023-04, ALL PII needs consent, this has HUGE implications for the RIPE NCC and RIPE policy generally. We MUST have a good understanding of the legal basis for entering PII into the RIPE Database. Consent cannot be conditional. So if a resource holder who is a natural person withdraws their consent to have their PII in the database, it MUST be removed. That may leave an allocation and organisation with no identity or contacts. That would be a policy violation. BUT the resource cannot be reclaimed as that would have made the consent conditional. Also we have an abuse policy that requires all resources to have an abuse contact. If that contact is a natural person and they withdraw their consent their details must be deleted. Again that creates a policy violation. But the resource cannot be reclaimed again as that would have made the contact details consent conditional.

Your conclusion that this situation results in a policy violation, is however entirely contingent on your interpretation of the current policy as mandating the publication of the End User's (non-delegated) contact information.

You did not read what I wrote. I was talking about LIR contacts in allocation objects. If that is PII (and a lot of it is) the subjects can now ask for it to be removed. That may leave allocation objects with no LIR contacts. That is syntactically not possible in the RIPE Database.

Under the RIPE NCC's interpretation of the current policy, on the other hand, this situation is entirely unproblematic. Under their interpretation, the LIR has, quote, «freedom to take over the responsibility as the point of contact for their End User». No PII, no GDPR, no problem.

But if the LIR has NO contacts because they have asked for their details to be removed then you can't replace the End User contacts with non-existent LIR contacts. You and the legal team have started a chain reaction here by declaring that ALL contacts in the RIPE Database are there by consent. The RIPE NCC, as joint data controller for the RIPE Database, now has joint responsibility, and I presume therefore joint liability, for 2 million people having given their consent to their details being added into a PERSON object in the database.

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/0138...

...

Again you have selected just one example that can support your argument, Farmer Fred. I could have used KPN or Apple Inc as an example which would negate your argument.

KPN or Apple would not be relevant examples, as they (presumably) would use non-personal NOC roles which are not PII, and thus out of scope of the GDPR.

The RIPE NCC is a corporate body and yet it has many PERSON objects in the database relating to individual staff members as contacts for their resources. ------------------------ On Thu, 11 Jan 2024 at 09:45, Tore Anderson <tore@fud.no> wrote:

Hi Denis,

On 11/01/24 03:20, denis walker wrote:

...

On Wed, 10 Jan 2024 at 13:02, Tore Anderson <tore@fud.no> wrote:

...

On 10/01/24 11:25, Jan Ingvoldstad wrote:

...

Or you could take the other stance and stop publishing *any* contact details regarding an object, because you cannot know whether the information is personal data or not. Exactly. LIRs may (but are not required to) chose this approach already *today*. This is a common and long-standing practice which the RIPE NCC has repeatedly clarified as compliant with today's policy.

This is one of your biggest false statements. The ONLY person repeatedly saying this is YOU. Let's do a fact check here.

Yes, let us indeed do a fact check:

Your fact checking is not very accurate.

Exhibit 1:

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013...

This is the one time the RIPE NCC made this argument, which I have disputed.

Exhibit 2: https://www.ripe.net/participate/policies/proposals/2023-04 (specifically the «counter-argument», which the RIPE NCC Policy Officer confirmed to the proposers and the WG chairs as correctly representing the RIPE NCC's interpretation)

This 'counter argument' is your argument and is completely false.

Exhibit 3:

https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis

I have explained this above. This is the argument about LIRs adding Contact A or Contact B or email or phone. THAT is their decision. Who these contacts represent is set in the current policy and is not the LIR's choice.

Exhibit 4:

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/0138...

All the talk about maintainers, descr attributes, DB T&C and documentation has nothing to do with address policy. All they say here is that this proposal won't influence how the RIPE NCC currently carries out ARCs. They are doing it wrong now and will continue to do it wrong.

Four repetitions so far, all saying the same thing. How many more do you need?

One statement and no repetitions. They all say something different, which most people can clearly see.

...

...

As the RIPE NCC writes in the Impact Analysis (emphasis added):

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

...

...

Same repetitive argument again and again. Yes it IS the LIR's decision to enter Contact A or Contact B or email or phone. It is the POLICY that determines who those contacts represent. How many more times are we going to have this same discussion? (Which the legal team will not clarify.)

...

...

So, once again: which End User contact details LIRs publish (if any) is their decision today, and it will be continue to be their decision if 2023-04 passes.

YES AGAIN the LIR can always choose between Contact A and Contact B, email or phone. They cannot choose to not enter any End User contact details.

...

...

Hence, 2023-04 does not effect any change in this regard.

But as everyone else can see, this makes a huge change.

...

This really does make me cry. The wording in the IA is poor. You have applied an interpretation to this which I do not believe is what was meant. Then the RIPE NCC legal team has remained silent. So I am asking the RIPE NCC legal team to clearly explain what they meant by this wording.

The explanation you request was posted two days after the Impact Analysis was:

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/0138...

«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 explanation aligns perfectly with our interpretation of the statement in the Impact Analysis.

Wrong again. Yes the LIR is free to take over responsibility for technical matters. You can always find their contact details in the allocation object. So the public, civil society, LEAs, and other LIRs can choose who they want to contact...the LIR or the End User. Between the allocation and assignment objects you have all the contact details you need...according to current policy. The LIR does NOT have the freedom, according to current policy, to replace the admin-c and tech-c contacts in the assignment object with their own contact details in all situations. Again the current policy wording is clear and not interpretable: "Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." So you can ONLY replace the assignment contacts with those of the LIR IF the End User is an individual. Again this is simple, plain English, originally written by Leo and Mirjam.

...

...

Given that, it is hard to see how we could possibly amend the proposal to change this particular point to an even lesser extent than what is already the case? Let me help you. Do NOT remove a sentence that has nothing to do with the stated goal of the proposal to aggregate assignments and that you claim does not change anything.

This sentence also has a lot to do with the stated goal of aggregating assignments, because it mandates that assignments must be «registered separately». That is clearly incompatible with aggregation.

**** Finally, FINALLY you have admitted that this change that is not a change and that changes nothing does actually change something. **** It changes the registration requirements for assignments, which I have been saying all along and which you have been denying for months. ------------------------ On Thu, 11 Jan 2024 at 10:19, Jan Ingvoldstad <frettled@gmail.com> wrote:

On Thu, Jan 11, 2024 at 9:45AM Tore Anderson <tore@fud.no> wrote:

...

If our ulterior goal was to remove the End User contacts from our own assignments we can just go ahead and do so, right now. The RIPE NCC is already on the record saying that's totally OK, and we would be following in the footsteps of many other LIRs who have already done so.

While you seem to argue that the RIPE NCC is both omniscient and omnicompetent, I do not think it is that easy.

I simply think that the RIPE NCC and you are mistaken.

After talking to former members of RS I am beginning to think that the RIPE NCC is not mistaken. They know exactly what the current policy says and they know what it means. After all, it was written by former RS managers. BUT they don't believe they have any power to enforce it. This is why they quietly ignore what the policy says. I'll say more about that in my conclusion at the end of this email.

Continously appealing to RIPE NCC as the authority of policy and policy interpretation is not a good thing.

It undermines the community drive behind policies.

If this is where we are going, it seems that we would be just as well off by letting EU politicians run the show.

If you have watched John Curran's keynote speech at NANOG and think about the way a handful of operators are pushing this proposal through, the EU politicians WILL be running the show in the near future. https://www.youtube.com/watch?v=U1Ip39Qv-Zk

-- Jan

------------------------ On Thu, 11 Jan 2024 at 13:11, Tore Anderson <tore@fud.no> wrote:

On 11/01/24 10:19, Jan Ingvoldstad wrote:

...

Continously appealing to RIPE NCC as the authority of policy and policy interpretation is not a good thing.

The RIPE NCC is the secretariat of the RIPE Community and is delegated the task of implementing and enforcing the RIPE Community policies, as well as to providing training to the LIRs on how to operationalise said policies. If that is not an authority worth paying attention to, I do not know what is.

Exactly, the RIPE NCC is the secretariat, not the policy decision maker. They are supposed to enforce community derived policy. IF they don't think they have the powers to enforce a policy they should raise that issue with the community and seek guidance. They should not just quietly ignore the policy, or part of it.

After all, any LIR which prefers the RIPE NCC interpretation of the policy in this regard is may simply adhere to it and act accordingly, and this is commonly done today. Thus the RIPE NCC's interpretation of the policy – mistaken or not – ends up becoming the (de facto) way the policy is implemented anyway.

If a policy has unintentional interpretations it is badly written. LIRs should not be in a position to choose between a community view and the RIPE NCC's view of a policy. A RIPE NCC interpretation of a policy that conflicts with a community view should not become a de facto implementation. If such a situation arises the conflict must be resolved. ------------------------ On Thu, 11 Jan 2024 at 14:11, Tore Anderson <tore@fud.no> wrote:

Hi Jan,

On 11/01/24 13:27, Jan Ingvoldstad wrote:

...

On Thu, Jan 11, 2024 at 1:11PM Tore Anderson <tore@fud.no> wrote:

After all, any LIR which prefers the RIPE NCC interpretation of the policy in this regard is may simply adhere to it and act accordingly, and this is commonly done today. Thus the RIPE NCC's interpretation of the policy – mistaken or not – ends up becoming the (de facto) way the policy is implemented anyway.

This statement basically renders the point of a policy working group

moot.

I totally agree.

Not at all. Any working group member who is of the opinion that the RIPE NCC is interpreting a RIPE Community policy incorrectly, is free to at any point submit a policy proposal that clarifies the allegedly misinterpreted policy text with the aim to make the RIPE NCC change its procedures accordingly.

A policy proposal would only be needed if the policy is so badly written it needs clarity. When the policy is clear and simple, but the RIPE NCC is either misinterpreting it or doesn't believe it has the power to enforce it, we don't need a policy change. We need an interpretation change.

The RIPE NCC's Impact Analysis will then reveal whether or not the proposed new policy text does attain its goal and that the RIPE NCC will change its procedures as desired, should the proposal pass.

Finally, the proposal will need to reach (rough) consensus in order to confirm that the RIPE Community does indeed concur with the proposer's opinion that the old policy was interpreted incorrectly, and that the RIPE NCC's procedures ought to change.

You do not write policy proposals to change the RIPE NCC's interpretation of existing policy.

Absent this, the RIPE NCC's operationalisation of the policy will stay as-is.

------------------------ On Thu, 11 Jan 2024 at 14:35, Sebastian Graf <ripe-lists@sebastian-graf.at> wrote:

Dear Tore/Denis:

If we are looking at the Policy Language, then i'm not certain we are

Or maybe i missed something. Feel free to point out the corresponding

As a small LIR ... I may not see all edge cases.... but...... So feel free to point out anything important that i may have missed.

Lets look at the actual language in the policy:

...

"All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations."

The way i read it, this point is filled both with the current state of

reading the same things into it. section of the policy to me. I'm more than happy to update my views if strong evidence is presented. things, and also if we have an aggregated status. Space would still be registered. So the question is what kind of data needs to accompany it.

Actually this point is not satisfied by aggregation. When you have all assignments separately registered, as current policy requires and the proposers of this policy update have finally agreed is the case, you can see that each assignment is unique. You cannot assign the same space to two End Users as you cannot create two assignment objects with the same or overlapping prefix. With an aggregation object, all you know is that some part(s) of this aggregated block may be assigned to one or more End Users. You do not know how much is in use, or even if any of the aggregated space is currently in use. It does not satisfy the uniqueness condition as you can't be sure some of the space has not been multiply assigned.

So lets look at what needs to be documented:

...

"Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)."

I think you are arguing what both of you are considering "contact information". It does NOT say we state to put personally identifyable information into it.

You are totally correct here. I have never argued for putting PII into the database.

If we read the text literally, then only putting enough information to establish a contact (ie: contact information) would theoretically be sufficient. So theoretically, a "proxy" type of setup for email/postal mail/... could be permissiable as long as any communication/... is forwarded to the the actual responisble party.

In fact i would argue for most businesses (End-User or ISP) this is already the case if they make use of "role" contacts for their admin/noc/abuse/... handling.

...

"Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)."

The other thing that i do not read from the statement is where it asks to

Also correct. put "contact information" for the End-User. It simply reads contact information (one could theoretically interpret this as "contact information for the party that is responsible for managing the space....).

You are missing the infamous lines this proposal wants to delete from the current policy: "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's."

ANYWAY....

I still do not feel anything of significance would be lost, if something could be lost at all.

I guess you don't accept that the registration details of End Users is significant.

My personal opinion goes the other way.....I suspect, if anything aggregated status could potentially lead to more accurate data. Let me explain: With the aggregation we gain better understanding of the network usage. PLUS the ability to create more specific assignments (under the aggregated). So This way, i feel more usable data would be int the database, compared to now.

This would also be in line with the goals in Section 3.0 - Point 2 "Agregation: Distributing IPv4 addresses in an hierarchical manner permits

With an aggregated block all/some/none of the space covered by this block may be in use by one/many/no End Users. You have no idea about network usage. All that detail may be lost. the aggregation of routing information.".

Aggregating address space registration details has nothing at all to do with routing aggregation.

If we look at the goal for registration: "Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.".

If we consider the usefulnes of data entered into the ripe-db for this

Aggregating assignment data does not guarantee uniqueness, or provide information for Internet troubleshooting at ALL levels. purpose, then most useful will be the ISP contact information. Contact information for End-Users (could be an ISP as well) would also be useful in some cases. Personal Information for "individual" type end users (ie: Fred Testuser's DSL Line that comes with a Public IPv4 Address)....to a lesser extend.

If we look at Section 3.1 ...it reads "Internet Registries (IRs) have a

duty of confidentiality to their registrants. Information passed to an IR must be securely stored and must not be distributed wider than necessary within the IR.".

So i am not certain why you are trying to force more data than actually

required/useful into the db. And yes in this context i would consider LIR's in this to be part of this as some type of "local" IR's.

During the writing of this email, i realised that you (denis/tore) may consider the need/usecase for adding a "restricted" flag into the DB, that would allow adding information, that is only shown to a select audience (ie: law enforcment, ripe staff and Ripe-Members) - wich could be used to

There is always a balance between privacy and the needs of civil society. It was decided many years ago that anyone operating a network using public address space should have contact details available in a public registry. That is still what the current policy says with wording written by Leo (AP WG co-chair, former RS manager) and Mirjam (RIPE chair). The original source of this requirement goes back to address policy written in the 1990s by many varied authors including Daniel (RIPE NCC founder) and Hans Petter (RIPE NCC CEO and former AP WG and LIR WG chair). Unfortunately no one is willing to provide any background information to the current RIPE community about why these rules were originally imposed. That makes it difficult to discuss if those original conditions still apply to the current stakeholders of the RIPE Database, who we also can't easily identify. publish PII data. HOWEVER doing something like that would "extend" the existing usecase(s) of the DB and dataentry required - as such this should be in a different Policy Proposal/wg-discussion. Feel free to put one forward, that we can discuss....

I did consider this option when I put forward my RIPE Database Privacy policy proposal some time ago. The idea of multi level access was not very popular. ------------------------ On Fri, 12 Jan 2024 at 08:12, Tore Anderson <tore@fud.no> wrote:

Good morning Jan,

On 12/01/24 07:25, Jan Ingvoldstad wrote:

...

I also do not understand what makes it so hard to say that: "Yes, the current policy does state something else than NCC's interpretation of it does, (…)

We do not make statements that we do not believe to be true.

In our opinion, the RIPE NCC implements current policy correctly.

How can you keep saying this when everyone knows it is not true. Regardless of whether or not you support the way the RIPE NCC currently implements the policy, it is NOT what the policy says. We have been over this so many times. The policy is so clear in simple, plain English. For whatever reason, the way the RIPE NCC implements the policy today is NOT what the current policy so clearly says, as written by a co-chair of this WG. You even admitted it yourself in an earlier email (listed above) where you said (and these are YOUR words):

After all, any LIR which prefers the RIPE NCC interpretation of the policy in this regard is may simply adhere to it and act accordingly, and this is commonly done today. Thus the RIPE NCC's interpretation of the policy – mistaken or not – ends up becoming the (de facto) way the policy is implemented anyway.

------------------------ On Fri, 12 Jan 2024 at 08:57, Sebastian Graf <ripe-lists@sebastian-graf.at> wrote:

Dear Jan!

As mentioned in my previous e-mail: Would you please post the section of the policy that you belive has the NCC's interpretation differ from the actual wording/language used?

Because i have yet to find a section that states explicitly what is considered valid vs invalid contact information (other than being out of date or information that does not provide a contact to the user in a timely manner). Or a section that restricts what kind of data is permissable for "contact information".

It is not a question of what is (in)valid contact information. It is about who the contact details refer to. End User or LIR. ------------------------ On Fri, 12 Jan 2024 at 09:28, Sebastian Graf <ripe-lists@sebastian-graf.at> wrote:

Dear Jan!

Thank you for your reply. But you have not answerred my question.

We are all clear/well aware on the fact that the policy states

(paraphrasing here: resources need to be registered and the registions need to have contact information).

We are looking for the DEFINITION of "contact details of the End User.".

This is not directly defined (as far as i can tell) and is therefore open for interpretation.

Unless i missed something?

Yes you have missed something. Take your sentence above "contact details of the End User". This can be split into two parts: "contact details" "of the End User." You are right, there is no definition of "contact details". So it doesn't matter if this is email, phone, fax, postal address or if it is in a role or person object or if it is corporate or personal data. Much of this does matter when it comes to privacy concerns, but that is another discussion. What we are primarily discussing here is the other part "of the End User." So the contact details don't matter for this discussion as long as they collectively refer to the End User. And this reference is not open to any interpretation according to the current policy. ------------------------ On Fri, 12 Jan 2024 at 10:35, Sebastian Graf <ripe-lists@sebastian-graf.at> wrote:

Dear Jan!

You and Denis are arguing that registration/user data needs to include

certain (sometimes sensitive details (ie: PII)) that need to be put in the database. Your Argument is that this is a policy requirement.

That is NOT what we are arguing. There is no policy requirement regarding the nature of the contact details. The policy states who the contact details should refer to, ie End User or LIR, for example.

When I tried to get both of you to spell out what this "user data"/"contact information" is exactly and where that is defined - We do not get a clear answer.

Because it is not what we are arguing and it is not defined anywhere.

I have read every single of denis replies/comments.

When asked, neither of you cannot reference a policy section that actually spells out what is considered "contact details".

Because the policy doesn't define this and it is not relevant to this discussion.

According to your own e-mail - your opinion is based on a software interface/implementation (ripe-db). This interface itself is an interpretation of what the policy could mean. The Interface of the DB also does not specify what kind of Information (regular address, proxy address,...) needs to be inserted. Just that some fields need to be filled out (and its open to interpret what goes into them to a certain extent - wich is the point of this discussion).

The relationship is policy -to- database. Not Database -to- Policy.

And yet, we have no document or reference that defines what kind of contact information (direct only, or indirect via proxy/masking/....) is

Sorry but you have missed the point again. The discussion has nothing to do with RIPE Database interfaces, forms or attribute contents. It is about WHO these details refer to. permissable. Correct, and it is not relevant.

Just that it needs to be maintained (meaning "if it works" -> OK).

All data in the RIPE Database should be maintained and kept up to date.

In my previous e-mail i did argue that in some scenarios working witout"proxy" data is impossible (think: Role/NOC Contacts).

ROLE or PERSON object is also irrelevant to this discussion.

I have also read your reference https://www.ripe.net/publications/docs/ripe-705 . It defines an abuse inbox is mandatory for certain objects. And that it has to be an email address. - Nothing else.

Also irrelevant to this discussion. ------------------------ So where does all this leave us? During this discussion we have established that: -We do not understand what many elements of data in the RIPE Database mean. -There are some historical definitions in old documents. These definitions have never been updated, so technically they are the only current definition available. But some of these definitions do not map exactly into the modern world. -Some registration requirements were written in the early 1990s. Some were re-written in 2003. Much of this was written by people who still have a high profile in the RIPE community or RIPE NCC today. -We do not know what the reasoning was for why these requirements were introduced. -We do not know who the major stakeholders are who use the data in the RIPE Database or what information they want and need or what they use it for. -We have no business requirements for the RIPE Database as a public registry. -We do not know what data needs to be registered in the RIPE Database or what information it needs to serve to who for what purpose. -An unknown amount of assignment data in the RIPE Database does not comply with current address policy. -The RIPE NCC does not enforce the current address policy. This may be because the RIPE NCC does not believe they have the power to enforce current policy. -Some members have made it clear they will not enter any of their customer's details into a public registry no matter what policy says for commercial sensitivity reasons. While there are interpretations of current policy they may be considered in violation of policy. So there are other reasons why some people may want to push through this change in End User registration. -We do not know what the potential consequences may be for some stakeholders by making this change. So given all these unknowns, should we go ahead and make this change? It seems like this has been a long and intense discussion. Some people may think we have had sufficient input from the community to be able to make a decision on consensus. But as is often the case, statistics beat perception. So let's look at some numbers. Excluding the chairs, proposers and RIPE NCC staff there have been 22 people who commented on this discussion over the last 6 months. Of these 6 people only made 1 comment and another 6 made 2 comments. Then 8 people made 3 to 6 comments. One person made 12 and one made 24 comments. Also 5 people made up the '+1' brigade. These numbers cover both supporters and objectors. This is quite typical of policy discussion. Many of the 'regular' vocal community members who are involved in almost all policy discussions are included in these numbers. So we are looking at a very small number of people who actually support this proposal. Given all the unknowns we have identified during this discussion and the very small number of supporters, should we still approve this proposal? Bear in mind also that the proposal is basically about adding an inconsequential, minor, optional feature change for the convenience of some operators. It also makes a huge change to the registration requirements of End User assignments which will have an unknown impact on the public registry and some major stakeholders. Now let's add in some other factors. I really do recommend that you all watch John Curran's keynote speech to NANOG about internet governance. https://www.youtube.com/watch?v=U1Ip39Qv-Zk He makes some very interesting points that are highly relevant to this discussion. He talks about 3 phases of the internet. The first one was the early development, done largely by universities and other early adopters of the technology, but largely paid for by governments. Then we went into the commercial phase that covers much of the last 20 years or so. But now we are moving into a public phase where civil society is more knowledgeable and is much more heavily involved. During the commercial phase the tech community could pretty much do what they wanted. If questioned by any parts of civil society or regulators they could just fob them off with No No No No... In the new public phase politicians, regulators, organisations involved in public order are much more aware of the interest by civil society (people who vote in elections). The public is aware of the dangers of the internet as well as the benefits. Politicians and regulators must be seen to be in control. So the days of the tech community saying No No No No to them are over. Now it must be at least No No No Maybe. The Maybe allows the tech community to write something down that they can live with, that politicians can refer to in regulations and everyone is happy. So how does this relate to 2023-04? We have a public registry that we built and maintain. But there are so many things we don't understand now in the 2020s. We all know what the registry was. My research has reminded you of some of the early details. But what is it now and what should it be tomorrow? We don't have answers to these questions. In the face of all these unknowns we want to add an inconsequential feature that could have a massive impact in other areas that we don't fully understand. We know LEAs have serious concerns. But we have just brushed them aside. This very small group of operators that took part in this discussion have prioritised their own convenience over anything else. They have turned that Maybe back into a No. If you approve this proposal with all these unknowns I think you will find that train full of regulators that is rumbling down the line, heading straight for you, will pick up speed. Think of the LEAs sitting in a room behind two doors. One of those doors opens up to the tech community. You are about to slam that door in their face. The other door opens up to the politicians. We still have the option to invite them into our room and talk seriously with them about their needs. Once you slam that door shut, they will walk through the other door and you lose control. Yes I know I am a drama queen. But I am trying to illustrate to you that actions have consequences. Today's consequences may be very different to those of yesterday in a similar situation. Nothing stays the same forever. So is it worth risking the wrath of the politicians for what has been described as a minor, optional feature change that some will find convenient? Let me end by suggesting an alternative path. I have said all this before and been ignored or insulted. But I will say it again anyway. I am used to being insulted on these lists with no one protecting me. 1/ Withdraw this proposal 2023-04 2/ Set up a new Task Force with these primary goals: a/ Determine the business requirements for the RIPE Database as a public registry, looking forwards. b/ Identify the major stakeholders for the RIPE Database public registry. c/ Identify the needs/wants of these stakeholders. d/ Based on the above, determine the registration needs of the public registry, taking account of privacy concerns. 3/ Once we know what we want, design a new data model for the RIPE Database. 4/ Slowly move from where we are now to where we want to be. Yes I know this is a long term project and yes it will cost money. But the RIPE Database is so old, with so many things lost in the mists of time, so many things not applicable to the modern world. If you continue turning your back on all this, you may find the regulators will tell you what they want in the registry. That may be far more costly. I don't think there is anything more I can say on this issue now. cheers denis ======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================

Hi Erik On Tue, 13 Feb 2024 at 16:56, Erik Bais <erik@bais.name> wrote:

Dear Denis,

Thank you for your long email.

This policy in particular is quite clear and although it proposes on how to change/register assignments in the database, it doesn’t talk about a complete database redesign or overhaul.

If you like to create a full TF or alike to have a discussion about the state of the DB, please do so in the correct WG for it. ( please read this as . . . not in AP-WG )

You are right that such a discussion is better suited to the DB-WG. However I will make one last point here. The boundaries of WG topics are not black and white. There is often overlap between WGs. Throughout this discussion, the fact that the database is such a difficult tool to use and requires considerable manual effort on the part of LIRs to maintain the registration data within, has been used as justification for changing the registration requirements. When we clearly don't understand the reasoning behind the registration requirements we have today, I still argue it is wrong to change registration requirements just for the convenience of making a historic tool easier to use. The correct approach is to fix the tool. cheers denis

So, yes we’ve read your email and we will note your objection.

Regards,

Erik Bais

on behalf of the Co-Chair collective of the AP-WG.

From: address-policy-wg <address-policy-wg-bounces@ripe.net> on behalf of denis walker <ripedenis@gmail.com> Date: Saturday, 10 February 2024 at 09:10 To: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Cc: Tore Anderson <tore@fud.no>, Jan Ingvoldstad <frettled@gmail.com> Subject: Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Colleagues

I am back!! Thanks to those who agreed I should never have been away. I am not going to focus on that for now. I do have a lot to say around that issue. But that is for another day, on another mailing list. I won't discuss it here and I will wait until we conclude the discussion on this proposal. I want people to focus on the message rather than the messenger.

There hasn't been much conversation while I have been away, but still several significant points that seemed to have been missed by most observers. I have answered all points raised by several people in this single email. In these days of uncertainty, who knows how long any of us will be around. So it is more of an article than an email. But I do end with a positive recommendation.

Let's start with a comment by Leo: "We encourage everyone to focus comments on the proposal and its potential impact. Do not comment on individuals, their characteristics, or motivations." The co-chairs have no authority to determine what constitutes part of this discussion. If individuals use tactics that may confuse the community or repeatedly make comments that are not true, they make themselves part of the discussion. The co-chairs have no right to try to prevent these issues from being highlighted and discussed. People need to understand that personal criticism is not a personal attack, even if it is strong criticism. When an individual repeatedly says something that is not true, to highlight this issue and ask them why they keep saying this is not a personal attack. Criticism is part of life, especially in business. Throughout this discussion there has been lots of criticism thrown at me. My characteristics have been heavily criticised and commented on. Even who I speak for has been questioned. No one has questioned if an employee speaks on behalf of their employer. My motivations have also been questioned. It was suggested that I should not talk about the RIPE Database on the Address Policy WG. Even though the old design and technology of the database is one of the key elements used to support the need for aggregation. So much criticism aimed at me and yet the co-chairs saw no reason to intervene. They only intervene when I criticise someone.

Then there is motivation. Is it questionable? A lot of the discussion on policy is political, commercial and self interest based. In these contexts I believe it is acceptable to question motivation. The co-chairs never asked what I meant by what I said. Of course the proposal is about aggregation. It's in the title and the text. But it is about a lot more than that. There are two main aspects to this proposal. An inconsequential, minor feature change that people may or may not use. And a major change to the handling of End User details, which people also may or may not take advantage of. The two aspects combined can make a massive change to the available information in the RIPE Database. But the proposal did not even mention the change to End User details. Is it important? Well after I pointed it out, some people who had said "+1 I agree with this proposal" changed their mind and withdrew their support. So for them it was highly relevant. There are sections in the proposal template for supporting and opposing issues relating to the proposal. Depending on your point of view this major change should have been listed in one of those sections. But it wasn't. So did the proposers fully understand the implications of this change or not? I must be allowed to ask that question as part of this discussion. If they did understand it, why did they not mention it? Did they overlook it, or was there some other reason? Again I have to be able to ask these questions. This is all about motivation. To ask these questions and understand what happened is not a personal attack. It is a reasonable line of inquiry.

Enough about the messenger, let's get back to the message.

------------------------

On Mon, 18 Dec 2023 at 16:49, Edwin Verheul via address-policy-wg <address-policy-wg@ripe.net> wrote:

...

I support this proposal.

Since this policy introduces convenience for LIR by aligning ipv4 object policy to the ipv6 policy, unclear usage of the admin contact should not prevent this improvement in policy.

This pretty much sums up a lot of people's view of this proposal. It is 'convenient' for the operators. Who cares if it is the right thing to do or not, it is convenient. It doesn't align v4 and v6, there are significant differences in the defined aggregations. Never mind if we don't understand what the data means, let's just change it anyway as it is convenient.

Maybe a few of you should watch John Curran's keynote speech at NANOG on internet governance: https://www.youtube.com/watch?v=U1Ip39Qv-Zk

He talks about phases of the internet and how we are now moving from the 'commercial' internet to the 'public' internet. With this public internet, civil society has/wants a much bigger say in how things work. Organisations that represent civil society and civil order are more concerned about how things work. Politicians are concerned about what their voters think. Do you think civil society cares about operator convenience? They are more likely to think 'it's your job, do it. That's what we pay you for'. I think civil society will be more interested in knowing who is spamming them or attacking their network and can the police catch them, rather than operator convenience.

Now let's think a bit more about what this data means and how to interpret it.

------------------------

On Fri, 12 Jan 2024 at 08:56, Alex Le Heux <alexlh@funk.org> wrote:

...

During the discussion about AGGREGATED-BY-LIR status for IPv4 PA assignments the argument has been raised that this proposal would substantially change the registration requirements for end-user assignments in the RIPE DB and the discussion has been going around in circles ever since.

We would like to point out the following:

From the RIPE NCC Impact Analysis:

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 completely out of context. I have asked the RIPE NCC legal team to clarify what this means but I guess by their silence they declined. To me this sentence says the member can choose to enter the details of Contact A or Contact B and choose what the details are. Which one (A or B) and the details (email or phone) they enter will be their decision. The RIPE NCC cannot enforce if they enter A or B or email or phone. WHO these contacts represent is a matter of policy. The current policy says they MUST be representatives of the End User. That can be enforced by the RIPE NCC, but they choose not to enforce it.

...

As well as:

It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time.

This is completely false. I know Alex well and will give him the benefit of the doubt that he has not picked up on the detail here. He signed this email 'for the Address Policy WG co-chairs'. A lot was said about who I speak for, so I assume Alex was speaking 'for' all the chairs. I was told that signing as 'co-chair DB-WG' gives what I say more weight and has more influence on the community. The same must apply when the co-chairs of this WG collectively sign an email. The community will assume that statement carries more validity.

Let's look at the detail. Address policy from the early 1990s has made it clear that assignments must include contact details of the End User. But ripe-288, 28 Oct 2003 is particularly interesting. The authors of this version of the address policy were: Mirjam Kühne, Paul Rendek, Sabrina Wilmot, Leo Vegoda At that time they were all current or former NCC staff. Leo was the operations manager of the RIPE NCC Registration Services (RS). Paul was the senior manager responsible for RS. In this version, these authors added the exact wording that we have today: "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." The wording was very different before this. The document was restructured and the wording changed. So they must have thought about what this meant. I cannot believe that when these words were added to the policy by the RS manager and RS senior manager they were not enforced by RS. Maybe Leo can give some background to this.

Nothing in this industry changes quickly. So if these newly worded requirements were enforced just 20 years ago, they must have been enforced for at least 5 to 10 years. That means the RIPE NCC's interpretation of this wording, written by the RS manager, has only changed in the last 5 to 10 years. I have been told by some former members of RS that they stopped enforcing these requirements at runout of IPv4. They told me that when they had no more address space to allocate, they had no power to enforce these rules. So they simply stopped enforcing them. This paints a very different picture. We are not changing policy to match a common practice. We are dropping policy because it is difficult to enforce, regardless of the reasons why the policy was introduced.

It is also interesting that, no matter how many times you read something, you don't always see what it says. A lot has been said about replacing the admin-c and tech-c contacts in an assignment with the contacts of the LIR. It has been said that the RIPE NCC now considers this acceptable. But look at what the current policy actually says: "Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." So this substitution is only allowed by policy where the End User is an individual. You cannot do it for all End Users. This actually makes sense to me. If I want to contact the LIR's tech or admin contacts, they are already available in the RIPE Database in the allocation object. Why duplicate the data in the assignment. The policy says the assignment must have the End User's contacts. So that is another misinterpretation of the current policy.

...

In its impact analysis the RIPE NCC has indicated that this proposal does not change this interpretation.

It should therefore be clear that 2023-04 does not in fact change anything regarding how end-user details will actually be registered in PA Assignments.

Interesting choice of words. It may not change how some End User details 'will' actually be registered, but it changes how they 'should' be registered enormously.

...

However, is has been argued that this interpretation is wrong and that PA Assignments in the RIPE DB must include the actual end-user details. And even though this is out of scope for the 2023-04 discussion, it is still something that is worth resolving. As changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects, we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one.

I agree this needs further clarification. But you can't write a policy proposal on something you don't understand. We don't know what much of the data means now or in the past, or why we have these rules, or what we need now. Until we have the business requirements for the RIPE Database as a public registry any such policy proposal, including this one, is just a dangerous stab in the dark.

...

Kind regards,

Alex Le Heux, for the Address Policy WG co-chairs

It is interesting that this email was signed 'for' all the co-chairs of this WG. How can the co-chairs approve this policy proposal (2023-04) while accepting that another proposal is needed to clarify if the RIPE Database must include the actual End User contact details? Are they going to approve a policy proposal that potentially removes this End User detail requirement and then consider a policy proposal that would require them to put this detail back into the RIPE Database?

------------------------

On Thu, 11 Jan 2024 at 09:40, Tore Anderson <tore@fud.no> wrote:

...

Hello Denis,

On 11/01/24 01:40, denis walker wrote:

...

So personal data does not always need consent of the data subject. But you only ever refer to (a) consent.

There are indeed other possible lawful bases than consent, and this fact is precisely why I wrote (emphasis added):

«Publishing this information requires *a* lawful basis, *e.g.*, consent.»

Consent is however the only lawful basis singled out by the RIPE NCC in the RIPE Database Terms and Conditions and in the 2023-04 Impact Analysis, so it seems reasonable to assume that some LIRs will seek consent.

I wrote the T&C before GDPR was in place. That's why it doesn't refer to any of the other lawful options. I questioned the IA but the legal team chose not to respond.

...

Therefore we need to examine what that actually means in practice. You sum it up quite accurately below:

...

If we take the latest revelation in the IA on 2023-04, ALL PII needs consent, this has HUGE implications for the RIPE NCC and RIPE policy generally. We MUST have a good understanding of the legal basis for entering PII into the RIPE Database. Consent cannot be conditional. So if a resource holder who is a natural person withdraws their consent to have their PII in the database, it MUST be removed. That may leave an allocation and organisation with no identity or contacts. That would be a policy violation. BUT the resource cannot be reclaimed as that would have made the consent conditional. Also we have an abuse policy that requires all resources to have an abuse contact. If that contact is a natural person and they withdraw their consent their details must be deleted. Again that creates a policy violation. But the resource cannot be reclaimed again as that would have made the contact details consent conditional.

Your conclusion that this situation results in a policy violation, is however entirely contingent on your interpretation of the current policy as mandating the publication of the End User's (non-delegated) contact information.

You did not read what I wrote. I was talking about LIR contacts in allocation objects. If that is PII (and a lot of it is) the subjects can now ask for it to be removed. That may leave allocation objects with no LIR contacts. That is syntactically not possible in the RIPE Database.

...

Under the RIPE NCC's interpretation of the current policy, on the other hand, this situation is entirely unproblematic. Under their interpretation, the LIR has, quote, «freedom to take over the responsibility as the point of contact for their End User». No PII, no GDPR, no problem.

But if the LIR has NO contacts because they have asked for their details to be removed then you can't replace the End User contacts with non-existent LIR contacts. You and the legal team have started a chain reaction here by declaring that ALL contacts in the RIPE Database are there by consent. The RIPE NCC, as joint data controller for the RIPE Database, now has joint responsibility, and I presume therefore joint liability, for 2 million people having given their consent to their details being added into a PERSON object in the database.

...

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/0138...

...

Again you have selected just one example that can support your argument, Farmer Fred. I could have used KPN or Apple Inc as an example which would negate your argument.

KPN or Apple would not be relevant examples, as they (presumably) would use non-personal NOC roles which are not PII, and thus out of scope of the GDPR.

The RIPE NCC is a corporate body and yet it has many PERSON objects in the database relating to individual staff members as contacts for their resources.

------------------------

On Thu, 11 Jan 2024 at 09:45, Tore Anderson <tore@fud.no> wrote:

...

Hi Denis,

On 11/01/24 03:20, denis walker wrote:

...

On Wed, 10 Jan 2024 at 13:02, Tore Anderson <tore@fud.no> wrote:

...

On 10/01/24 11:25, Jan Ingvoldstad wrote:

...

Or you could take the other stance and stop publishing *any* contact details regarding an object, because you cannot know whether the information is personal data or not. Exactly. LIRs may (but are not required to) chose this approach already *today*. This is a common and long-standing practice which the RIPE NCC has repeatedly clarified as compliant with today's policy.

This is one of your biggest false statements. The ONLY person repeatedly saying this is YOU. Let's do a fact check here.

Yes, let us indeed do a fact check:

Your fact checking is not very accurate.

...

Exhibit 1: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013...

This is the one time the RIPE NCC made this argument, which I have disputed.

...

Exhibit 2: https://www.ripe.net/participate/policies/proposals/2023-04 (specifically the «counter-argument», which the RIPE NCC Policy Officer confirmed to the proposers and the WG chairs as correctly representing the RIPE NCC's interpretation)

This 'counter argument' is your argument and is completely false.

...

Exhibit 3: https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis

I have explained this above. This is the argument about LIRs adding Contact A or Contact B or email or phone. THAT is their decision. Who these contacts represent is set in the current policy and is not the LIR's choice.

...

Exhibit 4: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/0138...

All the talk about maintainers, descr attributes, DB T&C and documentation has nothing to do with address policy. All they say here is that this proposal won't influence how the RIPE NCC currently carries out ARCs. They are doing it wrong now and will continue to do it wrong.

...

Four repetitions so far, all saying the same thing. How many more do you need?

One statement and no repetitions. They all say something different, which most people can clearly see.

...

...

...

As the RIPE NCC writes in the Impact Analysis (emphasis added):

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

Same repetitive argument again and again. Yes it IS the LIR's decision to enter Contact A or Contact B or email or phone. It is the POLICY that determines who those contacts represent. How many more times are we going to have this same discussion? (Which the legal team will not clarify.)

...

...

...

So, once again: which End User contact details LIRs publish (if any) is their decision today, and it will be continue to be their decision if 2023-04 passes.

YES AGAIN the LIR can always choose between Contact A and Contact B, email or phone. They cannot choose to not enter any End User contact details.

...

...

...

Hence, 2023-04 does not effect any change in this regard.

But as everyone else can see, this makes a huge change.

...

...

This really does make me cry. The wording in the IA is poor. You have applied an interpretation to this which I do not believe is what was meant. Then the RIPE NCC legal team has remained silent. So I am asking the RIPE NCC legal team to clearly explain what they meant by this wording.

The explanation you request was posted two days after the Impact Analysis was:

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/0138...

«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 explanation aligns perfectly with our interpretation of the statement in the Impact Analysis.

Wrong again. Yes the LIR is free to take over responsibility for technical matters. You can always find their contact details in the allocation object. So the public, civil society, LEAs, and other LIRs can choose who they want to contact...the LIR or the End User. Between the allocation and assignment objects you have all the contact details you need...according to current policy.

The LIR does NOT have the freedom, according to current policy, to replace the admin-c and tech-c contacts in the assignment object with their own contact details in all situations. Again the current policy wording is clear and not interpretable: "Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's." So you can ONLY replace the assignment contacts with those of the LIR IF the End User is an individual. Again this is simple, plain English, originally written by Leo and Mirjam.

...

...

...

Given that, it is hard to see how we could possibly amend the proposal to change this particular point to an even lesser extent than what is already the case? Let me help you. Do NOT remove a sentence that has nothing to do with the stated goal of the proposal to aggregate assignments and that you claim does not change anything.

This sentence also has a lot to do with the stated goal of aggregating assignments, because it mandates that assignments must be «registered separately». That is clearly incompatible with aggregation.

**** Finally, FINALLY you have admitted that this change that is not a change and that changes nothing does actually change something. **** It changes the registration requirements for assignments, which I have been saying all along and which you have been denying for months.

------------------------

On Thu, 11 Jan 2024 at 10:19, Jan Ingvoldstad <frettled@gmail.com> wrote:

...

On Thu, Jan 11, 2024 at 9:45AM Tore Anderson <tore@fud.no> wrote:

...

...

If our ulterior goal was to remove the End User contacts from our own assignments we can just go ahead and do so, right now. The RIPE NCC is already on the record saying that's totally OK, and we would be following in the footsteps of many other LIRs who have already done so.

...

While you seem to argue that the RIPE NCC is both omniscient and omnicompetent, I do not think it is that easy.

I simply think that the RIPE NCC and you are mistaken.

After talking to former members of RS I am beginning to think that the RIPE NCC is not mistaken. They know exactly what the current policy says and they know what it means. After all, it was written by former RS managers. BUT they don't believe they have any power to enforce it. This is why they quietly ignore what the policy says. I'll say more about that in my conclusion at the end of this email.

...

Continously appealing to RIPE NCC as the authority of policy and policy interpretation is not a good thing.

It undermines the community drive behind policies.

If this is where we are going, it seems that we would be just as well off by letting EU politicians run the show.

If you have watched John Curran's keynote speech at NANOG and think about the way a handful of operators are pushing this proposal through, the EU politicians WILL be running the show in the near future. https://www.youtube.com/watch?v=U1Ip39Qv-Zk

...

-- Jan

------------------------

On Thu, 11 Jan 2024 at 13:11, Tore Anderson <tore@fud.no> wrote:

...

On 11/01/24 10:19, Jan Ingvoldstad wrote:

...

Continously appealing to RIPE NCC as the authority of policy and policy interpretation is not a good thing.

The RIPE NCC is the secretariat of the RIPE Community and is delegated the task of implementing and enforcing the RIPE Community policies, as well as to providing training to the LIRs on how to operationalise said policies. If that is not an authority worth paying attention to, I do not know what is.

Exactly, the RIPE NCC is the secretariat, not the policy decision maker. They are supposed to enforce community derived policy. IF they don't think they have the powers to enforce a policy they should raise that issue with the community and seek guidance. They should not just quietly ignore the policy, or part of it.

...

After all, any LIR which prefers the RIPE NCC interpretation of the policy in this regard is may simply adhere to it and act accordingly, and this is commonly done today. Thus the RIPE NCC's interpretation of the policy – mistaken or not – ends up becoming the (de facto) way the policy is implemented anyway.

If a policy has unintentional interpretations it is badly written. LIRs should not be in a position to choose between a community view and the RIPE NCC's view of a policy. A RIPE NCC interpretation of a policy that conflicts with a community view should not become a de facto implementation. If such a situation arises the conflict must be resolved.

------------------------

On Thu, 11 Jan 2024 at 14:11, Tore Anderson <tore@fud.no> wrote:

...

Hi Jan,

On 11/01/24 13:27, Jan Ingvoldstad wrote:

...

On Thu, Jan 11, 2024 at 1:11PM Tore Anderson <tore@fud.no> wrote:

After all, any LIR which prefers the RIPE NCC interpretation of the policy in this regard is may simply adhere to it and act accordingly, and this is commonly done today. Thus the RIPE NCC's interpretation of the policy – mistaken or not – ends up becoming the (de facto) way the policy is implemented anyway.

This statement basically renders the point of a policy working group moot.

I totally agree.

...

Not at all. Any working group member who is of the opinion that the RIPE NCC is interpreting a RIPE Community policy incorrectly, is free to at any point submit a policy proposal that clarifies the allegedly misinterpreted policy text with the aim to make the RIPE NCC change its procedures accordingly.

A policy proposal would only be needed if the policy is so badly written it needs clarity. When the policy is clear and simple, but the RIPE NCC is either misinterpreting it or doesn't believe it has the power to enforce it, we don't need a policy change. We need an interpretation change.

...

The RIPE NCC's Impact Analysis will then reveal whether or not the proposed new policy text does attain its goal and that the RIPE NCC will change its procedures as desired, should the proposal pass.

Finally, the proposal will need to reach (rough) consensus in order to confirm that the RIPE Community does indeed concur with the proposer's opinion that the old policy was interpreted incorrectly, and that the RIPE NCC's procedures ought to change.

You do not write policy proposals to change the RIPE NCC's interpretation of existing policy.

...

Absent this, the RIPE NCC's operationalisation of the policy will stay as-is.

------------------------

On Thu, 11 Jan 2024 at 14:35, Sebastian Graf <ripe-lists@sebastian-graf.at> wrote:

...

Dear Tore/Denis:

If we are looking at the Policy Language, then i'm not certain we are reading the same things into it. Or maybe i missed something. Feel free to point out the corresponding section of the policy to me. I'm more than happy to update my views if strong evidence is presented. As a small LIR ... I may not see all edge cases.... but...... So feel free to point out anything important that i may have missed.

Lets look at the actual language in the policy:

...

"All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations."

The way i read it, this point is filled both with the current state of things, and also if we have an aggregated status. Space would still be registered. So the question is what kind of data needs to accompany it.

Actually this point is not satisfied by aggregation. When you have all assignments separately registered, as current policy requires and the proposers of this policy update have finally agreed is the case, you can see that each assignment is unique. You cannot assign the same space to two End Users as you cannot create two assignment objects with the same or overlapping prefix. With an aggregation object, all you know is that some part(s) of this aggregated block may be assigned to one or more End Users. You do not know how much is in use, or even if any of the aggregated space is currently in use. It does not satisfy the uniqueness condition as you can't be sure some of the space has not been multiply assigned.

...

So lets look at what needs to be documented:

...

"Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)."

I think you are arguing what both of you are considering "contact information". It does NOT say we state to put personally identifyable information into it.

You are totally correct here. I have never argued for putting PII into the database.

...

If we read the text literally, then only putting enough information to establish a contact (ie: contact information) would theoretically be sufficient. So theoretically, a "proxy" type of setup for email/postal mail/... could be permissiable as long as any communication/... is forwarded to the the actual responisble party.

In fact i would argue for most businesses (End-User or ISP) this is already the case if they make use of "role" contacts for their admin/noc/abuse/... handling.

Also correct.

...

...

"Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)."

The other thing that i do not read from the statement is where it asks to put "contact information" for the End-User. It simply reads contact information (one could theoretically interpret this as "contact information for the party that is responsible for managing the space....).

You are missing the infamous lines this proposal wants to delete from the current policy: "When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End User's."

...

ANYWAY....

I still do not feel anything of significance would be lost, if something could be lost at all.

I guess you don't accept that the registration details of End Users is significant.

...

My personal opinion goes the other way.....I suspect, if anything aggregated status could potentially lead to more accurate data. Let me explain: With the aggregation we gain better understanding of the network usage. PLUS the ability to create more specific assignments (under the aggregated). So This way, i feel more usable data would be int the database, compared to now.

With an aggregated block all/some/none of the space covered by this block may be in use by one/many/no End Users. You have no idea about network usage. All that detail may be lost.

...

This would also be in line with the goals in Section 3.0 - Point 2 "Agregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information.".

Aggregating address space registration details has nothing at all to do with routing aggregation.

...

If we look at the goal for registration: "Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.".

Aggregating assignment data does not guarantee uniqueness, or provide information for Internet troubleshooting at ALL levels.

...

If we consider the usefulnes of data entered into the ripe-db for this purpose, then most useful will be the ISP contact information. Contact information for End-Users (could be an ISP as well) would also be useful in some cases. Personal Information for "individual" type end users (ie: Fred Testuser's DSL Line that comes with a Public IPv4 Address)....to a lesser extend.

If we look at Section 3.1 ...it reads "Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and must not be distributed wider than necessary within the IR.".

So i am not certain why you are trying to force more data than actually required/useful into the db. And yes in this context i would consider LIR's in this to be part of this as some type of "local" IR's.

There is always a balance between privacy and the needs of civil society. It was decided many years ago that anyone operating a network using public address space should have contact details available in a public registry. That is still what the current policy says with wording written by Leo (AP WG co-chair, former RS manager) and Mirjam (RIPE chair). The original source of this requirement goes back to address policy written in the 1990s by many varied authors including Daniel (RIPE NCC founder) and Hans Petter (RIPE NCC CEO and former AP WG and LIR WG chair). Unfortunately no one is willing to provide any background information to the current RIPE community about why these rules were originally imposed. That makes it difficult to discuss if those original conditions still apply to the current stakeholders of the RIPE Database, who we also can't easily identify.

...

During the writing of this email, i realised that you (denis/tore) may consider the need/usecase for adding a "restricted" flag into the DB, that would allow adding information, that is only shown to a select audience (ie: law enforcment, ripe staff and Ripe-Members) - wich could be used to publish PII data. HOWEVER doing something like that would "extend" the existing usecase(s) of the DB and dataentry required - as such this should be in a different Policy Proposal/wg-discussion. Feel free to put one forward, that we can discuss....

I did consider this option when I put forward my RIPE Database Privacy policy proposal some time ago. The idea of multi level access was not very popular.

------------------------

On Fri, 12 Jan 2024 at 08:12, Tore Anderson <tore@fud.no> wrote:

...

Good morning Jan,

On 12/01/24 07:25, Jan Ingvoldstad wrote:

...

I also do not understand what makes it so hard to say that: "Yes, the current policy does state something else than NCC's interpretation of it does, (…)

We do not make statements that we do not believe to be true.

In our opinion, the RIPE NCC implements current policy correctly.

How can you keep saying this when everyone knows it is not true. Regardless of whether or not you support the way the RIPE NCC currently implements the policy, it is NOT what the policy says. We have been over this so many times. The policy is so clear in simple, plain English. For whatever reason, the way the RIPE NCC implements the policy today is NOT what the current policy so clearly says, as written by a co-chair of this WG.

You even admitted it yourself in an earlier email (listed above) where you said (and these are YOUR words):

...

After all, any LIR which prefers the RIPE NCC interpretation of the policy in this regard is may simply adhere to it and act accordingly, and this is commonly done today. Thus the RIPE NCC's interpretation of the policy – mistaken or not – ends up becoming the (de facto) way the policy is implemented anyway.

------------------------

On Fri, 12 Jan 2024 at 08:57, Sebastian Graf <ripe-lists@sebastian-graf.at> wrote:

...

Dear Jan!

As mentioned in my previous e-mail: Would you please post the section of the policy that you belive has the NCC's interpretation differ from the actual wording/language used?

Because i have yet to find a section that states explicitly what is considered valid vs invalid contact information (other than being out of date or information that does not provide a contact to the user in a timely manner). Or a section that restricts what kind of data is permissable for "contact information".

It is not a question of what is (in)valid contact information. It is about who the contact details refer to. End User or LIR.

------------------------

On Fri, 12 Jan 2024 at 09:28, Sebastian Graf <ripe-lists@sebastian-graf.at> wrote:

...

Dear Jan!

Thank you for your reply. But you have not answerred my question.

We are all clear/well aware on the fact that the policy states (paraphrasing here: resources need to be registered and the registions need to have contact information).

We are looking for the DEFINITION of "contact details of the End User.". This is not directly defined (as far as i can tell) and is therefore open for interpretation.

Unless i missed something?

Yes you have missed something. Take your sentence above "contact details of the End User". This can be split into two parts: "contact details" "of the End User." You are right, there is no definition of "contact details". So it doesn't matter if this is email, phone, fax, postal address or if it is in a role or person object or if it is corporate or personal data. Much of this does matter when it comes to privacy concerns, but that is another discussion. What we are primarily discussing here is the other part "of the End User." So the contact details don't matter for this discussion as long as they collectively refer to the End User. And this reference is not open to any interpretation according to the current policy.

------------------------

On Fri, 12 Jan 2024 at 10:35, Sebastian Graf <ripe-lists@sebastian-graf.at> wrote:

...

Dear Jan!

You and Denis are arguing that registration/user data needs to include certain (sometimes sensitive details (ie: PII)) that need to be put in the database. Your Argument is that this is a policy requirement.

That is NOT what we are arguing. There is no policy requirement regarding the nature of the contact details. The policy states who the contact details should refer to, ie End User or LIR, for example.

...

When I tried to get both of you to spell out what this "user data"/"contact information" is exactly and where that is defined - We do not get a clear answer.

Because it is not what we are arguing and it is not defined anywhere.

...

I have read every single of denis replies/comments.

When asked, neither of you cannot reference a policy section that actually spells out what is considered "contact details".

Because the policy doesn't define this and it is not relevant to this discussion.

...

According to your own e-mail - your opinion is based on a software interface/implementation (ripe-db). This interface itself is an interpretation of what the policy could mean. The Interface of the DB also does not specify what kind of Information (regular address, proxy address,...) needs to be inserted. Just that some fields need to be filled out (and its open to interpret what goes into them to a certain extent - wich is the point of this discussion).

Sorry but you have missed the point again. The discussion has nothing to do with RIPE Database interfaces, forms or attribute contents. It is about WHO these details refer to.

...

The relationship is policy -to- database. Not Database -to- Policy.

And yet, we have no document or reference that defines what kind of contact information (direct only, or indirect via proxy/masking/....) is permissable.

Correct, and it is not relevant.

...

Just that it needs to be maintained (meaning "if it works" -> OK).

All data in the RIPE Database should be maintained and kept up to date.

...

In my previous e-mail i did argue that in some scenarios working witout"proxy" data is impossible (think: Role/NOC Contacts).

ROLE or PERSON object is also irrelevant to this discussion.

...

I have also read your reference https://www.ripe.net/publications/docs/ripe-705 . It defines an abuse inbox is mandatory for certain objects. And that it has to be an email address. - Nothing else.

Also irrelevant to this discussion.

------------------------

So where does all this leave us? During this discussion we have established that:

-We do not understand what many elements of data in the RIPE Database mean.

-There are some historical definitions in old documents. These definitions have never been updated, so technically they are the only current definition available. But some of these definitions do not map exactly into the modern world.

-Some registration requirements were written in the early 1990s. Some were re-written in 2003. Much of this was written by people who still have a high profile in the RIPE community or RIPE NCC today.

-We do not know what the reasoning was for why these requirements were introduced.

-We do not know who the major stakeholders are who use the data in the RIPE Database or what information they want and need or what they use it for.

-We have no business requirements for the RIPE Database as a public registry.

-We do not know what data needs to be registered in the RIPE Database or what information it needs to serve to who for what purpose.

-An unknown amount of assignment data in the RIPE Database does not comply with current address policy.

-The RIPE NCC does not enforce the current address policy. This may be because the RIPE NCC does not believe they have the power to enforce current policy.

-Some members have made it clear they will not enter any of their customer's details into a public registry no matter what policy says for commercial sensitivity reasons. While there are interpretations of current policy they may be considered in violation of policy. So there are other reasons why some people may want to push through this change in End User registration.

-We do not know what the potential consequences may be for some stakeholders by making this change.

So given all these unknowns, should we go ahead and make this change? It seems like this has been a long and intense discussion. Some people may think we have had sufficient input from the community to be able to make a decision on consensus. But as is often the case, statistics beat perception. So let's look at some numbers. Excluding the chairs, proposers and RIPE NCC staff there have been 22 people who commented on this discussion over the last 6 months. Of these 6 people only made 1 comment and another 6 made 2 comments. Then 8 people made 3 to 6 comments. One person made 12 and one made 24 comments. Also 5 people made up the '+1' brigade. These numbers cover both supporters and objectors. This is quite typical of policy discussion. Many of the 'regular' vocal community members who are involved in almost all policy discussions are included in these numbers. So we are looking at a very small number of people who actually support this proposal. Given all the unknowns we have identified during this discussion and the very small number of supporters, should we still approve this proposal? Bear in mind also that the proposal is basically about adding an inconsequential, minor, optional feature change for the convenience of some operators. It also makes a huge change to the registration requirements of End User assignments which will have an unknown impact on the public registry and some major stakeholders.

Now let's add in some other factors. I really do recommend that you all watch John Curran's keynote speech to NANOG about internet governance. https://www.youtube.com/watch?v=U1Ip39Qv-Zk

He makes some very interesting points that are highly relevant to this discussion. He talks about 3 phases of the internet. The first one was the early development, done largely by universities and other early adopters of the technology, but largely paid for by governments. Then we went into the commercial phase that covers much of the last 20 years or so. But now we are moving into a public phase where civil society is more knowledgeable and is much more heavily involved. During the commercial phase the tech community could pretty much do what they wanted. If questioned by any parts of civil society or regulators they could just fob them off with No No No No... In the new public phase politicians, regulators, organisations involved in public order are much more aware of the interest by civil society (people who vote in elections). The public is aware of the dangers of the internet as well as the benefits. Politicians and regulators must be seen to be in control. So the days of the tech community saying No No No No to them are over. Now it must be at least No No No Maybe. The Maybe allows the tech community to write something down that they can live with, that politicians can refer to in regulations and everyone is happy.

So how does this relate to 2023-04? We have a public registry that we built and maintain. But there are so many things we don't understand now in the 2020s. We all know what the registry was. My research has reminded you of some of the early details. But what is it now and what should it be tomorrow? We don't have answers to these questions. In the face of all these unknowns we want to add an inconsequential feature that could have a massive impact in other areas that we don't fully understand. We know LEAs have serious concerns. But we have just brushed them aside. This very small group of operators that took part in this discussion have prioritised their own convenience over anything else. They have turned that Maybe back into a No. If you approve this proposal with all these unknowns I think you will find that train full of regulators that is rumbling down the line, heading straight for you, will pick up speed. Think of the LEAs sitting in a room behind two doors. One of those doors opens up to the tech community. You are about to slam that door in their face. The other door opens up to the politicians. We still have the option to invite them into our room and talk seriously with them about their needs. Once you slam that door shut, they will walk through the other door and you lose control.

Yes I know I am a drama queen. But I am trying to illustrate to you that actions have consequences. Today's consequences may be very different to those of yesterday in a similar situation. Nothing stays the same forever. So is it worth risking the wrath of the politicians for what has been described as a minor, optional feature change that some will find convenient?

Let me end by suggesting an alternative path. I have said all this before and been ignored or insulted. But I will say it again anyway. I am used to being insulted on these lists with no one protecting me.

1/ Withdraw this proposal 2023-04

2/ Set up a new Task Force with these primary goals:

a/ Determine the business requirements for the RIPE Database as a public registry, looking forwards.

b/ Identify the major stakeholders for the RIPE Database public registry.

c/ Identify the needs/wants of these stakeholders.

d/ Based on the above, determine the registration needs of the public registry, taking account of privacy concerns.

3/ Once we know what we want, design a new data model for the RIPE Database.

4/ Slowly move from where we are now to where we want to be.

Yes I know this is a long term project and yes it will cost money. But the RIPE Database is so old, with so many things lost in the mists of time, so many things not applicable to the modern world. If you continue turning your back on all this, you may find the regulators will tell you what they want in the registry. That may be far more costly.

I don't think there is anything more I can say on this issue now.

cheers denis

======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================

Hi Tore and others New year, but same old story. So much miss information, endlessly repeated. Selective quotes from other documents to support your argument where a full quote might show a different picture. Carefully chosen examples to again support your argument, where other examples will negate it. But I won't give up. I put forward a proposal on privacy 1 1/2 years ago, 2022-01. In the end I withdrew it for two main reasons. It became apparent that my proposal would significantly change the basis under which personal data is entered into the RIPE Database. Secondly it was suggested that my proposal covered multiple areas that should have been proposed separately. Your proposal has the same two issues. Firstly it will also make changes to the way personal (contact) data is used in the database. Secondly it is claimed to be about aggregating End User assignments but as a side issue 'slips in' the biggest change to address policy in 20 years. In your own words you have repeatedly said this policy is all about aggregation. So keep it strictly about aggregating assignment objects that have the same contact details. Again, in your own words you have repeatedly said this will not make any practical change to the current practise of defining contact details. So take that out. That is where the contentious arguments exist. If you really believe what you are saying over and over again, that there will be no material change in this area, then drop it. Make this proposal about what the title suggests, aggregation. Drop every other change. It will probably then get support without objections. The other changes, that you repeatedly claim are not material changes, can be the subject of a separate proposal. I and some others in this community do not believe these other changes are incidental. In fact I believe that is the real goal of this proposal. I suspect it is the aggregation that is incidental. A means to achieve the goal of dropping the mandatory requirement to document assignments with End User contact details. That is without doubt the bigger change being pushed by this proposal. As it is, this proposal should not, and must not, be approved with such a big change slipped in and complete denial that it is even a change. Separate the two then we can have a full and open discussion on the other change, if you want to put that forward as a proposal. Working on the assumption that you have no intention of doing that, I will continue to argue against your mis-information below, again. You have referenced GDPR so many times in this discussion. Let's look at that in more detail. Article 6 Lawfulness of processing 1. Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; ... (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Note in the opening sentence it says "at least one of the following applies". So personal data does not always need consent of the data subject. But you only ever refer to (a) consent. If you look back at the discussion on 2022-01 my privacy proposal you will see this was heavily discussed: https://www.ripe.net/ripe/mail/archives/db-wg/2022-October/007630.html I also discussed it a lot privately with the RIPE NCC legal team. Frank Breedijk from divd.nl was very concerned about the loss of contact data as my proposal was suggesting we move to a full consent model. (I have CCed Frank as he may not be aware of this proposal that may lead to the removal of a lot of contact information from the database.) This was one of the final points that led me to drop my proposal. It was concluded that much of the personal data is entered into the RIPE Database on the basis of 6.1 (e) - public interest. Especially as so much of this data is used by LEAs and other investigators looking into cyber crime, security incidents and abuse. Then if we look at the legal impact analysis (IA) for 2022-01 https://www.ripe.net/participate/policies/proposals/2022-01?version=3#impact... "Currently, the processing of personal data relating to resource holders is necessary for the performance of registry function. This function is carried out in the legitimate interest of the RIPE community and supports the smooth operation of the Internet globally (and is therefore in accordance with Article 6.1.f of the GDPR)." Then if we look at the legal impact analysis for 2023-04 https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis "In particular, before anyone updates the RIPE Database with personal data, they must obtain the contact person’s informed and expressed consent and ensure this data is kept accurate and up-to-date." So the RIPE NCC legal team, at different times, has said that we process PII for resource holders on the basis of 6.1 (f), End Users on the basis of 6.1 (e), but now they say ALL PII is on the basis of 6.1 (a), ie consent. This is total confusion!!! The RIPE NCC legal team now needs to explain what the basis is for entering PII into the RIPE Database for at least the following situations: -Resource Holders -End Users -admin and tech contacts -abuse contacts If we take the latest revelation in the IA on 2023-04, ALL PII needs consent, this has HUGE implications for the RIPE NCC and RIPE policy generally. We MUST have a good understanding of the legal basis for entering PII into the RIPE Database. Consent cannot be conditional. So if a resource holder who is a natural person withdraws their consent to have their PII in the database, it MUST be removed. That may leave an allocation and organisation with no identity or contacts. That would be a policy violation. BUT the resource cannot be reclaimed as that would have made the consent conditional. Also we have an abuse policy that requires all resources to have an abuse contact. If that contact is a natural person and they withdraw their consent their details must be deleted. Again that creates a policy violation. But the resource cannot be reclaimed again as that would have made the contact details consent conditional. There is also the question of 2 million person objects in the database. It says in the IA for 2022-01 "Although the resource holders themselves are responsible for the registration details they add to the RIPE Database, the RIPE NCC is responsible for operating it. Under GDPR, that creates shared responsibilities on the RIPE NCC’s side with regards to the personal data added and processed in the RIPE Database." So the RIPE NCC is jointly responsible for the consent given (and maybe withdrawn) by these 2m people. This is a separate can of worms but related to this proposal 2023-04. The legal team has to sort this out. On Tue, 9 Jan 2024 at 15:12, Tore Anderson <tore@fud.no> wrote:

Hi again Jan,

On 09/01/24 13:38, Jan Ingvoldstad wrote:

...

It is important to also consider the cases where the End Users are organisations that do not have non-PII role addresses.

Consider for example a small one-person business, let's say a farm owned by «Farmer Fred». This End User would be a company, not an individual, yet the company is often given the same name as the person owning it (at least here in Norway).

The e-mail address might well be farmer.fred@gmail and the phone number might be the Farmer Fred's personal mobile. This would mean that both the name and the contact information for this End User *is* PII and is in scope of the GDPR.

The current interpretation of this part of the GDPR is that "Farmer Fred" is permissible to publish.

Whose interpretation? According to the EU Commission: «Personal data is any information that relates to an identified or identifiable living individual. Different pieces of information, which collected together can lead to the identification of a particular person, also constitute personal data.»

https://commission.europa.eu/law/law-topic/data-protection/reform/what-perso...

«Farmer Fred» – the name of an individual – clearly falls within this definition. So does his e-mail address and telephone number. Publishing this information requires a lawful basis, e.g., consent. If consent was refused, it is not permissible to publish. This is presumably the reason why the RIPE NCC states the following in the 2023-04 Impact Analysis:

Again you have selected just one example that can support your argument, Farmer Fred. I could have used KPN or Apple Inc as an example which would negate your argument. We have no statistics on how many contacts in the database have corporate data or personal data and there is no way to determine this from the data. Even Farmer Fred may be a clever guy. He may have set up a separate business email and phone number for business purposes. You don't know that. Also as I said above, consent is not the only option for a lawful basis to enter personal data.

«Inserting any personal data in the RIPE Database must be in compliance with the RIPE Database Terms and Conditions, even when it relates to the contact details of the member’s own contact person(s). In particular, before anyone updates the RIPE Database with personal data, they must obtain the contact person’s informed and expressed consent and ensure this data is kept accurate and up-to-date.»

https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis

...

Therefore, if Farmer Fred exercises his rights under the GDPR to object against / not give consent to the publishing of his PII in the RIPE DB, you (the LIR) have a problem. Proceeding to publish this contact information over Farmer Fred's objections opens you up to legal risk (not to mention souring the relationship with your customer).

This depends on the legal team's answer to what basis the PII is entered into the database.

The solution here would be to not publish (and not require the publication of) personal phone numbers (or personal addresses), and to clearly make this a requirement in the policy regarding what End User information is published.

Indeed, and it is our opinion that this solution is already available today, as the RIPE NCC has confirmed that according to their current policy interpretation and procedures, not publishing Farmer Fred's PII in the RIPE DB is compliant with today's policy. This will continue to be the case after 2023-04 is implemented, so no change there.

And I have provided a mountain of evidence that this interpretation by the RIPE NCC is so clearly wrong. So your proposal makes a significant change in this area, no matter how many times you claim it doesn't.

Similarly, that requirement must be there for *any* contact object, not just End Users.

You cannot know if the LIR's phone numbers are personal or not, or can you?

LIRs' contact information is definitively out of scope of 2023-04. 2023-04 only concerns itself with *assignments* (made by LIRs to End Users), not *allocations* (made by the RIPE NCC to LIRs).

(That said, LIRs' contact information is also subject to the RIPE Database Terms and Conditions.)

and subject to the legal team's answer to the basis on which it is entered into the database.

...

Precisely. The LIR, like a domain name registrar, can simply serve as a proxy between the wider Internet community and its End Users.

In other words hide the End User data so it doesn't comply with current policy and requires a court order to obtain by the wider internet community.

No, that is not what I wrote.

This is about an automatic email forwarding scheme, not about a registration by proxy scheme.

E.g. you register the domainname ripe-example.shop with a registrar within the EEA, your email address is published (for EEA-based domainnames, anyway) as e.g. qaobuaidbvsas@privacy.example, which is a valid email address that is automatically forwarded to e.g. tore+ripe-example@fud.no.

The policy is technology agnostic in this respect. An automatic e-mail forwarding scheme such as the one you describe is one example of a policy- (and presumably GDPR-) compliant way to do it, but that's not the only possible option. The LIR could instead opt for operating a human-staffed help desk that receives and forwards messages to End Users as appropriate.

...

This voids any policy requirement to (possibly illegally) publish Farmer Fred's PII in the RIPE DB. As stated in the Impact Analysis, the RIPE NCC is of the opinion that this (already widespread) practice is permitted by current policy, and will continue to be permitted after 2023-04 is implemented. In other words, just like in the registrar business, this is an already solved problem, which will continue to be solved after 2023-04 is implemented. It is in this respect that we say that 2023-04 will not bring about any change – it ain't broken, and we're not fixing it.

The claim that has been made is that *current* policy does not allow LIRs to serve as proxies in this manner, and that the RIPE NCC has not been implementing current policy correctly by allowing it. It is further claimed that 2023-04 will bring about an (undesired) change in that it will allow LIRs to serve as proxies. However, for the reasons already discussed we are of the opinion the premise this argument rests on is incorrect, hence we do not believe 2023-04 will effect any change.

We hope this clarifies the clarification. :-)

I was kindof trying to avoid that argument again.

But sure, as you bring it up again.

This opinion is obviously a logical impossibility.

There is no way that you can change something and at the same way legitimately claim that the change is not a change.

If it is true that the current practice is both widespread and accepted, then *no change is necessary*.

If a change is necessary, it is logically because there is a widespread and accepted practice of publishing End Users' contact information.

The argument is therefore nonsensical, sorry.

I think that because the WG discussion has almost exclusively revolved around this alleged changing of policy requirements to publish End User contact information (which may or may not be PII), it is easy to lose track of what this proposal is *actually* all about. We are talking about two different things:

There is nothing alleged here. Jan is correct. You ARE removing that infamous statement "When an End User has a network using public address space this must be registered separately with the contact details of the End User." You cannot describe this as anything other than the fact that you ARE changing the policy requirements to publish End User contact information.

1) The actual intention behind the proposal: Making it possible to aggregate multiple IPv4 End User assignments that have consistent contact information and purpose into a single database object. This is not possible today, and that is what we want to make that possible, in the same way it is already possible in IPv6.

If this is the actual intention then keep the proposal to this. DO NOT make other changes to the policy on the side.

2) The *alleged* change to what kind of End User contact information is required to be published in the RIPE database. We have never had any intention of changing this in any way, and the Impact Analysis and other statements from the RIPE NCC confirm that the proposal does not change it either.

Then don't change it. SIMPLE!!! The IA does NOT say it doesn't change this.

In short: 1) is an intentional and desired change from today, while 2) is *not* a change from today – intentionally so.

So maybe we could discuss 1) instead of 2) going forward? :-)

You have not actually addressed this concern and objection, you have merely restated claims and opinions that do not actually do so.

I therefore again urge you to resubmit the proposal *without* this removal.

As noted in 2) above, the proposal in its current form does not cause any «removal» of any End User contact information publishing requirement compared to current policy.

You are removing this 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." This is a 'publishing requirement'. You ARE removing it. To keep saying you are NOT changing anything is not a joke anymore.

It merely upholds the status quo, which has been confirmed by the RIPE NCC on multiple occasions. However, if you are dismissing the RIPE NCC's clarifications on this subject in the Impact Analysis and elsewhere as not factual, then there is not much more to discuss and we would simply have to agree to disagree.

It has been said once by the RIPE NCC and disputed. It is YOU who is repeating it on multiple occasions.

Then, if this part of the policy change is of importance, resubmit it as a separate proposal, and preferably clearing up the PII mess a bit more. I have no beef with clearing that up.

Any effort to «clearing up the PII mess» has always been outside the scope of this proposal. This proposal is simply not about PII or contact information. That could be a subject for another policy proposal, of course, but one thing at a time.

cheers denis

Tore & Jeroen

--

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

On Thu, Jan 11, 2024 at 9:40 AM Tore Anderson <tore@fud.no> wrote:

Your conclusion that this situation results in a policy violation, is however entirely contingent on your interpretation of the current policy as mandating the publication of the End User's (non-delegated) contact information.

Please stop misrepresenting this argument. -- Jan

I still oppose this policy and mostly agree with denis. I don't think it makes sense to push through this policy currently given the concerns raised and the quite limited potential benefits. -Cynthia On Fri, 15 Dec 2023, 15:05 denis walker, <ripedenis@gmail.com> wrote:

Hi Jeroen

Looking back over this email, there are two things that really stand out to me.

"Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way?"

"the statement «When an End User has a network using public address space this must be registered separately with the contact details of the End User» found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy)"

These two statements that you made basically sum up this policy proposal. You are suggesting we fundamentally change IPv4 address policy for the 'convenience' of operators and to 'align' some words between two different policies regardless of the consequences.

When you add to this a comment Gert made at RIPE 87 when he said that after 30 years we have no clue as to what the "admic-c:" attribute means or why anyone would want to contact them or what they would expect to get from such contact. We have maybe 5 or 6 million inetnum objects in the RIPE Database, a few million inet6num objects and probably tens of thousands of aut-num objects. They all have a mandatory admin-c and we don't know why it is there. All we have is a 30 year old definition that says it must be an on-site contact for the End User in the case of assignment and ASNs.

This is a dreadful situation to be in. I suggest that 2023-04 is withdrawn. Then we have a wide reaching consultation with many stakeholder groups who use the RIPE Database. Determine what their needs are for a public registry. What information they need and would like to have in the RIPE Database. Basically do what I expected the last database task force to do, produce a business requirements document for the RIPE Database as a public registry. Then see where we go from there.

cheers denis

On Wed, 13 Dec 2023 at 19:14, Jeroen Lauwers <jlauwers@a2b-internet.com> wrote:

...

Dear colleagues,

Though we recognise that most of you are probably busy preparing for the

upcoming holidays, we would like to ask you to share your opinion on proposal 2023-04. Remember that Policy Development Process requires any comments made during the Discussion phase must be repeated during the Review phase in order to count towards or against rough consensus, as your views can now take the RIPE NCC’s Impact Analysis into account.

...

Here are some questions for the WG to get the discussion started: Do you

already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way? Does 2023-04 address this use case well in its current form, or could you think of any potential improvements?

...

We hope you will find the time to let your voice be heard!

The Policy Development Process requires the proposers to adequately

address any suggestions for changes or objections to the proposal in each phase, which we will do below.

...

1. Does 2023-04 change the contact registration requirements for

assignments?

...

The argument made is that the statement «When an End User has a network

using public address space this must be registered separately with the contact details of the End User» found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy), implicitly requires LIRs to register non-delegated/outsourced contact information for the End User in the RIPE database, not necessarily in the mandatory «admin-c» or «tech-c» attributes, but possibly in an optional attribute like «descr», «org» or «remarks».

...

Proposers’ response:

We do not believe so, for the following reasons, and keeping the current

practice and policies in consideration:

...

The RIPE NCC does not consider that 2023-04 changes the contact

...

The practice of creating assignments with all contact information delegated is already widespread. If this was a policy violation made

...

Outsourcing and delegation of contact information is a common practice across many industries, including in networking and information technology. There is no policy language that explicitly prohibits this for IPv4 assignments. Absent that, we believe any implicit prohibition found “between the lines” is essentially «void for vagueness»[4]. An obligation to publish the End User’s contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User’s contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence). The policy’s stated goal of registering assignments is «to ensure uniqueness and to provide information for Internet troubleshooting at all levels»[7]. Requiring LIRs to publish the contact information of End Users who often will not have any knowledge or capability to aid with

registration requirements in any way[1][2][3]. Absent any (rough) consensus in the Working Group to the contrary, we defer to the RIPE NCC’s judgement on this point. possible due to the RIPE NCC implementing RIPE policy incorrectly, we would have expected the community to take action to correct this situation. However, no such policy proposal has been put forward by the community. troubleshooting does work towards this attaining goal. On the contrary, delegating the contact information to the LIR/ISP may well be the only way to attain this goal.

...

[1]

...

[2] https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/0138... [4] https://www.law.cornell.edu/wex/void_for_vagueness [5] https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms [6] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1... [7] https://www.ripe.net/publications/docs/ripe-804#3

2. The «assignment-size» attribute should be a CIDR prefix length

Leaving it undefined could result in some LIRs using it to represent an IPv4 address count, while others would use it to represent a CIDR prefix length.

Proposers’ response:

We agree «assignment-size» should be a CIDR prefix length. We understand

https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013... that, if proposal 2023-04 would be accepted, the RIPE NCC could implement the «assignment-size» attribute for IPv4 inetnum objects to be a CIDR prefix length, and document it as such. Therefore we do not believe it is necessary to spell this out explicitly in the policy document (it is not spelled out in the IPv6 policy document either).

...

Thank you for your attention and enjoy your holidays!

Best regards, Jeroen and Tore

Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara <adallara@ripe.net> het

volgende geschreven:

...

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

...

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

https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis 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

--

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

Hi folks, Anno domini 2023 Peter Hessler scripsit:

I still support the proposal as-is. The proposed change does not weaken any data that is in the database, and in fact may allow it to be more obvious that these address ranges are used by end users rather than be unclear what their status is.

Furthermore, I will state that Denis' objections are not relevant to the proposal. The proposers, various people on the lists (including myself), and the RIPE NCC themselves all state the opposite of what Denis is saying. In addition the proposers have, in my opinion, addressed the concerns stated.

+1 to what Peter said. Cheers, Max

Dear address-policy WG, Hope this email finds you in good health! Please see my comments below, inline... Thanks. Le vendredi 15 décembre 2023, Peter Hessler <phessler@theapt.org> a écrit :

I still support the proposal as-is. The proposed change does not weaken any data that is in the database, and in fact may allow it to be more obvious that these address ranges are used by end users rather than be unclear what their status is.

Hi Peter, Thanks for your email, brother.

Furthermore, I will state that Denis' objections are not relevant to the proposal.

...this statement might have not sufficiently considered the fundamental issues raised by him.

The proposers, various people on the lists (including myself), and the RIPE NCC themselves all state the opposite of what Denis is saying.

...i have to step in; because i think it should not be about the number of occurrence of an argument. ...imho! consensus should not be attained when fundamental issues such as a misinterpretation of a policy, or its misimplementation, might have occured silently. What's the process in the event of such a claim ? ...imho, i'm not sure that we should just move on without first correcting the mistinterpretation issue identified :-/ Without restoring the truth, it would be really tough to correctly evaluate the risks regarding proposed changes around the actual policy.

In addition the proposers have, in my opinion, addressed the concerns stated.

...as the core problem is above them; they stated that they refer to the Staff who produced the IA (Impact Analysis); avoiding the hot topic :-/ The issue raised by Denis remains unaddressed... ...imho! ...i stand with him; asking for a pause regarding the progress of this policy proposal. Shalom, --sb.

-peter

On 2023 Nov 21 (Tue) at 11:13:57 +0100 (+0100), Angela Dall'Ara wrote: [...]

-- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

Hi James, Thank you for your message.

I always understood them as a way of recording who/what was using a piece of address space so that you can contact the right organisation in the case of an issue. In this case, there were explicit carve-outs for blocks of dynamic address space so that the ISP could be contacted to determine who was using that particular piece of address space at a single time.

Where address space was allocated on a more permanent basis the contact details of the end site would be added so the organisation who was trying to address the problem had a direct route to contact that end network.

I think in cases of the AGGREGATED-BY-LIR it will be used for LIRs that are also something like an ISP. LIRs that delegate their prefix to another entity would use sub-allocated pa for doing this. Personally, I prefer as an LIR/ISP to use our contact information in the assignments that we also delegate to customers this is because I value knowing what is going on by our customers in matters of technical problems and abuse cases that are using our network and IP space. I am convinced that in this way, we can advise and help our customers better and also solve the problem sooner.

From a technical point of view, it was useful as a reference to be able to work out if several IP addresses in a subnet had been allocated to the same customer or if there was a wider issue. This means that having the assignment size fixed for each block and included in the RipeDB entry is rather important.

Is it possible to give a detailed example of this?

This policy appears to take the standard approach for IPv6 and apply it to IPv4 (this is a good thing) it will reduce the number of individual entries in the system (neutral) and hopefully increase the accuracy (a good thing) but at the loss of explicitly including the contact details of the end user site and replacing it with a contact for the LIR (neutral). The last step appears to be the most controversial as it stops people from going directly to the source as it were.

I think the operational impact here is a potential issue, some LIRs are less than stellar in dealing with requests about things listed in the RipeDB (mostly because of spam) so I can see the concern that some have raised about not being able to get hold of people. However that's not a Ripe issue explicitly but rather a function of the world of capitalism (it's free to send an email, let's send lots of emails, we only need a few people to respond to make money...)

If we want to fix this problem then maybe we need to add a new capability onto the db that allows authenticated users to contact LIRs about their address space (without using the published contact details) in a way that would allow anti-abuse and LEAs to access the information they need, that is very much not something that needs discussion in the WG because were here to talk about address policy.

It would be good if some research would be done on your point of why LIRs become less stellar in dealing with the requests. Is it indeed because of the spam or just because the abuse department is an easy thing to save money on? In both or other cases it is good to see what we can do to improve the situation. I think that AGGREGATED-BY-LIR won’t affect this because a customer next to being portably less technically capable, can just as good save money on their abuse department or be annoyed by the spam as the LIR.

This policy is optional...

I think people have missed this, from my reading an LIR is not prevented from continuing to put entries without marking them as aggregated so from that point of view if you want to continue to include customer details (and you have their consent) you can still do it.

Yes, indeed it is optional. Regards, Jeroen and Tore.