Re: [address-policy-wg] RIPE Code of Conduct and discussion on this list
by Carsten Schiefner
Hi Leo and AP WG co-chairs,
On 11.01.2024 14:42, Leo Vegoda wrote:
> Earlier, Denis sent a message
I'd assume that you refer to one of these two most recent emails from
Denis of the "[address-policy-wg] 2023-04 Review Phase (Add
AGGREGATED-BY-LIR status for IPv4 PA assignments)" thread:
* Date: Thu, 11 Jan 2024 01:40:33 +0100
* Date: Thu, 11 Jan 2024 03:20:58 +0100
These two emails most certainly bear a quite robust style of writing.
Also wrt. content they - taking Tore's emails also into account for a
full picture - are heavily going in circles.
However, having just re-read them carefully again, I fail to see
multiple ad-hominem attacks and/or "Aggressive communication" such as
"Calling people offensive names" as you line out here:
> that contained multiple ad-hominem
> attacks on the proposers of 2023-04 (Add AGGREGATED-BY-LIR status for
> IPv4 PA assignments). This is in conflict with our Code of Conduct. We
> will not tolerate breaches of the Code of conduct.
>
> As a reminder, our Code of Conduct urges us to "be open, considerate,
> and respectful." Further, "Aggressive communication" such as "Calling
> people offensive names" is not allowed.
Certainly, different people will come to different judgements in their
respective assessments of third parties' communications styles - that is
why would like to share mine: I truly believe that Denis' communication
style is heavily "passionate" (thanks, Sebastian! ;-) but IMHO still
fully within the boundaries set by the Code of Conduct.
Therefore...
> Denis has previously had a private warning. As this is his second
> breach in a discussion of this proposal, we will instruct the RIPE NCC
> to stop him from posting to the list for 30 days.
... I'd like to ask you as the AP WG co-chairs collective to reconsider
your decision to temporarily revoke Denis' posting rights. Thank you!
> Also, as the discussion has derailed, we will extend the Review Phase
> by four weeks.
This makes all the sense to me. Thanks again!
> We encourage everyone to focus comments on the proposal
> and its potential impact. Do not comment on individuals, their
> characteristics, or motivations.
Strictly separating comments on the proposal and its potential impact
from those of perceived motivations can be tricky at times - even more
so as the proposals themselves bear their respective motivation. Or
reasoning. Or whatever you want to call it.
Doubting the motivation of the proposal and instead assuming another one
should IMHO still be considered as part of a fruitful discussion.
Yes, the line can get very thin very quickly.
But we're not - see above - yet there and across it, I believe.
All the best,
-C.
1 year, 2 months
Re: [address-policy-wg] 2023-04 Proposal Accepted (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by APEX NCC ORG
Hello, Tore!
Thank you for quick feedback.
After the example you gave - I understood the purpose of the
introduction for IPv4.
> I do not quite understand this use case. I believe it is not common to
> split an ASSIGNED PA object into more specific ASSIGNED PA objects. To
> be honest, I didn't even know that was possible. Anyway…
So sorry.
My mistake.
> ASSIGNED PA object (for example /20)
I had in mind *ALLOCATED* *PA* */20*, which divided to much /*24*, which
is*ASSIGNED PA *already.*
*Thank you!*
*
On 4/16/24 13:55, Tore Anderson wrote:
> Hi there,
>
> * APEX NCC ORG
>>
>> Can you provide an example of using and registering an
>> AGGREGATED-BY-LIR object for IPV4?
>> Who is this for and when?
>>
> It has exactly the same use case as AGGREGATED-BY-LIR for IPv6. It is
> primarily intended for LIRs which need to make a large number of
> essentially identical assignments, which can then be aggregated into a
> single database object rather than registering a bunch of redundant
> objects.
>
> Here's an example, which represent 256 essential identical ASSIGNED PA
> objects:
>
> inetnum: 192.0.2.0 - 192.0.2.255
> netname: CLOUDPROVIDER-CUSTOMER-VMS
> descr: IP addresses dynamically assigned to virtual machines running
> in CloudProvider's public cloud infrastructure # this is optional
> assignment-size: 32 # this is optional
> country: NO
> admin-c: CLOUDPROVIDER-RIPE
> tech-c: CLOUDPROVIDER-RIPE
> status: AGGREGATED-BY-LIR
> mnt-by: CLOUDPROVIDER-MNT
> source: RIPE
>
>
>> Is its use mandatory?
>>
> Not at all, feel free to ignore it and continue doing whatever you've
> been doing so far.
>
>
>> Initially, the assignment policy was discussed as an assignment for
>> cloud providers.
>> What should a provider do, for example, if it has a status ASSIGNED
>> PA object (for example /20),
>> splits it into /24 objects also like ASSIGNED PA with additional
>> routes obj. for its end clients (without NAT / with NAT)?
>>
> I do not quite understand this use case. I believe it is not common to
> split an ASSIGNED PA object into more specific ASSIGNED PA objects. To
> be honest, I didn't even know that was possible. Anyway…
>
>
>> Is it here an AGGREGATED-BY-LIR status objects? Or NOT?
>>
> …as I understand it, in your example, the 16 /24 ASSIGNED PA objects
> have unique mnt-routes: values. If so, that means you cannot aggregate
> the 16 /24s into a single AGGREGATED-BY-LIR object.
>
> Tore
--
Best wishes,
APEX NCC ORG
--------------------------------
+38(056)-731-99-11,
+38(067)-731-99-11,
+38(050)-731-99-11,
www.trifle.net
11 months, 2 weeks
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Sebastian Graf
Dear Jan!
You and Denis are arguing that registration/user data needs to include
certain (sometimes sensitive details (ie: PII)) that need to be put in
the database. Your Argument is that this is a policy requirement.
When I tried to get both of you to spell out what this "user
data"/"contact information" is exactly and where that is defined - We do
not get a clear answer.
I have read every single of denis replies/comments.
When asked, neither of you cannot reference a policy section that
actually spells out what is considered "contact details".
According to your own e-mail - your opinion is based on a software
interface/implementation (ripe-db). This interface itself is an
interpretation of what the policy could mean.
The Interface of the DB also does not specify what kind of Information
(regular address, proxy address,...) needs to be inserted. Just that
some fields need to be filled out (and its open to interpret what goes
into them to a certain extent - wich is the point of this discussion).
The relationship is policy -to- database. Not Database -to- Policy.
And yet, we have no document or reference that defines what kind of
contact information (direct only, or indirect via proxy/masking/....) is
permissable.
Just that it needs to be maintained (meaning "if it works" -> OK).
In my previous e-mail i did argue that in some scenarios working
witout"proxy" data is impossible (think: Role/NOC Contacts).
I have also read your reference
https://www.ripe.net/publications/docs/ripe-705 . It defines an abuse
inbox is mandatory for certain objects. And that it has to be an email
address. - Nothing else.
Regards
On 1/12/24 09:40, Jan Ingvoldstad wrote:
> On Fri, Jan 12, 2024 at 9:28 AM Sebastian Graf
> <ripe-lists(a)sebastian-graf.at> wrote:
>
> Dear Jan!
>
>
> Dear Sebastian,
>
> Thank you for your reply. But you have not answerred my question.
>
> I answered your question, but I did not understand that you intended
> your ancillary comment as an additional question. Sorry about that.
>
> We are all clear/well aware on the fact that the policy states
> (paraphrasing here: resources need to be registered and the
> registions need to have contact information).
>
> We are looking for the DEFINITION of "contact details of the End
> User.". This is not directly defined (as far as i can tell) and is
> therefore open for interpretation.
>
> Unless i missed something?
>
>
> As I understand it, this comes from how contact objects are defined in
> the database, and this is what RIPE-804 references.
>
> Denis has provided more detailed context.
>
> RIPE-705 sets specific requirements regarding abuse contact details.
>
> --
> Jan
>
1 year, 2 months
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Tore Anderson
Hello Cynthia,
* 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.
The reason why we took "assignment-size" out, is that we understood its
purpose (in the IPv6 policy) to be related to calculating the HD-ratio,
which in turn is done to justify subsequent allocations.
As I'm sure you're well aware, none of those things exist in IPv4, so
there did not appear to be any purpose in keeping it in.
> 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.
You include inet6num objects here, so I want to make it crystal clear
that AGGREGATED-BY-LIR already exists in IPv6 and that this proposal
does not in any way change it.
Therefore, if there really is something to worry about here, we ought
to have seen evidence of it happening already in IPv6. I am not aware
of anything like that, though.
> [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.
We believe policy compliance is a goal worth striving for. As Gert
said: «Anyone unwilling to register proper data is able to do so
already today», but this requires ignoring certain requirements of the
policy.
This is not a hypothetical situation. As noted in the proposal text:
«As of August 2023, there were 19,221 PA allocations without any child
PA assignments held by 10,052 LIRs» (for the record: this data comes
from the RIPE NCC, not us proposers)
Our hypothesis is that a fair share of those are used for high-churn
and automated small assignments (think cloud VPS instances, customer
DHCP pools, etc.) which it is impractical to keep the RIPE database
updated with in a synchronous manner. So they don't bother to even try
to comply with the registration requirements in the policy.
Another set of LIRs of unknown quantity will instead (ab)use the
«solely for the connection» exception to improperly register such
assignments as being part of their own infrastructure. While perhaps a
lesser evil compared to the above, this approach is not compliant with
the policy either.
With AGGREGATED-BY-LIR, we want to provide an attainable way for such
LIRs to become policy compliant. We do believe there is a "true
benefit" in that.
Tore
1 year, 6 months
Draft Address Policy WG Agenda for RIPE 87, Rome
by Leo Vegoda
Hi,
Here is our draft agenda for Rome.
We can make refinements if needed, so please contact the chairs if you
would like us to add or change something.
Kind regards,
Leo
Session 1 starts: 09:00
A. Introduction [5 min]
B. Chair Selection [10 min]
C. NRO NC / ICANN ASO AC Update [10 min]
Hervé Clement and/or Sander Steffann
D. Registry Services Update Followed by Q&A [15 min]
Marco Schmidt, RIPE NCC
E. Policy Update Followed by Q&A [15 min]
Angela Dall'Ara, RIPE NCC
F. Discussion: What is the purpose of IPv4 assignment registration in
2024? [30 mins]
[co-chairs to show 1 discussion slide]
Session 1 ends: 11:00
☕
Session 2 starts: 11:30
G. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins]
Jeroen Lauwers, A2B Internet
Tore Anderson, Redpill Linpro
H. Improving IPv6 PI Policy [25 mins]
Tobias Fiebig
I. AOB [10 mins]
Session 2 ends: 12:30
1 year, 4 months
@EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Kessler, Emmanuel
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
1 year, 2 months
RIPE Code of Conduct and discussion on this list
by Leo Vegoda
Dear Working Group,
Earlier, Denis sent a message that contained multiple ad-hominem
attacks on the proposers of 2023-04 (Add AGGREGATED-BY-LIR status for
IPv4 PA assignments). This is in conflict with our Code of Conduct. We
will not tolerate breaches of the Code of conduct.
As a reminder, our Code of Conduct urges us to "be open, considerate,
and respectful." Further, "Aggressive communication" such as "Calling
people offensive names" is not allowed.
Denis has previously had a private warning. As this is his second
breach in a discussion of this proposal, we will instruct the RIPE NCC
to stop him from posting to the list for 30 days.
Also, as the discussion has derailed, we will extend the Review Phase
by four weeks. We encourage everyone to focus comments on the proposal
and its potential impact. Do not comment on individuals, their
characteristics, or motivations.
Kind regards,
Leo Vegoda, for the Address Policy WG co-chairs
1 year, 2 months
@EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Kessler, Emmanuel
Dear Leo Vedoga,
Thanks for your interest and constructive mind,
statistics are sometimes a challenge in our activities however I consult my experts so as to provide you, a better idea of the impact.
Kind regards
Emmanuel Kessler
Cybercrime centre-EUROPOL
-----Original Message-----
From: Leo Vegoda <leo(a)vegoda.org>
Sent: mercredi 17 janvier 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, 2 months
Re: [address-policy-wg] @EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Leo Vegoda
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, 2 months
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Tore Anderson
Hello Denis,
Let me start off by clearing up a misunderstanding:
My brief example did not mean to convey that non-uniform contact
information is the only thing that could make a set of objects non-
uniform and thus unsuitable for AGGREGATED-BY-LIR.
Rather, the exact opposite was the intended meaning - which is that
almost any attribute can make a set of objects non-uniform. The tech-c
attribute was only used an example to demonstrate this.
With that out of the way, my answers to your remaining points follow
in-line:
* denis walker
> 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.
As I clarified above, these objects are in my view *not* uniform, as
they have distinct netname, descr and country attributes (possibly
others I missed too, I only skimmed through them quickly).
The LIR in question clearly has a policy of publishing the street
address of each assignee in the descr attribute. That is totally fine,
and will continue to be totally fine after 2023-04 is implemented, but
it makes their objects unsuitable for aggregation.
> 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.
It is important to note that the information you mention as "important"
here - the assignee's address - is (as you rightly point out) optional
to include. An LIR is under no obligation to publish this information,
and the inetnum object does not even contain an attribute dedicated to
it.
(While the organisation object has mandatory org-name and address
attributes, the org attribute is optional in inetnum objects.)
Thus the LIR in question already has a 'short cut' option available to
them, should they feel managing the assignees' address information in
the RIPE database is too burdensome - they can simply chose to not
include that information in the first place.
I want to emphasise that this policy proposal does not grant them this
option, it is already there today.
> 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.
Yes, just as in IPv6, aggregated objects can span gaps. This is
essential, as the primary use case targeted by AGGREGATED-BY-LIR is
automated assignment pools with a high churn rate (e.g., a dynamic DHCP
pool).
In such environments, the .1, .2 and .3 addresses might be assigned
before .2 might get de-assigned again - all within seconds, with no
operator involvement. We believe it is not necessary to reflect this
high level of granularity and rapid churn rate in the RIPE database.
> The assignments are all randomly sized. Which is why you have dropped
> the inet6num assignment-size attribute for inetnum objects. So if I
> amgetting abuse from one specific IP address what should I do? I have
> noidea 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.
My personal recommendation would be to block the specific IP address
you are receiving abusive traffic from and send a complaint to the
abuse-c for the inetnum in question.
Note that this is not really much different than what you have to do
today for abuse coming from customer assignments that are «registered
as part of the service provider's internal infrastructure», cf. ripe-
708 section 6.2. That said, AGGREGATED-BY-LIR would here have made it
clear that the abusive address is indeed assigned to a downstream
customer and is not part of the service provider's internal
infrastructure.
Tore
1 year, 6 months