January 2024 - address-policy-wg

2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Angela Dall'Ara 13 Feb '24

13 Feb '24

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

20 53

RIPE Code of Conduct and discussion on this list
by Leo Vegoda 10 Feb '24

10 Feb '24

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

5 4

Update on AS Number Assignments - Transitioning to Policy Compliance
by Marco Schmidt 26 Jan '24

26 Jan '24

Dear colleagues, During the RIPE 87 Address Policy working group session yesterday, I presented the topic of AS Number assignments, specifically addressing a policy in place since 2010. According to this policy, assignments should be made from an undifferentiated 32-bit AS Number allocation pool. https://www.ripe.net/publications/docs/ripe-679#ASnumbers Before this policy became active in 2010, the Address Policy WG recognized that many providers were not ready to exclusively work with 32-bit ASNs, mostly due to technical constraints. A verbal consensus in 2009 suggested that the RIPE NCC would temporarily continue using two pools of 16-bit and 32-bit AS Numbers. The plan was to attempt to extend the global policy by 12 months, but this effort was never undertaken. To date, the RIPE NCC remains the only Regional Internet Registry (RIR) employing this temporary approach. Observing that other RIRs have successfully issued AS Numbers from an undifferentiated pool for many years without technical challenges for operators, the RIPE NCC plans to phase out the current temporary approach. The intention is to align with the policy and issue AS Numbers accordingly. No objections were raised during the working group session. However, for transparency, we want to inform working group members who couldn't attend the RIPE meeting. The presentation can be viewed here: https://youtu.be/Zoq4PpqlaK4?t=1797 Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

2 3

.cz says bye-bye to IPv4
by Hank Nussbacher 24 Jan '24

24 Jan '24

https://konecipv4.cz/en/?is=e583f1196868df2304ff1140184b103346ee70b72851338… Regards, Hank

3 2

New on RIPE Labs: 10 Years of Legacy Policy
by Alun Davies 18 Jan '24

18 Jan '24

Dear colleagues, Ten years after the publication of 'RIPE NCC Services to Legacy Internet Resource Holders', we take a look at what's changed through a decade of implementing the RIPE legacy policy: https://labs.ripe.net/author/xavier/10-years-of-legacy-policy/ Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

2023-04 Review Phase further extended (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Angela Dall'Ara 18 Jan '24

18 Jan '24

Dear colleagues, The Address Policy WG Co-Chairs decided to extend by four more weeks the Review Phase for policy proposal 2023-04, “Add AGGREGATED-BY-LIR status for IPv4 PA assignments”. As per the RIPE Policy Development Process (PDP), the purpose of this Review Phase extension is to continue discussing 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. If you support the proposal, please indicate that support with a simple message to the mailing list. If you have objections or would like a change, please provide that feedback to the mailing list. 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 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 15 February 2024. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

@EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Kessler, Emmanuel 18 Jan '24

18 Jan '24

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 0

@EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Kessler, Emmanuel 17 Jan '24

17 Jan '24

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

2 1

@EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Kessler, Emmanuel 16 Jan '24

16 Jan '24

Hello, Tore Thanks for your message, I dare keep my message in the loop as there is for us a fundamental point here, I take note of yours, and may understand your wish to advance in the debate… However,… excluding this matter from the discussion should still depend on the certainty that there are no consequences on the way the data will be processed… …As I read the various inputs, I observe that the below statement (“no impact on end user data available”) and the relevancy of still discussing this point (or not), is not a matter of consensus in the group… some of our investigators, assessing the proposal, also observe a risk of future losses of information that are highly considered on EU side, to be honest… I remember that the loss of granularity was also acknowledged by another member of the group (who seemed to consider it as a collateral damage), in the chat I had during the latest RIPE session on November Considering the challenges for companies on processing IPV4, any simplification will damage identification effort. in the content your quote below, a possible option is mentioned about a separate policy proposal to clarify the internal aggregation processes at company level,… so as to ensure a right process, achieving this one would then ideally be a pre-condition before considering the current one we discuss. from our views, we need to check precisely the extend of the reality of “no impact on the end user data available” as it will fully condition our views on the measure…and could have a real impact on the way to grant security matters for citizens. Here a fair debate with all, using the necessary time, would really help, so as to fully clarify it.. in the past, on various occasion, new measures have been taken in various international groups,…identification capacities got weakened and we observed increasingly more obstacles (identification gaps) in our investigation, but it was then too late, once the measure implemented, …and what disappears is by definition harder to precisely measure and fully prove,…!! it does not mean the damage does not exist. Thanks for your understanding of my position, as the matter also interests various services and authorities at EU level (Law enforcement, Justice, and also digital matters) Best regards Emmanuel Kessler Europol From: Tore Anderson <tore(a)fud.no> Sent: 15 January 2024 12:08 To: Kessler, Emmanuel <Emmanuel.Kessler(a)europol.europa.eu> Cc: Šileris, Edvardas <Edvardas.Sileris(a)europol.europa.eu>; 'BAUER-BULST Cathrin' <Cathrin.BAUER-BULST(a)ec.europa.eu>; Azofra Martínez, Álvaro <Alvaro.Azofra-Martinez(a)europol.europa.eu>; Frank Breedijk <f.breedijk(a)divd.nl>; Maria Stafyla <mstafyla(a)ripe.net>; Jeroen Lauwers <jlauwers(a)a2b-internet.com> 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: tore(a)fud.no<mailto:tore@fud.no> Hello Emmanuel, I removed the AP-WG mailing list from the CC list here, because the Working Group chairs have declared the subject of end user contact details as being out of scope for this proposal. The chairs state: «It should therefore be clear that 2023-04 does not in fact change anything regarding how end-user details will actually be registered in PA Assignments» Please see: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2024-January/0139… We hope you will take this into consideration as you continue your evaluation of this policy proposal. Best regards, Tore & Jeroen On 15/01/24 11:31, Kessler, Emmanuel 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

1 0

2023-04 Discussion scope
by Alex Le Heux 12 Jan '24

12 Jan '24

Dear Working Group, During the discussion about AGGREGATED-BY-LIR status for IPv4 PA assignments the argument has been raised that this proposal would substantially change the registration requirements for end-user assignments in the RIPE DB and the discussion has been going around in circles ever since. We would like to point out the following: From the RIPE NCC Impact Analysis: [...] Acceptance of this proposal will not change the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this will remain their decision. [...] As well as: It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time. In its impact analysis the RIPE NCC has indicated that this proposal does not change this interpretation. It should therefore be clear that 2023-04 does not in fact change anything regarding how end-user details will actually be registered in PA Assignments. However, is has been argued that this interpretation is wrong and that PA Assignments in the RIPE DB must include the actual end-user details. And even though this is out of scope for the 2023-04 discussion, it is still something that is worth resolving. As changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects, we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one. Kind regards, Alex Le Heux, for the Address Policy WG co-chairs

3 2

Reducing IXP IPv4 assignment default size to a /26
by Viacheslav Adamanov 11 Jan '24

11 Jan '24

Dear community, The problem with ipv4 network speculation for IXP is exaggerated. RIPE NCC forbids transferring this networks to another company. Have there been cases of transmission of such networks? Kind regards, Viacheslav Adamanov. IXP Mesh Ukraine, Mariupol

3 2

Extend Review Phase for 2023-04 - "Add AGGREGATED-BY-LIR status for IPv4 PA assignments"
by Leo Vegoda 10 Jan '24

10 Jan '24

Dear colleagues, There's still an active discussion on 2023-04 - "Add AGGREGATED-BY-LIR status for IPv4 PA assignments". We'll extend the Review Phase until 18 January 2024. You can find the policy proposal, the draft RIPE document, and the RIPE NCC's Impact Analysis here: https://www.ripe.net/participate/policies/proposals/2023-04 The RIPE NCC will update the proposal web page with the new dates soon. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

2 1

[Moderated]
by unknown＠example.com 09 Jan '24

09 Jan '24

X-RIPE-Signature: 90bd07b9269f470e2dd51a8ff1b5290217985e0b4ca471fb5aefa22def383bd3 X-RIPE-Spam-Level: / X-RIPE-Spam-Report: Spam Total Points: -0.2 points pts rule name description ---- ---------------------- ------------------------------------ 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.0 T_SCC_BODY_TEXT_LINE No description available. Subject: Re: [address-policy-wg] Extend Review Phase for 2023-04 - "Add AGGREGATED-BY-LIR status for IPv4 PA assignments" X-BeenThere: address-policy-wg(a)ripe.net X-Mailman-Version: 2.1.26 Precedence: list List-Id: Developing policies relating to the management and registration of Internet addresses and routing identifiers <address-policy-wg.ripe.net> List-Unsubscribe: <https://lists.ripe.net/mailman/options/address-policy-wg>, <mailto:address-policy-wg-request@ripe.net?subject=unsubscribe> List-Archive: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/> List-Post: <mailto:address-policy-wg@ripe.net> List-Help: <mailto:address-policy-wg-request@ripe.net?subject=help> List-Subscribe: <https://lists.ripe.net/mailman/listinfo/address-policy-wg>, <mailto:address-policy-wg-request@ripe.net?subject=subscribe> X-List-Received-Date: Wed, 10 Jan 2024 09:02:37 -0000 On Thu, 21 Dec 2023, Leo Vegoda wrote: > Dear colleagues, > > There's still an active discussion on 2023-04 - "Add AGGREGATED-BY-LIR > status for IPv4 PA assignments". We'll extend the Review Phase until > 18 January 2024. > > You can find the policy proposal, the draft RIPE document, and the > RIPE NCC's Impact Analysis here: > https://www.ripe.net/participate/policies/proposals/2023-04 > > The RIPE NCC will update the proposal web page with the new dates soon. > > Kind regards, > > Leo Vegoda, for the Address Policy WG co-chairs > > -- I support this proposal, so +1 from me -- Thor-Henrik Kvandahl

1 0

[Moderated]
by unknown＠example.com 09 Jan '24

09 Jan '24

1 0

[Moderated]
by unknown＠example.com 09 Jan '24

09 Jan '24

1 0

[Moderated]
by unknown＠example.com 09 Jan '24

09 Jan '24

1 0

[Moderated]
by unknown＠example.com 09 Jan '24

09 Jan '24

1 0

[Moderated]
by unknown＠example.com 09 Jan '24

09 Jan '24

1 0

[Moderated]
by unknown＠example.com 09 Jan '24

09 Jan '24

1 0

Minutes of the RIPE87 Rome meeting
by Erik Bais 02 Jan '24

02 Jan '24

Dear WG, I like to wish you all a very healthy and successful 2024, on behalf of myself and the other AP-WG chairs. We’ve received the minutes of the RIPE87 meeting and the RIPE NCC was so kind to publish them already for your review online. And I like to thank the RIPE NCC in creating the minutes for us. Please review the minutes and provide feedback if you think there is something missing or incorrect. https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-87-addre… Regards, Erik Bais On behalf of the AP-WG Chairs.

1 0