- address-policy-wg - mailman.ripe.net

Co-chair selection (was: Fwd: [ripe-list] The RIPE Chair Team Reports - April 2024)
by Leo Vegoda 17 Apr '24

17 Apr '24

Hi, Mirjam's update notes that this and other working groups are running selections for co-chairs. If you are interested in becoming a co-chair of this or another working group, please take a look at Mirjam's blog post and the linked resources. They include a job description and training resources. My earlier announcement is archived here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2024-March/014008… If you are considering standing for selection as co-chair, now or in the future, you're welcome to contact me directly. I'll be posting the list of candidates on 19 April. Kind regards, Leo ---------- Forwarded message --------- From: Mirjam Kuehne <mir(a)zu-hause.nl> Date: Wed, 17 Apr 2024 at 03:47 Subject: [ripe-list] The RIPE Chair Team Reports - April 2024 To: RIPE List <ripe-list(a)ripe.net> Dear colleagues, With the RIPE 88 Meeting approaching fast, and plenty of developments in our community, we report on some of the developments in this new article on RIPE Labs: https://labs.ripe.net/author/mirjam_kuhne/the-ripe-chair-team-reports-april… Kind regards, Mirjam Kühne RIPE Chair -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ripe-list

1 0

2023-04 Proposal Accepted (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Angela Dall'ara 16 Apr '24

16 Apr '24

Dear colleagues, Consensus has been reached on 2023-04 "Add AGGREGATED-BY-LIR status for IPv4 PA assignments". This proposal aimed at introducing the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. You can find the full proposal at: https://www.ripe.net/membership/policies/proposals/2023-04/ The new RIPE Document is called ripe-822 and is available at: https://www.ripe.net/publications/docs/ripe-822/ We estimate that this proposal will take around two months to fully implement. We will send another announcement once the implementation is complete and the new procedures are in place. Thanks to everyone who provided input. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

3 3

Consensus – 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments
by Leo Vegoda 15 Apr '24

15 Apr '24

Dear Working Group, No new objections were raised during the Concluding (Last Call) phase. The community has achieved a consensus. The RIPE NCC can proceed with implementation. Our thanks to everyone who contributed to this discussion. In particular, we'd like to thank Tore and Jeroen for the calm professionalism they demonstrated. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

1 0

Proposal: Limiting Membership and Allocating IPv4 Subnets in Less Developed Countries
by AlbaHost SH.P.K 10 Apr '24

10 Apr '24

Limiting Membership and Allocating IPv4 Subnets in Less Developed Countries. Background: The Regional Internet Registry (RIR) for Europe, the Middle East, and parts of Central Asia, RIPE NCC, faces challenges in managing the allocation of IPv4 addresses due to exhaustion of available IPv4 address space globally. This proposal aims to address these challenges by implementing limits on membership per entity and providing special considerations for less developed countries where IPv6 adoption is still low. Proposal Details: 1. Limit Membership per Entity: - RIPE NCC will implement a policy limiting the number of memberships per entity to a maximum of two. - This measure aims to prevent hoarding of IPv4 address space by a few entities, ensuring fair distribution and availability of addresses to a wider range of organizations. 2. Allocation of IPv4 Subnets in Less Developed Countries: - Recognizing the challenges faced by less developed countries where IPv6 adoption is still minimal, RIPE NCC will allocate more than one /24 subnet to eligible entities in such regions. - This special consideration aims to support the growth and development of internet infrastructure in these countries, allowing them to meet their addressing needs while transitioning to IPv6 gradually. Rationale: 1. Fair Distribution: Limiting membership per entity ensures that a small number of organizations do not monopolize the available IPv4 address space, promoting fair distribution among a broader range of stakeholders. 2. Encouraging IPv6 Adoption: While IPv4 addresses are increasingly scarce, encouraging IPv6 adoption remains a priority. However, in less developed countries where IPv6 infrastructure is till underdeveloped, providing additional IPv4 address space can help sustain internet connectivity and services while facilitating a smoother transition to IPv6 in the long term. 3. Balanced Approach: By combining limits on membership with special considerations for less developed countries, RIPE NCC aims to strike a balance between managing IPv4 scarcity effectively and supporting the needs of regions where internet infrastructure development may lag behind. Conclusion: This proposal seeks to address the challenges of IPv4 address exhaustion by implementing limits on membership per entity and providing additional IPv4 address space to less developed countries. By promoting fair distribution and supporting regions with limited IPv6 adoption, RIPE NCC can better manage its resources while fostering global internet connectivity and development. This proposal invites feedback and discussion from the RIPE community to refine and implement effective policies for the equitable distribution of IPv4 addresses in the region. Kind Regards. -- *Sinqerisht / Sincerely,* AlbaHost [image: Logo] <https://www.albahost.net/> Albanian Hosting SH.P.K. Besim Beka p.n. 50000 Gjakovë, Kosovë. NIPT/VAT ID: 811442657 T: +386900501502 E: info(a)albahost.net W*: *wWw.AlbaHost.Net <http://www.albahost.net/> [image: Facebook icon] <https://www.facebook.com/albanianhosting> [image: Twitter icon] <https://twitter.com/albahost> [image: Instagram icon] <https://www.instagram.com/albahost_vpn/> [image: Banner] Përmbajtja e këtij emaili është konfidenciale dhe ka për qëllim marrësin e specifikuar vetëm në mesazh. Ndalohet rreptësisht shpërndarja e ndonjë pjese të këtij mesazhi me ndonjë palë të tretë, pa pëlqimin me shkrim të dërguesit. Nëse e keni marrë këtë mesazh gabimisht, ju lutemi përgjigjuni këtij mesazhi dhe ndiqni me fshirjen e tij, në mënyrë që të sigurohemi që një gabim i tillë të mos ndodhë në të ardhmen. The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

4 5

@EXT: FW: Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by Kessler, Emmanuel 08 Apr '24

08 Apr '24

Dear All, I would have some comments about the previous points that mentions Europol Thanks for your cooperation spirit Regards Emmanuel Kessler -----Original Message----- From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> On Behalf Of Kai 'wusel' Siering via address-policy-wg Sent: vendredi 5 avril 2024 21:41 To: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status Moin, am 05.04.24 um 16:51 schrieb denis walker: > I used to wonder why no one > would even talk about bringing the RIPE Database into the modern > world. Because this is address-policy (»The Address Policy Working Group develops policies relating to the management and registration of Internet number resources.«), not database (»The Database Working Group deals […]«). > Europol has expressed serious concerns about these changes. Europol has the means to challenge the maintainer of the address space for more information on individual usage; there is no real thread to Europol's operation by the change, it might just become less convenient to get the wanted information. --> Sorry, but reading this, I observe that you may indeed have only a fuzzy/limited idea of what Europol does, and the impact on LE operations.. As knowing the scope of Europol and digital investigation (we work here), we repeat that the matter is not only being less convenient. The matter is the loss of opportunities of identification that will vanish for investigators... > If someone had informed them earlier > of the changes being considered that may affect them, Well, this is happening all in the open. IF Europol is depending so greatly on the RIPE DB, they SHOULD be following the PDP already for years and years and voiced their concerns more timely. --> the matter is not just Europol, but the impact on investigations of LE services....Europol has been regularly well active in various working groups of RIPE... Please consider that capacities of investigators are impacted by a large number of negotiation processes : at E-governance level (ICANN, RIPE,..), UN treaties, Council of Europe conventions, numerous EU legislations (Nis2, E-evidence package, DSA,...), national levels ones... (and I may forget some..?!).... linked with judicial cooperation frameworks, companies regulations, cybersecurity actors, technological standards in permanent evolution, .... The number of working groups, regulations, proposals, legal acts, is the most consequent...it is a "jungle" of processes that have to be covered,...you can believe me... in spite of the efforts of our committed people, we are unfortunately not omniscient an always present everywhere....(nobody is...!). As in all organisations, capacities are not infinite and we have sometimes to prioritize those we have, under emergencies and the various agendas.. ...but whatever the raised questions, THE relevant question is overall that a joint work in open spirit is THE best way...beyond considering the only question of a seat gap at a moment... --> The matter should remain in the end, which impact (positive/negative...) ? when all know new popping processes from the beginning, it allows to formalize swiftly a full knowledge about impact, and prevent 2 undesirable ends that are : wasting time on a proposal that should be given up/ or persisting on the difficult adoption of a measure that will bring damage on victims protection... we can do great job to secure digital space, (just see Lockbit and the latest operations against ransomwares : https://www.europol.europa.eu/media-press/newsroom?q=cyber ) including protecting private sector and companies that are essential for business and the economic health of our countries, but if we lose the access to data, it means less operational achievements/ and criminals being more in capacity to target companies and peoples, who still "pay the bill" of crimes... > proceed with all haste to No haste visible at all; this is about 2023-04 — we already are in 2024-04. Regards, -kai -- 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

4 3

Interpretation of IPv6 PI Policy
by Tobias Fiebig 22 Mar '24

22 Mar '24

Dear colleagues, I am currently handling an end-user request for, initially, a /47 PI (now, due to the NCC stating that a /47 is, generally, not possible, even if routing reasons exist, a /48). During that discussion the NCC shared further details concerning the interpretation of RIPE-738, which I believe may be useful information to share, also in the context of possible ways to improve the address policy for the NCC region. Specifically: - The NCC reads "The minimum size of the assignment is a /48." as the minimum pertaining to the minimal value of the prefix size and not 'the minimum total size of an assignment in the number of IP addresses.' However, it deems it possible that multiple separate /48 can be assigned. => This means that a revision of the IPv6 policy will have to also clarify this point, i.e., by rephrasing it to 'the longest prefix size for an assignment is a /48' - The NCC reads "Assignments larger than a /48 (shorter prefix) or additional assignments exceeding a total of a /48 must be based on address usage or because different routing requirements exist for additional assignments." to mean that larger assignments can only be made based on address usage. Routing requirements can only justify multiple /48. => If this should be clarified, removing the text saying 'for additional assignments.' should suffice. - The NCC reads the reference to Section 5.4.2 in 'The considerations of "5.4.2. Assignments shorter than a /48 to a single End-Site" must be followed if needed.' to imply authoritative language codifying the assignment to a single end-site, and not a reference to a different section requiring the analogous application of the concepts in this section to a PI assignment. => A way to clarify that might be to only reference sections by, e.g., "Section 5.4.2", to ensure that the referenced title of a section is not understood as authoritative language. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias(a)fiebig.nl

1 0

2023-04 Last Call for Comments (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Karen Hung 11 Mar '24

11 Mar '24

Dear colleagues, Proposal 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 PA assignments " is now in Concluding Phase. The goal of this proposal was to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. The WG co-chairs have declared that rough consensus has been reached and the proposal will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of this four-week Concluding Phase is to give an opportunity to present well-justified objections for those who missed the previous two phases and wish to oppose the proposal. Any objection must be made before 9 April 2024 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the WG co-chairs for final consensus. You can find the full proposal at: https://www.ripe.net/membership/policies/proposals/2023-04/ Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net> before 9 April 2024. Kind regards, Karen Hung On behalf of Policy Officer RIPE NCC

1 0

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

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

13 Feb '24

Dear partners and chairs of the Address policy working group of RIPE, Please find more clarifications from EUROPOL and Law enforcement agencies, about how the 2023-04 measure would impact the capacity of investigators in identifying cybercriminals. First, I would inform you that we had to open a large consultation with various European services and EU authorities, cybersecurity authorities, that indeed showed an interest on the measure. It has taken some time to collect inputs, …of course. While we worked on providing concrete inputs as much as possible, we coped with some limits, as we cannot share some information that are under the secrecy of law or judicial cases, we cannot share information in public/open access that could in the end, inform cybercriminals on how countering our activities,…. and as a last point, omniscient statistics do not exist anywhere… Thank you for considering it. Having said that , lets jump with the points... In our assessment, the 2023-04 measure would impact at 2 levels. The first level of impact is that it would complicate the process to access the information. Some European services have confirmed they do use on daily basis, the RIPE data basis to get directly the end user information. It is an easy access for them. They also use support-tools whose results would be weakened through the new configuration. At national level, capacities would be preserved in some extend for some services, but would it would become heavier, as court order would become systematic. At International level, identification of IPs would become far more complicated on digital investigations (from some general assessment, about 80% of investigations have a digital dimension now !),…and especially on cyber cases.... Most of investigations rely on a swift IP identification, that may involve external LIRs and various ISPs that regularly give an IP to others.. An European service gave me the example of a Child sexual abuse material case : an investigator would have to send a mutual legal agreement request to a LIR, to receive as an answer, 4-6 months later, that the IP is handled by an ISP (sometimes in the same country as the investigator)..we will here lose time, with less capacity in the end to identify victims, accomplices, perpetrators, (because of some data retention limits in many countries)… on this situation, it would be for the best interest of all parties if for example, a measure would ensure that, "in any case, LIRs and ISPs that transfer/give any IP or IP block to another legal entity, must declare this information to the RIPE database". It would also become more time consuming in getting the identification, meaning less cases processed by investigators. Judicial proceeding has got more and more complex for many reasons, and the new measure would not help the daily job. The capacity of investigation services is asymmetric with the large volumes of ransomwares attacks, online scams, child sexual abuses materials sharing,… In the end, the new measure could foster by design, a “bullet proof hosting” like-situation. Here is a point to be also considered. RIPE covers not only the European Union, but also other countries outside the EU. The cooperation level with these countries may vary in a large extend and across time. With some of them, getting a swift answer on the sole court order is not an option, and it may be the most uncertain/long with a mutual legal agreement request. Here again, it would loudly impact us,...as the location of some of these countries are regularly used in a consequent number cyberattacks. Some will say that criminals have not waited for anybody to use bullet proof hosting capacities,…yes,….but we consider that a measure that may hide their mistakes, clearly does not help us, ....but them…. International cooperation relies on processes, that are still largely humanly tailored by legal authorities (not automatized), linked with sovereignty, respect of fundamental laws and rights, safeguards. …I believe we all respect that,… but it means consequences on the way the global flow of judicial cooperation may work and some balance is needed in maintaining some efficiency in the processes. The second level of impact would be linked with the quality of the data hosted in an aggregated environment. “Aggregating multiple IPv4 End User assignments that have consistent contact information and purpose into a single database object” : which impact on cross-matching the information of IPV4…??? IPV4 identification is far more challenging than IPV6 one....the matter has become well identified... From our assessment, the measure would impact the granularity of the data, as already said. Through aggregating assignments, it will have as a consequence, the loss of various end users details, preventing cross-matching efforts by investigators, that are essential. While individual assignments offer specific and detailed information about each IP address's usage, aggregated data may obscure such details, potentially complicating investigations that rely on precise IP address information. In the end, the less detailed information will, either require additional steps or inquiries to ascertain the specifics of an IP address's usage, potentially delaying investigative processes….either identification may not be possible as it was previously… To give you an idea of the extend of impact, Lets’ take the example of the CGN-NAT matter. The mutualisation of IPV4 addresses, is here fully considered as a big challenge for investigation. EUROPOL has worked for long on that, especially on this CGN-NAT matter that raises a similar question as the 2023-4 proposal. various reports are publicly available online (IOCTA, or other publications) CGN-NAT configuration greatly helps criminals to get anonymous as the ISP cannot locate the subscriber. Numerous cases have been reported by investigators. Europol met this challenge in important operations, covering for example cases of traffic of arms, or child sexual exploitation (CSAM sharing forum with 62000 members, 10 children victims) in big cases, we may have to process hundreds of IPV4, sometimes thousands in the biggest ones : because of aggregation, we may lose some cross matching/identification opportunities that are essential to solve a case. As an example, on some big cases, the CGN use impacted up to 70% of identifications of perpetrators or accomplices. we observe that the 2023-4 proposal could generate a similar “fog” with the same extend of impact. The CGN-NAT is so hampering that in answer, some EU countries had to limit the number of subscribers per IP. As another point, the measure observe some inconsistencies in Registration Practices: it acknowledges that some LIRs already apply exceptions to the current policy, leading to inconsistencies in how IPv4 addresses are registered. This inconsistency can pose challenges for law enforcement in tracking and mapping IP addresses to specific users or activities, as the registration practices may not be uniform across different LIRs. However, standardisation should not mean further weaken the quality of data. The expected decreased granularity of the data would raise a question in the context of the EU NIS2 DIRECTIVE, that aims to provide an improved quality of the data available for cybersecurity/legal needs. NIS2 covers identification of DNS, but it would be paradox that while we are progressing on the identification of DNS, we may decrease on identification of IPs,… It is right that so far, EU regulatory efforts have focused on the DNS identification need rather than the IP one, as DNS matter was clearly identified as a urgent need, after the evolution linked with GDPR. the 2023-4 proposal would raise indeed a new concern... To our assessment, ensuring reliable registration requirements for end user contact information (providing the necessary information, without any drafting interpretation) remains here essential to prevent progressive anonymization/losses of data. The way, each ISP will aggregate its data, is a real and complex question, with huge potential impact on investigations. In deep analysis, we still consider that there is a risk of progressive anonymization of data of end users information, with the 2023-4 proposal... For these reasons, the 2023-4 proposal remains at EU level, a matter of concerns and question. As such, it could practically result in being a technical evolution hampering in practice the legal obligation (in many countries) for ISPs to identify end user subscriber information, ....as long as it cannot be proved that the previous identification granularity is maintained. I hope that these information will help you on better understanding our concern. we do understand the business need, however the support of private partners is essential for us on protecting people. Thanks for your cooperation Regards Emmanuel Kessler -----Original Message----- From: Leo Vegoda <leo(a)vegoda.org> Sent: 17 January 2024 18:01 To: Kessler, Emmanuel <Emmanuel.Kessler(a)europol.europa.eu> Cc: address-policy-wg(a)ripe.net; Šileris, Edvardas <Edvardas.Sileris(a)europol.europa.eu>; BAUER-BULST Cathrin <Cathrin.BAUER-BULST(a)ec.europa.eu>; Tore Anderson <tore(a)fud.no>; Azofra Martínez, Álvaro <Alvaro.Azofra-Martinez(a)europol.europa.eu>; Frank Breedijk <f.breedijk(a)divd.nl>; Maria Stafyla <mstafyla(a)ripe.net> Subject: Re: [address-policy-wg] @EXT: RE: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe. The external address that sent the message is: leo(a)vegoda.org Dear Emmanuel Kessler, It would help the co-chairs tremendously if your arguments gave some specific numbers or other details. We are aware of your concerns but phrases like "large potential impact" are vague. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs On Mon, 15 Jan 2024 at 02:32, Kessler, Emmanuel <Emmanuel.Kessler(a)europol.europa.eu> wrote: > > Dear all, > > we keep analysing the possible consequences of the measure on our LEA > capacity to identify IPV4 It takes time as it interests various EU official partners and Law enforcement services, ...thanks for your understanding. > > We still identify two issues in the measure > > - about the process to access to data : as ending the direct access at RIPE level, it will not ease the work for some investigators who uses it as a convenient tool, although accessing the data at LIR level still remains partly an option. > > - about the granularity of the data as aggregated, and we think there is here a very strong question, with a large potential impact. > > As you know, EUROPOL has worked for years on the CGN-NAT challenge on IPV4, advocating for limiting this mutualisation of IPV4 addresses that regularly hampers investigation capacities. > we observe the aggregation measure as having a real negative impact on the granularity of the answers that will be collected. > it is also linked with internal practices in the companies that remain various...we know that. > Situation with IPV4 is different than the one with IPV6. > Consequently, we keep all our reserve about the proposal that raises concerns amongst many colleagues. > > We fully understand the code of conduct in RIPE debate, and still appreciate good discussion with constructive and realistic people... > However, getting all the truth of the situation requires contradictory debate that can progress through the exchange of still more detailed explanations,.... > As the matter is of real importance, we hope that the measure would not be adopted without this clarification with all opinions/arguments around the table,... > > We would be also in favour of postponing the deadline of the debate, to take time to exchange and check all the explanations as necessary. > > Thank you for your exchange and cooperation > > Regards > > Emmanuel Kessler > European Cybercrime centre > EUROPOL > > -----Original Message----- > From: denis walker <ripedenis(a)gmail.com> > Sent: 11 January 2024 03:21 > To: Tore Anderson <tore(a)fud.no>; Maria Stafyla <mstafyla(a)ripe.net> > Cc: Jan Ingvoldstad <frettled(a)gmail.com>; address-policy-wg(a)ripe.net; > Frank Breedijk <f.breedijk(a)divd.nl>; Kessler, Emmanuel > <Emmanuel.Kessler(a)europol.europa.eu> > Subject: Re: [address-policy-wg] 2023-04 Review Phase (Add > AGGREGATED-BY-LIR status for IPv4 PA assignments) > > > > This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe. > The external address that sent the message is: denis1(a)gmail.com > > > Hi Tore and others > > On Wed, 10 Jan 2024 at 13:02, Tore Anderson <tore(a)fud.no> wrote: > > > > Hello again Jan, > > > > On 10/01/24 11:25, Jan Ingvoldstad wrote: > > > Basically, any public company register would be illegal according > > > to the interpretation you lean on here. > > > > Public company registries also need a lawful basis for processing. > > The Norwegian public company registry, for example, uses the lawful > > basis «exercise of official authority» – Article 6(1)(e) GDPR – as > > its lawful basis, see https://www.brreg.no/en/privacy-statement/. I > > would assume that to be the case in most other countries as well. > > > > (Most) LIRs are not official authorities, so unlike public company > > registries LIRs cannot use this lawful basis for publishing PII in > > the RIPE Database. > > As I explained in the previous email, you only quoted half the GDPR > condition here. It actually says, > (e) processing is necessary for the performance of a task carried out > in the public interest or in the exercise of official authority vested > in the controller; As I also pointed out, during the discussion of > 2022-01 (privacy) > https://www.ripe.net/ripe/mail/archives/db-wg/2022-October/007630.html > it was accepted that there is a 'public interest' basis here. > > > > > In any case, all of this is rather off-topic. 2023-04 does not > > change the legal obligations on the LIRs relating to the publication > > of End User contact information, > > It does not matter how many times you repeat this, it is still NOT true. You remove the line When an End User has a network using public address space this must be registered separately with the contact details of the End User. > Removing this line DOES change the LIR's obligations relating to the publication of End User contact information. No matter how many times you repeat this false information I will repeat the reply. > > > nor does it change the RIPE Database Terms and > > Conditions. If you want to publish PII in the RIPE Database, you > > need a lawful basis. That's true today, and that will continue to be > > true if > > 2023-04 passes. > > > > > > > Or you could take the other stance and stop publishing *any* > > > contact details regarding an object, because you cannot know > > > whether the information is personal data or not. > > > > Exactly. LIRs may (but are not required to) chose this approach > > already *today*. This is a common and long-standing practice which > > the RIPE NCC has repeatedly clarified as compliant with today's policy. > > This is one of your biggest false statements. The ONLY person repeatedly saying this is YOU. Let's do a fact check here. You asked a question to the RIPE NCC about publishing End User contact details in an assignment object. The RIPE NCC PDO, policy officer Angela, consulted with registration services and made a reply. She confirmed, once, it is compliant with current policy to not publish the End User contact details. I have disputed that by quoting the famous line (which you want to remove): > 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' > I have provided a mountain of supporting evidence that the RIPE NCC's interpretation of this statement is incorrect. Angela's one time answer was incorrect. Since then the RIPE NCC has said exactly NOTHING. No one from registration services has come to this list and expanded, qualified or explained their one time response. But since then you have endlessly repeated that one time response from the RIPE NCC. You have claimed so many times that the RIPE NCC has repeated this many times. That is NOT true. Please STOP saying what is NOT TRUE. It was said once by the RIPE NCC and then disputed. You are still hiding behind this false premise. > > > > > It will continue to be compliant with the policy after 2023-04 > > passes, as well. Thus, 2023-04 effects no change on the LIRs' > > obligations in this regard. > > It has a massive change on the LIR's obligations, by removing a line of text from the current policy, which you have admitted yourself does not need to be removed for your aggregation proposal. You keep repeating that this change has no real, practical impact, so don't remove it. Then we can all get on with our lives. > > > > > > > > I think that because the WG discussion has almost exclusively > > > revolved around this alleged changing of policy requirements to > > > publish End User contact information (which may or may not be > > > PII), it is easy to lose track of what this proposal is *actually* > > > all about. We are talking about two different things: > > > > > > 1) The actual intention behind the proposal: Making it possible to > > > aggregate multiple IPv4 End User assignments that have consistent > > > contact information and purpose into a single database object. > > > This is not possible today, and that is what we want to make that > > > possible, in the same way it is already possible in IPv6. > > Then limit the proposal to exactly this!!! > > > > > > > 2) The *alleged* change to what kind of End User contact > > > information is required to be published in the RIPE database. We > > > have never had any intention of changing this in any way, and the > > > Impact Analysis and other statements from the RIPE NCC confirm > > > that the proposal does not change it either. > > This is total madness. You keep saying you have no intention of changing anything else. You keep saying the wording change actually changes nothing in practice. Some other people don't agree with you. > Just don't change wording that you claim changes NOTHING and has nothing to do with aggregation and everyone is happy. The fact that you are pushing so hard to make this wording change, you refuse to back down or compromise, you insist on changing wording that changes nothing and has nothing to do with aggregation...proves that you don't believe that yourself. The fact is, I suspect that this is the real change you want. You want to drop the current policy requirement to define assignments with End User contacts. It is the aggregation that is the side issue here. There is no other explanation for why you are insisting so strongly on changing wording that changes nothing. > > > > > > > In short: 1) is an intentional and desired change from today, > > > while 2) is *not* a change from today – intentionally so. > > > > > > This (regarding item 2) is simply not true. Any change in text *is > > > a change*. > > > > We are not making the claim that the policy text does not change. > > That it clearly does – in order to achieve the desired change > > described in item 1 above. > > > > We are however claiming that the *meanings* of the old and the new > > policy texts are exactly the same, with regards to how they > > translate into operational procedures and requirements for the > > publication of End User contact information (item 2). > > You must think that WE are the crazy people. You cannot remove the line 'When an End User has a network using public address space this must be registered separately with the contact details of the End User.' > and then say the meaning is exactly the same. I know it is a common tactic now, especially in politics, to keep repeating mis-information that makes no sense over and over again, refusing to listen to objections, until a mass of people start to believe your mis-information. I am one of those free thinkers who doesn't go with the masses. I will keep pointing out the mis-information here. > > > > > As the RIPE NCC writes in the Impact Analysis (emphasis added): > > > > «Acceptance of this proposal **will not change** the fact that > > the RIPE NCC cannot enforce which contact details members add to > > their > > IPv4 PA assignments in the RIPE Database; this **will remain** their > > decision.» > > > > So, once again: which End User contact details LIRs publish (if any) > > is their decision today, and it will be continue to be their > > decision if > > 2023-04 passes. Hence, 2023-04 does not effect any change in this regard. > > This really does make me cry. The wording in the IA is poor. You have applied an interpretation to this which I do not believe is what was meant. Then the RIPE NCC legal team has remained silent. So I am asking the RIPE NCC legal team to clearly explain what they meant by this wording. Is the legal team actually saying here that the RIPE NCC cannot enforce RIPE policy? The current policy is clear on the 'type' > of contact details. That 'line' says an assignment MUST include an End User contact. It is true the policy does not say the LIR must add Person A as the contact rather than Person B. So in this context the RIPE NCC cannot enforce which (Person A or B) contact details members add to their IPv4 PA assignments. The choice of Person A or Person B will remain the LIR's decision. But when the policy says an assignment MUST include 'an' End User contact, the RIPE NCC can and should enforce that 'a' contact for the End User is added. So I ask the legal team, which interpretation did you mean? > > > > > > > > So maybe we could discuss 1) instead of 2) going forward? :-) > > > > > > I have no problem with 1), as already stated. > > > > We're happy to hear that! > > > > > > > I do agree with you that this is distracting from the proper meat > > > of your proposal. Which is why I suggest that you drop this part of it. > > > Again, drop the part of the proposal that people have a beef with. > > > > > > Don't make the change that you claim is not a change. > > > > This «beef» is based on reading current policy to mean that which > > End User contact details LIRs publish in the database (if any) is > > *not* the LIRs' decision today. > > It is based on reading the current policy and understanding what a very clear sentence written in plain English means. > > > > > But the RIPE NCC has repeatedly clarified that that is simply not > > the > > case: it *is* the LIRs' decision today, and it will continue to be LIRs' > > decision should 2023-04 pass. > > You are doing it again. The RIPE NCC has said something ONCE and refused to clarify it ever since, despite it being contested. It is YOU who repeatedly claims something. > > > > > Given that, it is hard to see how we could possibly amend the > > proposal to change this particular point to an even lesser extent > > than what is already the case? > > Let me help you. Do NOT remove a sentence that has nothing to do with the stated goal of the proposal to aggregate assignments and that you claim does not change anything. > > cheers > denis > > > > > > > Tore & Jeroen > > > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > > change your subscription options, please visit: > > https://lists.ripe.net/mailman/listinfo/address-policy-wg > -- > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/address-policy-wg

1 0

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