@EXT: RE: URGENT 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Kessler, Emmanuel
Dear partners and chairs of the Address policy working group of RIPE,
Please find more clarifications from EUROPOL and Law enforcement agencies, about how the 2023-04 measure would impact the capacity of investigators in identifying cybercriminals.
First, I would inform you that we had to open a large consultation with various European services and EU authorities, cybersecurity authorities, that indeed showed an interest on the measure. It has taken some time to collect inputs, …of course.
While we worked on providing concrete inputs as much as possible, we coped with some limits, as we cannot share some information that are under the secrecy of law or judicial cases, we cannot share information in public/open access that could in the end, inform cybercriminals on how countering our activities,….
and as a last point, omniscient statistics do not exist anywhere… Thank you for considering it.
Having said that , lets jump with the points...
In our assessment, the 2023-04 measure would impact at 2 levels.
The first level of impact is that it would complicate the process to access the information.
Some European services have confirmed they do use on daily basis, the RIPE data basis to get directly the end user information. It is an easy access for them. They also use support-tools whose results would be weakened through the new configuration.
At national level, capacities would be preserved in some extend for some services, but would it would become heavier, as court order would become systematic.
At International level, identification of IPs would become far more complicated on digital investigations (from some general assessment, about 80% of investigations have a digital dimension now !),…and especially on cyber cases....
Most of investigations rely on a swift IP identification, that may involve external LIRs and various ISPs that regularly give an IP to others.. An European service gave me the example of a Child sexual abuse material case : an investigator would have to send a mutual legal agreement request to a LIR, to receive as an answer, 4-6 months later, that the IP is handled by an ISP (sometimes in the same country as the investigator)..we will here lose time, with less capacity in the end to identify victims, accomplices, perpetrators, (because of some data retention limits in many countries)…
on this situation, it would be for the best interest of all parties if for example, a measure would ensure that, "in any case, LIRs and ISPs that transfer/give any IP or IP block to another legal entity, must declare this information to the RIPE database".
It would also become more time consuming in getting the identification, meaning less cases processed by investigators. Judicial proceeding has got more and more complex for many reasons, and the new measure would not help the daily job.
The capacity of investigation services is asymmetric with the large volumes of ransomwares attacks, online scams, child sexual abuses materials sharing,…
In the end, the new measure could foster by design, a “bullet proof hosting” like-situation. Here is a point to be also considered.
RIPE covers not only the European Union, but also other countries outside the EU. The cooperation level with these countries may vary in a large extend and across time. With some of them, getting a swift answer on the sole court order is not an option, and it may be the most uncertain/long with a mutual legal agreement request.
Here again, it would loudly impact us,...as the location of some of these countries are regularly used in a consequent number cyberattacks.
Some will say that criminals have not waited for anybody to use bullet proof hosting capacities,…yes,….but we consider that a measure that may hide their mistakes, clearly does not help us, ....but them….
International cooperation relies on processes, that are still largely humanly tailored by legal authorities (not automatized), linked with sovereignty, respect of fundamental laws and rights, safeguards. …I believe we all respect that,…
but it means consequences on the way the global flow of judicial cooperation may work and some balance is needed in maintaining some efficiency in the processes.
The second level of impact would be linked with the quality of the data hosted in an aggregated environment.
“Aggregating multiple IPv4 End User assignments that have consistent contact information and purpose into a single database object” : which impact on cross-matching the information of IPV4…???
IPV4 identification is far more challenging than IPV6 one....the matter has become well identified...
From our assessment, the measure would impact the granularity of the data, as already said. Through aggregating assignments, it will have as a consequence, the loss of various end users details, preventing cross-matching efforts by investigators, that are essential.
While individual assignments offer specific and detailed information about each IP address's usage, aggregated data may obscure such details, potentially complicating investigations that rely on precise IP address information.
In the end, the less detailed information will, either require additional steps or inquiries to ascertain the specifics of an IP address's usage, potentially delaying investigative processes….either identification may not be possible as it was previously…
To give you an idea of the extend of impact, Lets’ take the example of the CGN-NAT matter. The mutualisation of IPV4 addresses, is here fully considered as a big challenge for investigation.
EUROPOL has worked for long on that, especially on this CGN-NAT matter that raises a similar question as the 2023-4 proposal. various reports are publicly available online (IOCTA, or other publications)
CGN-NAT configuration greatly helps criminals to get anonymous as the ISP cannot locate the subscriber. Numerous cases have been reported by investigators.
Europol met this challenge in important operations, covering for example cases of traffic of arms, or child sexual exploitation (CSAM sharing forum with 62000 members, 10 children victims)
in big cases, we may have to process hundreds of IPV4, sometimes thousands in the biggest ones : because of aggregation, we may lose some cross matching/identification opportunities that are essential to solve a case.
As an example, on some big cases, the CGN use impacted up to 70% of identifications of perpetrators or accomplices. we observe that the 2023-4 proposal could generate a similar “fog” with the same extend of impact.
The CGN-NAT is so hampering that in answer, some EU countries had to limit the number of subscribers per IP.
As another point, the measure observe some inconsistencies in Registration Practices: it acknowledges that some LIRs already apply exceptions to the current policy, leading to inconsistencies in how IPv4 addresses are registered.
This inconsistency can pose challenges for law enforcement in tracking and mapping IP addresses to specific users or activities, as the registration practices may not be uniform across different LIRs. However, standardisation should not mean further weaken the quality of data.
The expected decreased granularity of the data would raise a question in the context of the EU NIS2 DIRECTIVE, that aims to provide an improved quality of the data available for cybersecurity/legal needs.
NIS2 covers identification of DNS, but it would be paradox that while we are progressing on the identification of DNS, we may decrease on identification of IPs,…
It is right that so far, EU regulatory efforts have focused on the DNS identification need rather than the IP one, as DNS matter was clearly identified as a urgent need, after the evolution linked with GDPR.
the 2023-4 proposal would raise indeed a new concern...
To our assessment, ensuring reliable registration requirements for end user contact information (providing the necessary information, without any drafting interpretation) remains here essential to prevent progressive anonymization/losses of data.
The way, each ISP will aggregate its data, is a real and complex question, with huge potential impact on investigations. In deep analysis, we still consider that there is a risk of progressive anonymization of data of end users information, with the 2023-4 proposal...
For these reasons, the 2023-4 proposal remains at EU level, a matter of concerns and question.
As such, it could practically result in being a technical evolution hampering in practice the legal obligation (in many countries) for ISPs to identify end user subscriber information, ....as long as it cannot be proved that the previous identification granularity is maintained.
I hope that these information will help you on better understanding our concern.
we do understand the business need, however the support of private partners is essential for us on protecting people.
Thanks for your cooperation
Regards
Emmanuel Kessler
-----Original Message-----
From: Leo Vegoda <leo(a)vegoda.org>
Sent: 17 January 2024 18:01
To: Kessler, Emmanuel <Emmanuel.Kessler(a)europol.europa.eu>
Cc: address-policy-wg(a)ripe.net; Šileris, Edvardas <Edvardas.Sileris(a)europol.europa.eu>; BAUER-BULST Cathrin <Cathrin.BAUER-BULST(a)ec.europa.eu>; Tore Anderson <tore(a)fud.no>; Azofra Martínez, Álvaro <Alvaro.Azofra-Martinez(a)europol.europa.eu>; Frank Breedijk <f.breedijk(a)divd.nl>; Maria Stafyla <mstafyla(a)ripe.net>
Subject: Re: [address-policy-wg] @EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe.
The external address that sent the message is: leo(a)vegoda.org
Dear Emmanuel Kessler,
It would help the co-chairs tremendously if your arguments gave some specific numbers or other details. We are aware of your concerns but phrases like "large potential impact" are vague.
Kind regards,
Leo Vegoda, for the Address Policy WG co-chairs
On Mon, 15 Jan 2024 at 02:32, Kessler, Emmanuel <Emmanuel.Kessler(a)europol.europa.eu> wrote:
>
> Dear all,
>
> we keep analysing the possible consequences of the measure on our LEA
> capacity to identify IPV4 It takes time as it interests various EU official partners and Law enforcement services, ...thanks for your understanding.
>
> We still identify two issues in the measure
>
> - about the process to access to data : as ending the direct access at RIPE level, it will not ease the work for some investigators who uses it as a convenient tool, although accessing the data at LIR level still remains partly an option.
>
> - about the granularity of the data as aggregated, and we think there is here a very strong question, with a large potential impact.
>
> As you know, EUROPOL has worked for years on the CGN-NAT challenge on IPV4, advocating for limiting this mutualisation of IPV4 addresses that regularly hampers investigation capacities.
> we observe the aggregation measure as having a real negative impact on the granularity of the answers that will be collected.
> it is also linked with internal practices in the companies that remain various...we know that.
> Situation with IPV4 is different than the one with IPV6.
> Consequently, we keep all our reserve about the proposal that raises concerns amongst many colleagues.
>
> We fully understand the code of conduct in RIPE debate, and still appreciate good discussion with constructive and realistic people...
> However, getting all the truth of the situation requires contradictory debate that can progress through the exchange of still more detailed explanations,....
> As the matter is of real importance, we hope that the measure would not be adopted without this clarification with all opinions/arguments around the table,...
>
> We would be also in favour of postponing the deadline of the debate, to take time to exchange and check all the explanations as necessary.
>
> Thank you for your exchange and cooperation
>
> Regards
>
> Emmanuel Kessler
> European Cybercrime centre
> EUROPOL
>
> -----Original Message-----
> From: denis walker <ripedenis(a)gmail.com>
> Sent: 11 January 2024 03:21
> To: Tore Anderson <tore(a)fud.no>; Maria Stafyla <mstafyla(a)ripe.net>
> Cc: Jan Ingvoldstad <frettled(a)gmail.com>; address-policy-wg(a)ripe.net;
> Frank Breedijk <f.breedijk(a)divd.nl>; Kessler, Emmanuel
> <Emmanuel.Kessler(a)europol.europa.eu>
> Subject: Re: [address-policy-wg] 2023-04 Review Phase (Add
> AGGREGATED-BY-LIR status for IPv4 PA assignments)
>
>
>
> This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> The external address that sent the message is: denis1(a)gmail.com
>
>
> Hi Tore and others
>
> On Wed, 10 Jan 2024 at 13:02, Tore Anderson <tore(a)fud.no> wrote:
> >
> > 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.
>
> As I explained in the previous email, you only quoted half the GDPR
> condition here. It actually says,
> (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; As I also pointed out, during the discussion of
> 2022-01 (privacy)
> https://www.ripe.net/ripe/mail/archives/db-wg/2022-October/007630.html
> it was accepted that there is a 'public interest' basis here.
>
> >
> > 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,
>
> It does not matter how many times you repeat this, it is still NOT true. You remove the 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.
> Removing this line DOES change the LIR's obligations relating to the publication of End User contact information. No matter how many times you repeat this false information I will repeat the reply.
>
>
> 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.
>
> This is one of your biggest false statements. The ONLY person repeatedly saying this is YOU. Let's do a fact check here. You asked a question to the RIPE NCC about publishing End User contact details in an assignment object. The RIPE NCC PDO, policy officer Angela, consulted with registration services and made a reply. She confirmed, once, it is compliant with current policy to not publish the End User contact details. I have disputed that by quoting the famous line (which you want to remove):
> 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.'
> I have provided a mountain of supporting evidence that the RIPE NCC's interpretation of this statement is incorrect. Angela's one time answer was incorrect. Since then the RIPE NCC has said exactly NOTHING. No one from registration services has come to this list and expanded, qualified or explained their one time response. But since then you have endlessly repeated that one time response from the RIPE NCC. You have claimed so many times that the RIPE NCC has repeated this many times. That is NOT true. Please STOP saying what is NOT TRUE. It was said once by the RIPE NCC and then disputed. You are still hiding behind this false premise.
>
> >
> > 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.
>
> It has a massive change on the LIR's obligations, by removing a line of text from the current policy, which you have admitted yourself does not need to be removed for your aggregation proposal. You keep repeating that this change has no real, practical impact, so don't remove it. Then we can all get on with our lives.
>
> >
> >
> > > 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.
>
> Then limit the proposal to exactly this!!!
>
> > >
> > > 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.
>
> 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.
>
> > >
> > > 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).
>
> You must think that WE are the crazy people. You cannot remove the 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 then say the meaning is exactly the same. I know it is a common tactic now, especially in politics, to keep repeating mis-information that makes no sense over and over again, refusing to listen to objections, until a mass of people start to believe your mis-information. I am one of those free thinkers who doesn't go with the masses. I will keep pointing out the mis-information here.
>
> >
> > 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. Is the legal team actually saying here that the RIPE NCC cannot enforce RIPE policy? The current policy is clear on the 'type'
> of contact details. That 'line' says an assignment MUST include an End User contact. It is true the policy does not say the LIR must add Person A as the contact rather than Person B. So in this context the RIPE NCC cannot enforce which (Person A or B) contact details members add to their IPv4 PA assignments. The choice of Person A or Person B will remain the LIR's decision. But when the policy says an assignment MUST include 'an' End User contact, the RIPE NCC can and should enforce that 'a' contact for the End User is added. So I ask the legal team, which interpretation did you mean?
>
> >
> >
> > > 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.
>
> It is based on reading the current policy and understanding what a very clear sentence written in plain English means.
>
> >
> > 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.
>
> You are doing it again. The RIPE NCC has said something ONCE and refused to clarify it ever since, despite it being contested. It is YOU who repeatedly claims something.
>
> >
> > 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.
>
> 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
> --
>
> 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
1 year, 1 month
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Brian Storey
Hi Tore,
I'm conscious you've gone to a great deal of effort to respond back to me promptly and I've not come back to you sooner. Sorry to keep you waiting for at least an acknowledgement.
Firstly, thank you for taking us through this example. I can see yourself and Dennis have developed this converdation further.
Rather than tread on that, I'll perhaps offer a slightly different spin on this which is neither in support or against your proposal, but in respect to how a LIR is supposed to determine what they should or shouldn't do. I'll be honest and say that I'm a relative newcomer to this having taken on the adminsitrative responisbility and compliance here less than 12 months ago.
Whilst there is a degree of "This is the way" (from an internal & external perspective) with what I or anyone else takes on, I did want to audit and review as many aspects of what we should be doing as per policies, terms and conditions, RIPE DB Training, assumed best practice etc.
What is apparent to me is that whilst a policy may describe a "must", it isn't nessecarily prescriptive on the "how" and is sufficiently narrow leaving how the end result is achieved. Certaintly I don't think this how the policies are intended to be written but there are some leaps you need to make as to what you should perhaps do or not do. A policy alone, in the case of RIPE-733 is a good example of this, in particular when you also consider clause 3.0 bullet 4.
I know this isn't a unique problem but:-
- Within quick succession I had two end business customers reach out to us to remove their business name from the description of the relevant INET ASSIGNED PA entry. Reasons cited were security. Whilst I looked at what we could possibly do, on balance we determined that it wasn't an option because of policy, other obligations and objectives. To also help support this view, we could see other LIRs providing service for the same end business who have taken the same approach as us, so at least we are collectively consistent!
- On the other side, there was another new end business reaching out asking why the assignment with their details hadn't been published yet!
Clearly two competing interests!
Where does this lead me?
Well, clearly we want administrative simplicity. Not only that, a clear way to explain internally and externally downstream to end customers but also up to RIPE NCC why we do it the way we do. Referencing clear policies is important to help justify why we take a certain approach and explain any limitations we may have. With the proposal you have presented, whilst I understand the rationale of it, I'm not quite seeing how without some of the discussion being had here, someone can read it and proceed as intended or take our explanation / interpretation of our obligations and apply them consistently. I recognise the latter part is part of the challenge now and a goal to be addressed. The path of least resistance starts to become very attractive!
Perhaps I'm going down a rabbit hole with this. Ultimately I'm looking to make sure I understand how to remain on the right side of things! 😊.
With regard to AGGREGATED-BY-LIR and its existence with IPV6; yes, it's something which drew some interest when I first started and the different approaches. Feels like there is a bit more subtly to this though.
Many thanks,
Brian
-----Original Message-----
From: Tore Anderson <tore(a)fud.no>
Sent: Tuesday, September 12, 2023 7:52 AM
To: Brian Storey <Brian.Storey(a)gamma.co.uk>; address-policy-wg(a)ripe.net
Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
Hi Brian,
* Brian Storey
> Thanks for explaining this particular use case.
>
> Reading the proposed New Policy Text, it provides the LIR with an
> adminsitrative choice. Whilst I understand this choice, the rantionale
> behind the proposal is to find a reasonable way to fill the gap for
> the Provider Allocations not registered for the specific exception
> documented: "IP addresses used solely for the connection of an End
> User to a service provider... can be registered as part of the service
> provider's internal infrastructure".
>
> Given the choice provided in the proposal, it seems to me like I could
> go the other way with this and aggregate everything? The end user
> allocation size distinction no longer looks to apply and I could
> interprete that the "purpose" of the whole aggregate is consistent
> (they are all used to reach "stuff") and therefore chose to not
> register any end user assigned /29s, 28s, /27s etc.
It depends on whether or not all your assignments are completely uniform (apart from the prefix value and length). If they are, you will be able to aggregate them.
This means that they need to share a single common point of contact, which is often the case for assignments associated with fully managed Internet services provided to private individuals and small businesses.
Such assignments would be possible to aggregate.
If on the other hand they are not uniform (for example if your customers operate their own NOCs and therefore have different contact information), you will not be able to aggregate them.
I will try to explain by example here as well. Let's say you currently have two customer assignments as follows:
Customer 1:
inetnum: 192.0.2.0 - 192.0.2.128
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: BRIAN-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
Customer 2:
inetnum: 192.0.2.128 - 192.0.2.192
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: BRIAN-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
As you can see, except for the 'inetnum' value, they are completely identical. That means you will be able aggregate them into a single
object:
inetnum: 192.0.2.0 - 192.0.2.192
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: BRIAN-RIPE
status: AGGREGATED-BY-LIR
mnt-by: BRIAN-MNT
source: RIPE
The second example concerns the case where the assignments are not uniform. Let's say your customers operate their own NOCs, so your starting point instead is having these two assignments:
Customer 1:
inetnum: 192.0.2.0 - 192.0.2.128
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: CUST1-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
Customer 2:
inetnum: 192.0.2.128 - 192.0.2.192
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: CUST2-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
Note how the 'tech-c' attribute differs between the two assignments.
That means that not be able to replace them with an AGGREGATED-BY-LIR object.
> Does this not contradict other purposes / objectives of the registry,
> including the principles of registering public networks or am I
> missing something?
We do not believe so. As demonstrated above, only highly redundant data can be aggregated, so very little actual information lost in the process.
Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel idea, it has been around in the IPv6 policy for many many years. If it was indeed the case that it contradicted the purposes and/or objectives of the registry, someone ought to have noticed and attempted to fix that problem by now. That has not happened, as far as we know, which we take as a sign that there is no such problem in the first place.
Tore
1 year, 6 months
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Tore Anderson
Hi Brian,
* Brian Storey
> Thanks for explaining this particular use case.
>
> Reading the proposed New Policy Text, it provides the LIR with an
> adminsitrative choice. Whilst I understand this choice, the
> rantionale behind the proposal is to find a reasonable way to fill
> the gap for the Provider Allocations not registered for the specific
> exception documented: "IP addresses used solely for the connection of
> an End User to a service provider... can be registered as part of the
> service provider's internal infrastructure".
>
> Given the choice provided in the proposal, it seems to me like I
> could go the other way with this and aggregate everything? The end
> user allocation size distinction no longer looks to apply and I could
> interprete that the "purpose" of the whole aggregate is consistent
> (they are all used to reach "stuff") and therefore chose to not
> register any end user assigned /29s, 28s, /27s etc.
It depends on whether or not all your assignments are completely
uniform (apart from the prefix value and length). If they are, you will
be able to aggregate them.
This means that they need to share a single common point of contact,
which is often the case for assignments associated with fully managed
Internet services provided to private individuals and small businesses.
Such assignments would be possible to aggregate.
If on the other hand they are not uniform (for example if your
customers operate their own NOCs and therefore have different contact
information), you will not be able to aggregate them.
I will try to explain by example here as well. Let's say you currently
have two customer assignments as follows:
Customer 1:
inetnum: 192.0.2.0 - 192.0.2.128
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: BRIAN-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
Customer 2:
inetnum: 192.0.2.128 - 192.0.2.192
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: BRIAN-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
As you can see, except for the 'inetnum' value, they are completely
identical. That means you will be able aggregate them into a single
object:
inetnum: 192.0.2.0 - 192.0.2.192
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: BRIAN-RIPE
status: AGGREGATED-BY-LIR
mnt-by: BRIAN-MNT
source: RIPE
The second example concerns the case where the assignments are not
uniform. Let's say your customers operate their own NOCs, so your
starting point instead is having these two assignments:
Customer 1:
inetnum: 192.0.2.0 - 192.0.2.128
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: CUST1-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
Customer 2:
inetnum: 192.0.2.128 - 192.0.2.192
netname: BRIAN-ISP
country: GB
admin-c: BRIAN-RIPE
tech-c: CUST2-RIPE
status: ASSIGNED PA
mnt-by: BRIAN-MNT
source: RIPE
Note how the 'tech-c' attribute differs between the two assignments.
That means that not be able to replace them with an
AGGREGATED-BY-LIR object.
> Does this not contradict other purposes / objectives of the registry,
> including the principles of registering public networks or am I
> missing something?
We do not believe so. As demonstrated above, only highly redundant data
can be aggregated, so very little actual information lost in the
process.
Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel
idea, it has been around in the IPv6 policy for many many years. If it
was indeed the case that it contradicted the purposes and/or objectives
of the registry, someone ought to have noticed and attempted to fix
that problem by now. That has not happened, as far as we know, which we
take as a sign that there is no such problem in the first place.
Tore
1 year, 6 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
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(a)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(a)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(a)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
>
1 year, 4 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Jan Ingvoldstad
On Tue, Jan 9, 2024 at 3:12 PM Tore Anderson <tore(a)fud.no> wrote:
> Hi again Jan,
>
>
Hello again, Tore, and thanks yet again!
> 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-pers…
>
> «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
>
This is a fairly radical view of how GDPR regulates publishing of personal
data, IMHO erring far to the side of misunderstood caution:
https://commission.europa.eu/law/law-topic/data-protection/reform/rules-bus…
Does "Farmer Fred" alone "allow the identification of a natural person"?
IMHO it does not, and this seems to be the accepted view in various
publicly databases publishing data regarding companies containing parts of
the name of natural persons.
Basically, any public company register would be illegal according to the
interpretation you lean on here.
> 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(a)privacy.example, which is a valid email
> address that is automatically forwarded to e.g. tore+ripe-example(a)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.
>
The policy should be technology agnostic, and when requiring the
publication of contact details for end users, require that such publication
by a LIR conforms to regulations.
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.
The current stance is just not logical.
>
> 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*.
> So maybe we could discuss 1) instead of 2) going forward? :-)
>
I have no problem with 1), as already stated.
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.
>
> 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 is a removal of the text in question.
> 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.
>
I disagree that removing a piece of text is not removing a piece of text.
You can "agree to disagree" all you want, but this is starting to look
dishonest.
>
> 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.
>
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.
That is all, and I believe you will not only have rough consensus, but near
100% consensus.
--
Jan
1 year, 2 months
Re: [address-policy-wg] 2023-04 Who do I speak for?
by denis walker
Hi Peter
On Mon, 16 Oct 2023 at 21:36, Peter Hessler <phessler(a)theapt.org> wrote:
>
> Denis,
>
> Yes, you are correct that that signing your emails saying you are
> co-chair of DB tells the reader that you are speaking on behalf of the
> working group. That may or may not be your intention, but that is how
> people are reading it. No longer signing your emails "co-chair" would
> be a dramatic improvement, for sure. You could also sign them as "not
> speaking as co-chair" to be explicit.
>
> A lot of the critisim against you has been based on the understanding
> that you are acting as a dictator and pushing your agenda. You might
> not agree, but that is how I view your behaviour as co-chair.
>
One problem with that view...you cannot be a dictator if any agreement
to do something needs a consensus of views. This issue has come up a
number of times. The only agenda I have is to improve the RIPE
Database as a product and service, by consensus, and to maintain the
value of a public registry for IP addresses, which is why we are
talking on this list at the moment.
I would accept that I sometimes behave in a pushy manner, but not
dictatorial. And as we have discussed many times, for many issues
involving the RIPE Database, if 'I' don't push conversations no one
will say anything. The evidence is in the archive. Discussion on many
issues won't even start unless I push it onto everyone's agenda.
Conversations die quickly if I don't keep pushing it. There are open
issues we have been trying to reach a consensus on for 7 years but we
average about 1 comment every 6 months.
We simply cannot get many people to talk about many of the RIPE
Database issues. This is why I made the presentation at the last RIPE
Meeting about how we manage the RIPE Database. What we are doing right
now is simply not working. We cannot continue trying to manage it in
this way. As Leo mentioned some months ago, the number of people
contributing to mailing list discussions is extremely low.
I also raised the issue of the RIPE Database technology and data model
in the recent policy discussion on this list. That is one of those
'bury your head in the sand and pretend I never said it' topics. You
can call me dictatorial or pushy or say it is 'my' agenda if you like.
But I am retired. If the RIPE Database falls over in a heap and dies,
I don't lose any money. Some of you might. The technology is 25 years
old. The data model is 25-30 years old. It is not fit for purpose any
more. Just look at Ed's impact analysis on assigning a whole
allocation (one of those 7 year old open issues). We can't keep
hacking it like this. In Iceland Daniel said it is "time to stop
tinkering around the edges". That is all we have done ever since. If
we implement this feature we will break it for sure. Am I the only
person who can see this event on the horizon? Isn't it my duty as a
co-chair of the DB-WG to raise awareness of impending doom of this
dinosaur? If I was a dictator the RIPE NCC would already be
re-developing chunks of the database. Unfortunately I can't even get
anyone to talk about it. The RIPE Database is one of the central
pillars of the registry. One of the core functions of the RIPE NCC as
an RIR, which the members pay for. Yet no matter how many cracks I
point out to you, everyone looks the other way.
In the end you can talk all you like about my style (again). But is
this just a deflection tactic because you don't want to talk about the
issues I raise? Clearly there are many different views about the
registry. And I haven't even started yet on the recent report on the
latest RIPE NCC survey. That has implications for both address policy
and the database...but I am sure many of you have already read it and
noted those implications.
cheers
denis
> -peter
>
>
> On 2023 Oct 16 (Mon) at 21:09:47 +0200 (+0200), denis walker wrote:
> :Hi Mirjam
> :
> :Thanks for the clarifications. On points 1 and 2 I bow to your better
> :judgements.
> :
> :For point 3 I see your view. But I think I get singled out for unfair
> :criticism here. During my reappointment as co-chair of the DB-WG some
> :people heavily criticised me for taking part in discussions on mailing
> :lists whilst being a co-chair. I believe that was personal and not
> :objective criticism. It was suggested that 'I' am doing something no
> :other chair has ever done and it is wrong. They have short memories.
> :The previous chairs to the current set for the DB-WG were often
> :heavily involved in discussion on the database and other mailing
> :lists. The chairs before them (including the original chair) were also
> :often involved in discussions on multiple lists. So I haven't started
> :a new trend. The (co) chairs of the DB-WG (and perhaps other WGs) have
> :been involved in discussions on various mailing lists since the lists
> :started in 1992.
> :
> :Another interesting observation is that before the current chairs of
> :the DB-WG, ALL previous chairs only ever signed any email with their
> :first name. None of them ever signed anything 'as' a co-chair. Looking
> :at other mailing lists, including this AP-WG, most chairs
> :intermittently sign emails (at least on their own list) with or
> :without the chair title suffix. Again this goes back to the beginning
> :of time. So there doesn't seem to be any convention on how chairs sign
> :emails. Maybe I'll just sign with my name (as many others do), then I
> :can't be criticised for wearing the wrong hat.
> :
> :cheers
> :denis
> :
> :On Mon, 16 Oct 2023 at 16:44, Mirjam Kuehne <mir(a)zu-hause.nl> wrote:
> :>
> :> Hi Denis,
> :>
> :> Thank you for explaining how you see your role.
> :>
> :> I would like to clarify a few things you mentioned in your mail. I hope
> :> this will be useful especially for RIPE community members who might not
> :> have the long history in the community that some of us have.
> :>
> :> 1. Regarding the role of the RIPE Community:
> :>
> :> The fact that the RIPE community is not a legal entity and that it is
> :> open to anyone who wants to participate, does not mean it is "undefined".
> :>
> :> From the beginning, the RIPE community has agreed to document its
> :> decisions and processes as RIPE documents that are publicly accessible.
> :> In the RIPE Terms of Reference (ripe-001) [1] the mission and scope of
> :> RIPE is defined. We have a clearly defined policy development process
> :> and clearly defined governance processes that the community agrees to
> :> follow.
> :>
> :> Decisions are made by consensus and RIPE documents go through a defined
> :> community review.
> :>
> :> 2. Regarding the relation between RIPE and the RIPE NCC:
> :>
> :> The RIPE NCC clearly states its role as the secretariat of RIPE in its
> :> mission, activity plan and budget. These are formal documents the RIPE
> :> NCC members vote on.
> :>
> :> Also, there is a long track record of the RIPE NCC following guidance
> :> from the RIPE community.
> :>
> :> 3. Regarding the role of a chair:
> :>
> :> It is the responsibility of a chair to listen and to guide discussions,
> :> to summarise and to actively build consensus.
> :>
> :> Those of us who serve in a special function or have a leadership role
> :> are aware of the fact that people tend to see us as being in that role.
> :> Therefore we need to take extra care if and when we decide to
> :> participate in a discussion as an individual.
> :>
> :> Kind regards,
> :> Mirjam
> :> (RIPE Chair)
> :>
> :>
> :> [1] RIPE Terms of Reference
> :> https://www.ripe.net/publications/docs/ripe-001
1 year, 5 months
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
Hi Tore
Your claims are not correct. Your simple example hides a lot of
detail. I have given a real life example below taken from the database
to illustrate what I mean. My apologies to the resource holder, but it
is a perfect example to illustrate several points.
On Tue, 12 Sept 2023 at 08:51, Tore Anderson <tore(a)fud.no> wrote:
>
> Hi Brian,
>
> * Brian Storey
>
> > Given the choice provided in the proposal, it seems to me like I
> > could go the other way with this and aggregate everything? The end
> > user allocation size distinction no longer looks to apply and I could
> > interprete that the "purpose" of the whole aggregate is consistent
> > (they are all used to reach "stuff") and therefore chose to not
> > register any end user assigned /29s, 28s, /27s etc.
>
> It depends on whether or not all your assignments are completely
> uniform (apart from the prefix value and length). If they are, you will
> be able to aggregate them.
Your definition of 'completely uniform' seems to only apply to contact
details, as you make clear in the next paragraph. Many assignment
objects currently contain more information than just contact
references. You are making the assumption that the RIPE Database is
still nothing more than an operator's contact database for network
operational issues. In which case all you need is the tech-c.
>
> This means that they need to share a single common point of contact,
> which is often the case for assignments associated with fully managed
> Internet services provided to private individuals and small businesses.
> Such assignments would be possible to aggregate.
>
> If on the other hand they are not uniform (for example if your
> customers operate their own NOCs and therefore have different contact
> information), you will not be able to aggregate them.
>
> I will try to explain by example here as well. Let's say you currently
> have two customer assignments as follows:
>
> Customer 1:
>
> inetnum: 192.0.2.0 - 192.0.2.128
> netname: BRIAN-ISP
> country: GB
> admin-c: BRIAN-RIPE
> tech-c: BRIAN-RIPE
> status: ASSIGNED PA
> mnt-by: BRIAN-MNT
> source: RIPE
>
> Customer 2:
>
> inetnum: 192.0.2.128 - 192.0.2.192
> netname: BRIAN-ISP
> country: GB
> admin-c: BRIAN-RIPE
> tech-c: BRIAN-RIPE
> status: ASSIGNED PA
> mnt-by: BRIAN-MNT
> source: RIPE
>
> As you can see, except for the 'inetnum' value, they are completely
> identical. That means you will be able aggregate them into a single
> object:
But your example is a bare bones object.
>
> > Does this not contradict other purposes / objectives of the registry,
> > including the principles of registering public networks or am I
> > missing something?
>
> We do not believe so. As demonstrated above, only highly redundant data
> can be aggregated, so very little actual information lost in the
> process.
In real life lots of information may be lost.
>
> Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel
> idea, it has been around in the IPv6 policy for many many years. If it
> was indeed the case that it contradicted the purposes and/or objectives
> of the registry, someone ought to have noticed and attempted to fix
> that problem by now. That has not happened, as far as we know, which we
> take as a sign that there is no such problem in the first place.
This community has very little appetite to fix things properly if a
quick fix will do or they can live with existing problems. The
constant 'fight' to try to fix many problems with the RIPE Database
illustrates this point very well.
Now let's look at a real life example.
whois -rBm 195.238.192.0 - 195.238.223.255
The first thing to note is that the admin-c and tech-c values are the
same in all the more specific assignments. Even the mnt-by is the
same, although you make no mention if that is a blokker for
aggregation or not. So by your definition these are 'completely
uniform' objects and can be aggregated.
You will also note that all these objects contain optional descr
attributes. These attributes contain name and address details of the
end user. That is important information for many stakeholder groups
using the RIPE Database public registry. That detail will be lost in
an aggregation. Given that current policy requires these assignments
to be registered in the public registry, many users do include this
detail. Now we all know the RIPE Database design and technology is
very old and it does currently require some effort to manage this
data. (A problem that all users have noticed but no one has attempted
to fix.) Given a 'short cut' option, human nature suggests people will
use it, even if it is not the right thing to do for a public registry.
So aggregating across the whole database, may result in a massive
amount of detail being lost from the public registry.
Also note that there are gaps in the more specific assignments for
this allocation. For example 195.238.193.224 - 195.238.193.255 is not
assigned. Can your aggregated objects span these gaps? If so then we
lose sight of what address space is in use or available. It may no
longer be needed for further allocations but people do still use that
information.
The assignments are all randomly sized. Which is why you have dropped
the inet6num assignment-size attribute for inetnum objects. So if I am
getting abuse from one specific IP address what should I do? I have no
idea from the aggregated block what the block size is that includes
this one IP address. Is there any other way to find this information,
maybe from routing details? If not, should I block and blacklist the
entire aggregated block? That could affect hundreds, maybe even
thousands, of users in some cases. This is not a problem with IPv6 as
you know the size of the block containing that address.
cheers
denis
c0-chair DB-WG
>
> Tore
>
> --
>
> 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
1 year, 6 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Jeroen Lauwers
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.
1 year, 3 months
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Cynthia Revström
After reading denis's response I realized that I responded a bit too
hastily with my +1.
I am going to retract my support for this proposal as I really don't
get why you would need this without the "assignment-size" attribute.
I might have missed something but I can't see what possible benefit
"AGGREGATED-BY-LIR" has over "SUB-ALLOCATED PA" without it.
The only thing that I can think of is if you just want to just comply
with the policy without providing any additional info, in which case
the policy should just be updated to not require it if that is what
the community wants.
My reason for saying this is that some LIRs might choose to remove
specific inet(6)num objects that they have already created and just
create a big "AGGREGATED-BY-LIR" inet(6)num object as you can't have
inet(6)num objects under it.
Personally I would prefer it if an LIR just chose to document some of
their assignments while leaving some undocumented over "documenting"
them in a way that really doesn't specify any meaningful information.
If I have missed something and there actually is a true benefit[0] to
using "AGGREGATED-BY-LIR" without an "assignment-size" attribute then
do let me know.
I would really prefer if this was considered carefully before
implementing it due to the potential risk of losing data currently in
the database.
-Cynthia
[0]: "true benefit" here referring to something beyond just making it
compliant with RIPE policy as I think there are better solutions if
that is the case.
On Tue, Sep 12, 2023 at 4:56 PM denis walker <ripedenis(a)gmail.com> wrote:
>
> Hi Tore
>
> Your claims are not correct. Your simple example hides a lot of
> detail. I have given a real life example below taken from the database
> to illustrate what I mean. My apologies to the resource holder, but it
> is a perfect example to illustrate several points.
>
> On Tue, 12 Sept 2023 at 08:51, Tore Anderson <tore(a)fud.no> wrote:
> >
> > Hi Brian,
> >
> > * Brian Storey
> >
> > > Given the choice provided in the proposal, it seems to me like I
> > > could go the other way with this and aggregate everything? The end
> > > user allocation size distinction no longer looks to apply and I could
> > > interprete that the "purpose" of the whole aggregate is consistent
> > > (they are all used to reach "stuff") and therefore chose to not
> > > register any end user assigned /29s, 28s, /27s etc.
> >
> > It depends on whether or not all your assignments are completely
> > uniform (apart from the prefix value and length). If they are, you will
> > be able to aggregate them.
>
> Your definition of 'completely uniform' seems to only apply to contact
> details, as you make clear in the next paragraph. Many assignment
> objects currently contain more information than just contact
> references. You are making the assumption that the RIPE Database is
> still nothing more than an operator's contact database for network
> operational issues. In which case all you need is the tech-c.
>
> >
> > This means that they need to share a single common point of contact,
> > which is often the case for assignments associated with fully managed
> > Internet services provided to private individuals and small businesses.
> > Such assignments would be possible to aggregate.
> >
> > If on the other hand they are not uniform (for example if your
> > customers operate their own NOCs and therefore have different contact
> > information), you will not be able to aggregate them.
> >
> > I will try to explain by example here as well. Let's say you currently
> > have two customer assignments as follows:
> >
> > Customer 1:
> >
> > inetnum: 192.0.2.0 - 192.0.2.128
> > netname: BRIAN-ISP
> > country: GB
> > admin-c: BRIAN-RIPE
> > tech-c: BRIAN-RIPE
> > status: ASSIGNED PA
> > mnt-by: BRIAN-MNT
> > source: RIPE
> >
> > Customer 2:
> >
> > inetnum: 192.0.2.128 - 192.0.2.192
> > netname: BRIAN-ISP
> > country: GB
> > admin-c: BRIAN-RIPE
> > tech-c: BRIAN-RIPE
> > status: ASSIGNED PA
> > mnt-by: BRIAN-MNT
> > source: RIPE
> >
> > As you can see, except for the 'inetnum' value, they are completely
> > identical. That means you will be able aggregate them into a single
> > object:
>
> But your example is a bare bones object.
>
> >
> > > Does this not contradict other purposes / objectives of the registry,
> > > including the principles of registering public networks or am I
> > > missing something?
> >
> > We do not believe so. As demonstrated above, only highly redundant data
> > can be aggregated, so very little actual information lost in the
> > process.
>
> In real life lots of information may be lost.
>
> >
> > Finally, please keep in mind that AGGREGATED-BY-LIR is not a novel
> > idea, it has been around in the IPv6 policy for many many years. If it
> > was indeed the case that it contradicted the purposes and/or objectives
> > of the registry, someone ought to have noticed and attempted to fix
> > that problem by now. That has not happened, as far as we know, which we
> > take as a sign that there is no such problem in the first place.
>
> This community has very little appetite to fix things properly if a
> quick fix will do or they can live with existing problems. The
> constant 'fight' to try to fix many problems with the RIPE Database
> illustrates this point very well.
>
> Now let's look at a real life example.
>
> whois -rBm 195.238.192.0 - 195.238.223.255
>
> The first thing to note is that the admin-c and tech-c values are the
> same in all the more specific assignments. Even the mnt-by is the
> same, although you make no mention if that is a blokker for
> aggregation or not. So by your definition these are 'completely
> uniform' objects and can be aggregated.
>
> You will also note that all these objects contain optional descr
> attributes. These attributes contain name and address details of the
> end user. That is important information for many stakeholder groups
> using the RIPE Database public registry. That detail will be lost in
> an aggregation. Given that current policy requires these assignments
> to be registered in the public registry, many users do include this
> detail. Now we all know the RIPE Database design and technology is
> very old and it does currently require some effort to manage this
> data. (A problem that all users have noticed but no one has attempted
> to fix.) Given a 'short cut' option, human nature suggests people will
> use it, even if it is not the right thing to do for a public registry.
> So aggregating across the whole database, may result in a massive
> amount of detail being lost from the public registry.
>
> Also note that there are gaps in the more specific assignments for
> this allocation. For example 195.238.193.224 - 195.238.193.255 is not
> assigned. Can your aggregated objects span these gaps? If so then we
> lose sight of what address space is in use or available. It may no
> longer be needed for further allocations but people do still use that
> information.
>
> The assignments are all randomly sized. Which is why you have dropped
> the inet6num assignment-size attribute for inetnum objects. So if I am
> getting abuse from one specific IP address what should I do? I have no
> idea from the aggregated block what the block size is that includes
> this one IP address. Is there any other way to find this information,
> maybe from routing details? If not, should I block and blacklist the
> entire aggregated block? That could affect hundreds, maybe even
> thousands, of users in some cases. This is not a problem with IPv6 as
> you know the size of the block containing that address.
>
> cheers
> denis
> c0-chair DB-WG
>
>
> >
> > Tore
> >
> > --
> >
> > 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
1 year, 6 months
Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by Carlos Friaças
Greetings,
After reading your message, i had to go search if i expressed an opinion
on 2023-04 or not. It seems i did (back in September), but perhaps i
wasn't 100% clear about my opposition to this proposal.
So in order to make it clear for the co-chairs, i do oppose this proposal,
on the grounds that the quality of publicly available registration data
is likely to decrease if this proposal is approved.
Best Regards,
Carlos
On Fri, 5 Apr 2024, denis walker wrote:
> Colleagues
>
> I am not surprised this policy proposal (2023-04) has gone to last
> call. I expected this from the start, no matter what anyone said. And
> I won't be surprised when it is approved. I used to wonder why no one
> would even talk about bringing the RIPE Database into the modern
> world. Why continue to use an ancient, broken tool that is barely fit
> for purpose? It is quite obvious now. Playing on the complexity and
> difficulties with using the database allows people to justify changing
> the purpose and the rules, to make it more convenient. That is simpler
> and cheaper than fixing the tool. It is easy for a small vocal group
> to sell 'simple and cheap' to a silent majority. Convenience is easier
> to do than right. But it may have consequences.
>
> The proposers have assured us all that this proposal is about nothing
> more than introducing this optional, minor, inconsequential feature
> that changes nothing. They have argued that the RIPE NCC has
> "repeatedly" verified their claim that this proposal changes nothing
> 'of significance'. This is based on the RIPE NCC legal team's
> confusing impact analysis and the comments made once and referred to
> once by the RIPE NCC Registration Services through messages passed on
> by the policy officer. The legal team declined to clarify the
> confusing wording of their impact analysis. No one from Registration
> Services was willing to discuss the claims that they have been wrongly
> applying the policy for a number of years, or the reason why and when
> they stopped correctly applying the policy. I thought RIPE NCC staff
> were being encouraged to be more involved in community discussions?
>
> It has been said and confirmed recently by several people from the
> community that we no longer understand what some of the registration
> data in the RIPE Database means, why it is there and why we have these
> rules about it. This is despite the actual, current wording of these
> rules having been written into a version of the policy published in
> October 2003 that was authored by some people who are still leading
> members of this community, and at the time were RIPE NCC staff. The
> infamous line being removed by this proposal was a re-wording of
> earlier rules introduced in address policy with a long list of early
> authors, again including some people who are still leading members of
> this community. I asked if any one of these community leaders would
> offer some background information to the community on this, now poorly
> understood, registration data and the rules governing it. That may
> have helped with our current understanding. If we actually understood
> the data and rules that we are about to change, we might have more
> confidence in doing so. But nothing was said on this background.
>
> Europol has expressed serious concerns about these changes. They have
> stated that it takes time for them to consult with national LEAs, the
> EU commision and other partners. If someone had informed them earlier
> of the changes being considered that may affect them, they may have
> had sufficient time to do these consultations. Or perhaps they would
> have been able to express their deep concerns at an early stage,
> before the minds of the vocal few were made up. I did suggest early on
> in the discussion that the RIPE NCC contacts stakeholders of the RIPE
> Database and invite them to join the discussion. I was quickly told by
> other community members on the mailing list that this was not part of
> the policy development process. [Maybe it should be...]
>
> It is extraordinary that we have now reached a position where the
> convenience of a handful of vocal operators in this community is
> considered so important that we must proceed with all haste to
> introduce this optional, minor, inconsequential feature that changes
> nothing, without delay. That is without even a delay to allow Europol
> to complete it's consultations and report back to the working group. I
> saw references recently on the ripe.net website and LinkedIn about
> some productive meeting between the RIPE NCC and some internet
> governance groups. I hope the attitude of the technical community over
> this proposal won't undermine those meeting achievements. A technical
> community that clearly has not watched John Curran's keynote speech at
> NANOG that covers this very situation involving internet governance,
> the technical community and civil society. I would advise you all to
> watch it:
> https://www.youtube.com/watch?v=U1Ip39Qv-Zk
>
> You may question my comments about the vocal few. But the details of
> the who and how many are there for everyone to see in the public
> archive of these mailing lists. Only 22 people commented during the
> months of discussion over 2023-04. Of those, 6 people only made one
> comment and another 6 only two comments. Some of those 22 also opposed
> this proposal. So the number of people who actually expressed support
> is quite small. When you analyse these details for proposals across
> multiple WGs in recent years, and cross reference the who and how
> many, you see that there is a very small number of vocal people who
> tend to dominate these discussions. It is basically this small group
> of people whose voices dictate RIPE policy. The problem there is that
> we may find policy, accidentally or intentionally, following an agenda
> that suits the needs of these people, rather than the wider, silent
> community. Unfortunately, we don't have any other way to do this at
> the moment. However, when a change is controversial, has many serious
> objections and offers so few benefits, to push it through with so few
> supporters is very questionable. Especially as it has been well
> established during the long discussions that we (collectively) do not
> even understand the registration data and governing rules that we are
> about to substantially change. Nor do we have any firm evidence that
> even the minor benefits claimed by the proposers are likely to occur.
>
> I could go on and dispute the co-chairs' reasoning for declaring a
> rough consensus. But I have said it all before and it has been
> disregarded. Although I don't believe I have yet asked them for the
> evidence or statistical reasoning why they assert that this change
> will encourage those who don't declare any End User data now, will
> suddenly decide to provide it after this change.
>
> It is of course total nonsense to suggest that this change will end up
> offering more accurate data on assignments to End Users. It is quite
> possible that those resource holders that currently don't declare End
> User assignment data now, will simply create two appropriately sized,
> anonymous, aggregated objects below each of their allocations. That is
> 'job done' as far as operations is concerned. Those objects will never
> need to be updated again. No one has any clue how much, if any, of
> that address space is in use, by how many End Users with how many
> addresses each, or who the End Users are, or even if the same block of
> address space has been assigned to more than one End User by mistake.
> All that information will be lost. Including one of the basic
> functions of the registry, to ensure uniqueness of address usage.
>
> Quoting statistics on the number of allocations with no assignments is
> of course simply playing with numbers. It adds nothing to this
> discussion, but is intended to look like a supporting argument. A
> perceived problem that needs to be solved, but may not even exist on
> the implied scale. We don't know how many of those allocations are the
> /22 and /24 allocations made during the final stages of runout. These
> were 'intended' to be for new entrants into the industry who planned
> to provide LIR services. They would not be expected to have
> assignments if they were used for their infrastructure. (Or maybe they
> were not allocated as intended?) Many allocations are also made to
> organisations who do not provide LIR services and have no End Users.
> The address space is simply used by their organisation.
>
> Leo's final comment is a good one to end on.
> "Those LIRs that want to share data are already doing so. Those who
> would like to share some data if it were easier to do so will be
> accommodated if this proposal becomes policy."
> This basically sums up everything. ['want' 'like'] The RIPE NCC
> stopped enforcing address policy after runout because they did not
> believe they had any power to do so. Here Leo is suggesting that
> complying with policy is a choice. Some LIRs will choose to comply,
> others will choose not to comply with RIPE policy. Neither this
> community nor the RIPE NCC has any power to enforce any policy on
> operators. We can agree or disagree on any policy we like, but it
> cannot be enforced. RIPE policy has no teeth.
>
> The proposers have assured us that their focus is on providing this
> aggregation feature. So we must be able to assume that they, and the
> co-chairs, have deeply considered the implications of this change to
> the "status:'' attribute. So there shouldn't be any unintended
> consequences...
>
> Hopefully common sense will prevail and we will pause this process to
> assess where we have been, where we are and where we are going. (I
> think that is unlikely to happen...)
>
> 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.
> ========================================================
>
> On Mon, 11 Mar 2024 at 09:30, Leo Vegoda <leo(a)vegoda.org> wrote:
>>
>> Dear Address Policy WG,
>>
>> There was a consensus on this proposal and we are moving it forward to
>> Last Call. The RIPE NCC will publish an announcement with dates.
>>
>> There was a request, in Rome, for clarity over whether aggregated
>> assignments needed to have a fixed size or could vary. The proposers
>> suggested that a fixed size should be optional.
>>
>> We extended the list discussion by a month and the two issues raised
>> have been addressed.
>>
>> One was End User sites not having the End User's own admin-c instead
>> of the LIR's. There has been extensive discussion of this. One key
>> reason given is that it is common and acceptable to outsource a part
>> of an organisation's operations to another, more skilled, operator.
>> The RIPE NCC's impact analysis noted that the proposal "simply leaves
>> the status quo unchanged." It would not need to update its operational
>> processes.
>>
>> Concerns were also raised that aggregating assignments would impact
>> criminal investigations. But this proposal is intended to improve the
>> quality of data registered by offering LIRs a less arduous way to
>> share registration data. At the end of 2023 there were over 19,000 PA
>> allocations without any assignments. Those LIRs that want to share
>> data are already doing so. Those who would like to share some data if
>> it were easier to do so will be accommodated if this proposal becomes
>> policy.
>>
>> Kind regards,
>>
>> Leo Vegoda, for the Address Policy WG co-chairs
>>
>> --
>>
>> 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
>
11 months, 4 weeks