From jlauwers at a2b-internet.com Wed Dec 13 19:14:29 2023 From: jlauwers at a2b-internet.com (Jeroen Lauwers) Date: Wed, 13 Dec 2023 18:14:29 +0000 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> Dear colleagues, Though we recognise that most of you are probably busy preparing for the upcoming holidays, we would like to ask you to share your opinion on proposal 2023-04. Remember that Policy Development Process requires any comments made during the Discussion phase must be repeated during the Review phase in order to count towards or against rough consensus, as your views can now take the RIPE NCC?s Impact Analysis into account. Here are some questions for the WG to get the discussion started: Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way? Does 2023-04 address this use case well in its current form, or could you think of any potential improvements? We hope you will find the time to let your voice be heard! The Policy Development Process requires the proposers to adequately address any suggestions for changes or objections to the proposal in each phase, which we will do below. 1. Does 2023-04 change the contact registration requirements for assignments? The argument made is that the statement ?When an End User has a network using public address space this must be registered separately with the contact details of the End User? found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy), implicitly requires LIRs to register non-delegated/outsourced contact information for the End User in the RIPE database, not necessarily in the mandatory ?admin-c? or ?tech-c? attributes, but possibly in an optional attribute like ?descr?, ?org? or ?remarks?. Proposers? response: We do not believe so, for the following reasons, and keeping the current practice and policies in consideration: 1. The RIPE NCC does not consider that 2023-04 changes the contact registration requirements in any way[1][2][3]. Absent any (rough) consensus in the Working Group to the contrary, we defer to the RIPE NCC?s judgement on this point. 2. The practice of creating assignments with all contact information delegated is already widespread. If this was a policy violation made possible due to the RIPE NCC implementing RIPE policy incorrectly, we would have expected the community to take action to correct this situation. However, no such policy proposal has been put forward by the community. 3. Outsourcing and delegation of contact information is a common practice across many industries, including in networking and information technology. There is no policy language that explicitly prohibits this for IPv4 assignments. Absent that, we believe any implicit prohibition found ?between the lines? is essentially ?void for vagueness?[4]. 4. An obligation to publish the End User?s contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User?s contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence). 5. The policy?s stated goal of registering assignments is ?to ensure uniqueness and to provide information for Internet troubleshooting at all levels?[7]. Requiring LIRs to publish the contact information of End Users who often will not have any knowledge or capability to aid with troubleshooting does work towards this attaining goal. On the contrary, delegating the contact information to the LIR/ISP may well be the only way to attain this goal. [1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html [2] https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html [4] https://www.law.cornell.edu/wex/void_for_vagueness [5] https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms [6] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e1888-1-1 [7] https://www.ripe.net/publications/docs/ripe-804#3 2. The ?assignment-size? attribute should be a CIDR prefix length Leaving it undefined could result in some LIRs using it to represent an IPv4 address count, while others would use it to represent a CIDR prefix length. Proposers? response: We agree ?assignment-size? should be a CIDR prefix length. We understand that, if proposal 2023-04 would be accepted, the RIPE NCC could implement the ?assignment-size? attribute for IPv4 inetnum objects to be a CIDR prefix length, and document it as such. Therefore we do not believe it is necessary to spell this out explicitly in the policy document (it is not spelled out in the IPv6 policy document either). Thank you for your attention and enjoy your holidays! Best regards, Jeroen and Tore Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara > het volgende geschreven: Dear colleagues, Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA assignments?, is now in the Review Phase. The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. This proposal has been updated and it is now at version 2.0. The proposed policy text did not change, the only difference is that the section "Arguments opposing the proposal" includes a reference to the last round of discussion. The RIPE NCC has prepared an impact analysis on this proposal to support the community?s discussion. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2023-04 https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis And the draft document at: https://www.ripe.net/participate/policies/proposals/2023-04/draft As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue the discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg at ripe.net before 20 December 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-lists at sebastian-graf.at Wed Dec 13 19:39:50 2023 From: ripe-lists at sebastian-graf.at (Sebastian-Wilhelm Graf) Date: Wed, 13 Dec 2023 19:39:50 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> Message-ID: Dear Collegues! Looking at the impact analysis, the proposal and reviewing the arguments - i would like to agree with this proposal. In the best case scenario it may improve the accuracy of database entries. I also belive it will aid the goals of the registry because this way the usage of inetnums can be documented more clearly. Kind Regards On 12/13/23 19:14, Jeroen Lauwers wrote: > Dear colleagues, > > Though we recognise that most of you are probably busy preparing for > the upcoming holidays, we would like to ask you to share your opinion > on proposal 2023-04. Remember that Policy Development Process requires > any comments made during the Discussion phase must be repeated during > the Review phase in order to count towards or against rough consensus, > as your views can now take the RIPE NCC?s Impact Analysis into account. > > Here are some questions for the WG to get the discussion started: Do > you already use AGGREGATED-BY-LIR when registering IPv6 assignments? > Would you find it convenient and useful to be able to register IPv4 > assignments in the same way? Does 2023-04 address this use case well > in its current form, or could you think of any potential improvements? > > We hope you will find the time to let your voice be heard! > > The Policy Development Process requires the proposers to adequately > address any suggestions for changes or objections to the proposal in > each phase, which we will do below. > > > 1. Does 2023-04 change the contact registration requirements for > assignments? > > > The argument made is that the statement ?When an End User has a > network using public address space this must be registered separately > with the contact details of the End User?found in the current policy > (and removed by 2023-04 in order to bring the wording in line with > that of the IPv6 policy), implicitly requires LIRs to register > non-delegated/outsourced contact information for the End User in the > RIPE database, not necessarily in the mandatory ?admin-c? or ?tech-c? > attributes, but possibly in an optional attribute like ?descr?, ?org? > or ?remarks?. > > > Proposers? response: > > We do not believe so, for the following reasons, and keeping the > current practice and policies in consideration: > > 1. > The RIPE NCC does not consider that 2023-04 changes the contact > registration requirements in any way[1][2][3]. Absent any (rough) > consensus in the Working Group to the contrary, we defer to the > RIPE NCC?s judgement on this point. > 2. > The practice of creating assignments with all contact information > delegated is already widespread. If this was a policy violation > made possible due to the RIPE NCC implementing RIPE policy > incorrectly, we would have expected the community to take action > to correct this situation. However, no such policy proposal has > been put forward by the community. > 3. > Outsourcing and delegation of contact information is a common > practice across many industries, including in networking and > information technology. There is no policy language that > explicitly prohibits this for IPv4 assignments. Absent that, we > believe any implicit prohibition found ?between the lines? is > essentially ?void for vagueness?[4]. > 4. > An obligation to publish the End User?s contact information in the > RIPE database will constitute a violation of Article 6(3) of the > RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the > GDPR[6], if the End User?s contact person has not given explicit > consent to such publication. We believe that the RIPE policy > cannot reasonably be interpreted to require LIRs to break EU law > (and even if it explicitly did require that, EU law would still > take precedence). > 5. > The policy?s stated goal of registering assignments is ?to ensure > uniqueness and to provide information for Internet troubleshooting > at all levels?[7]. Requiring LIRs to publish the contact > information of End Users who often will not have any knowledge or > capability to aid with troubleshooting does work towards this > attaining goal. On the contrary, delegating the contact > information to the LIR/ISP may well be the only way to attain this > goal. > > > [1] > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html > > [2] > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > > [3] > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > > [4] https://www.law.cornell.edu/wex/void_for_vagueness > > [5] > https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms > > [6] > https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e1888-1-1 > > [7] https://www.ripe.net/publications/docs/ripe-804#3 > > > > 2. The ?assignment-size? attribute should be a CIDR prefix length > > Leaving it undefined could result in some LIRs using it to represent > an IPv4 address count, while others would use it to represent a CIDR > prefix length. > > > Proposers? response: > > We agree ?assignment-size? should be a CIDR prefix length. We > understand that, if proposal 2023-04 would be accepted, the RIPE NCC > could implement the ?assignment-size? attribute for IPv4 inetnum > objects to be a CIDR prefix length, and document it as such. Therefore > we do not believe it is necessary to spell this out explicitly in the > policy document (it is not spelled out in the IPv6 policy document > either). > > > Thank you for your attention and enjoy your holidays! > > Best regards, > Jeroen and Tore > > >> Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara >> het volgende geschreven: >> >> >> Dear colleagues, >> >> Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA >> assignments?, is now in the Review Phase. >> >> The goal of this proposal is to introduce the AGGREGATED-BY-LIR >> status for IPv4 PA assignments to reduce LIR efforts in registration >> and maintenance. >> >> This proposal has been updated and it is now at version 2.0. The >> proposed policy text did not change, the only difference is that the >> section "Arguments opposing the proposal" includes a reference to the >> last round of discussion. >> >> The RIPE NCC has prepared an impact analysis on this proposal to >> support the community?s discussion. >> >> You can find the proposal and impact analysis at: >> https://www.ripe.net/participate/policies/proposals/2023-04 >> https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis >> And the draft document at: >> https://www.ripe.net/participate/policies/proposals/2023-04/draft >> >> As per the RIPE Policy Development Process (PDP), the purpose of this >> four-week Review Phase is to continue the discussion of the proposal >> taking the impact analysis into consideration, and to review the full >> draft RIPE Policy Document. >> >> At the end of the Review Phase, the Working Group (WG) Chairs will >> determine whether the WG has reached rough consensus. >> It is therefore important to provide your opinion, even if it is >> simply a restatement of your input from the previous phase. >> >> We encourage you to read the proposal, impact analysis and draft >> document and to send any comments to address-policy-wg at ripe.net >> before 20 December 2023. >> >> Kind regards, >> Angela Dall'Ara >> Policy Officer >> RIPE NCC >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or >> change your subscription options, please visit: >> https://mailman.ripe.net/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Emmanuel.Kessler at europol.europa.eu Wed Dec 13 21:30:47 2023 From: Emmanuel.Kessler at europol.europa.eu (Kessler, Emmanuel) Date: Wed, 13 Dec 2023 20:30:47 +0000 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 Message-ID: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> Dear partners, companies and RIPE, on the last RIPE meeting, my inputs have unfortunately been hampered by some technical problems of online connection. With this message, I would like to express from Europol perspective, our questions and some clear concerns about the measure 2023-04 as proposed. We have been very recently informed about the project of measure that would indeed remove User assignment data from the RIPE Database public registry. We have started a consultation of EU law enforcement services (that however takes time), and informed the EU Commission. >From the first feedback we have gathered, the measure will have some clear negative impacts on the capacity of law enforcement authorities to lead investigation, considering the current situation and practices. Various law enforcement actors (LEA) do appreciate to have the information in the RIPE databases. This direct access helps many investigators to work swiftly in their daily activity against cybercriminals, fraudsters, pedophiles, terrorists...as we all know. The first negative impact will concern the swift availability of data : with the new measure, LEA will systematically have to request information to the LIRs, with a court order. Beyond the sole matter of lawfulness requirement, it will not ease as such the daily work, but instead it will be another barrier to the facilitated access to the data : easing the access means easing an efficient and swift investigation. The proposed measure does not prioritize it. Maintaining access to the data of end users at RIPE level is also a way to ensure access to all data, in spite of the uncertainty of answers from some LIRs. Registration practices are far to be uniform across the various LIRs. Please kindly consider that capacity of Law Enforcement is asymmetric towards large volumes of ransomware attacks, online scam types and massive sharing of Child Sexual Abuses Material,...all support from our partners is the most precious to counter these realities. The other main impact will be on the quality of collected data. In practice, the proposed policy could indeed allow assignments to be somewhat anonymised. The measure would have here an impact on data granularity : The shift to aggregated assignments would result in less granular data available to law enforcement. 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.. We do understand that the aggregated registration of IPv4 addresses would streamline administrative processes for LIRs but, it is important to acknowledge that it would also have a negative impact on the efficiency and effectiveness of law enforcement investigations. The less detailed information will require additional steps or inquiries to ascertain the specifics of an IP address's usage, potentially delaying investigative processes. Identifying IPV4, remains highly challenging in many cases, as all know, and IPV6 will not replace it at short term. All delays hamper the general (complex) process of investigation and may have an strong impact on the final result (bad guys arrested and new victims prevented or saved) EU has recently adopted the NIS2 directive with its article 28 for a better access to DNS information for the legitimate actors. we observe that the planned measure 2023-04 would open an opposite (negative) trend on the access to IP information. We express our serious concern with the impact that such a measure would have on various investigations carried out by EU competent authorities, and the protection of victims, should it be adopted. Thank you for your attention and consideration. Regards Emmanuel KESSLER Head of Team - Prevention/Outreach Europol - O3 European Cyber Crime Centre (EC3) Eisenhowerlaan 73, 2517 KK The Hague, The Netherlands Phone: [Moderated] / mobile [Moderated] www.europol.europa.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 1.jpg Type: image/jpeg Size: 1919 bytes Desc: Picture (Device Independent Bitmap) 1.jpg URL: From ripedenis at gmail.com Thu Dec 14 04:54:22 2023 From: ripedenis at gmail.com (denis walker) Date: Thu, 14 Dec 2023 04:54:22 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> Message-ID: Colleagues Here we go again. Let me start by saying that the emphasis and phrasing of both this email that I am replying to and the impact analysis seem to have been carefully chosen to show this proposal in a good way. What I mean by this will become apparent as you read on. Just to be clear, I object to this proposal. The discussion at RIPE 87 on the need for assignments in the RIPE Database and what contacts they should contain was very inconclusive. What it did show was that no one really understands what contacts are needed and what the current policy required contacts actually mean. Until we have a clear picture of what this data means and what different stakeholder groups require, we should not be considering changes on this scale. The RIPE NCC's impact analysis also completely ignored the impact of this proposal on the registry system. On Wed, 13 Dec 2023 at 19:14, Jeroen Lauwers wrote: > > Dear colleagues, > > Though we recognise that most of you are probably busy preparing for the upcoming holidays, we would like to ask you to share your opinion on proposal 2023-04. Remember that Policy Development Process requires any comments made during the Discussion phase must be repeated during the Review phase in order to count towards or against rough consensus, as your views can now take the RIPE NCC?s Impact Analysis into account. Let's look at the RIPE NCC's impact analysis (IA). The IA seems to focus mostly on the impact this proposal has on the RIPE NCC and its operations. I accept that the PDP (ripe-781) does suggest most of the IA will be about the impact on the NCC. But it does also mention the " registry and addressing systems". In Section A of the IA it says: "Acceptance of this proposal will not change the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this will remain their decision." This is too vague. It is true that it is the LIRs decision if they add contact A or contact B. However, the current policy says, as we all know now, an assignment MUST include the contact details of the End User. The RIPE NCC can and should enforce this policy requirement. The type of contact should be enforced, but not the specific contact. Section B of the IA has the title "Impact of Policy on Registry and Addressing System". The IA only refers to the impact on the addressing system. It says nothing about the impact on the registry. The registry has two parts. There is the internal, private registry. This is where the RIPE NCC stores things like contact details for the NCC to contact their members, the LIRs. This proposal probably doesn't have any impact on this part of the registry. The IA should still say that. The other part is the public registry, the RIPE Database. This proposal potentially has a huge impact on the public registry, but nothing has been said about this in the IA. So this raises a question about the PDP policy itself. Should the RIPE NCC focus ONLY on the impact the proposal has on the RIPE NCC or should it discuss wider implications for the Internet and other stakeholders? In the legal impact (Section D) it says: "the RIPE NCC would like to note that it is solely the responsibility of the member to choose which contact details to insert in the INETNUM object". This has the same vagueness as the comment in Section A. It then confuses the issue by talking about personal data. As I pointed out in my first attempt at a privacy policy last year, 'contact data NOT EQUAL personal data'. In 99% of INETNUM objects the End User contact details can be included without making any reference to personal data. The IA even refers to "contact person". As I pointed out last year, all contacts should be roles and not people. We are still locked into the mindset of referring to people. > > Here are some questions for the WG to get the discussion started: Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way? Does 2023-04 address this use case well in its current form, or could you think of any potential improvements? 'Convenience' is not the best parameter for determining internet policy. The idea of aligning IPv4 and IPv6 registrations is becoming an obsession. We should talk about aligning the two registration systems 'where appropriate'. Also as I said early on in this discussion, where two systems are mis-aligned, there are two ways to bring them into alignment. We can make IPv6 registrations work the same way as IPv4, with suitable technical improvements. > > We hope you will find the time to let your voice be heard! > > The Policy Development Process requires the proposers to adequately address any suggestions for changes or objections to the proposal in each phase, which we will do below. > > 1. Does 2023-04 change the contact registration requirements for assignments? > > > The argument made is that the statement ?When an End User has a network using public address space this must be registered separately with the contact details of the End User? found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy), implicitly requires LIRs to register non-delegated/outsourced contact information for the End User in the RIPE database, not necessarily in the mandatory ?admin-c? or ?tech-c? attributes, but possibly in an optional attribute like ?descr?, ?org? or ?remarks?. Fundamentally changing registration policy requirements "in order to bring the wording in line with that of the IPv6 policy" is absolutely the wrong reason to make such a change. > > Proposers? response: > > We do not believe so, for the following reasons, and keeping the current practice and policies in consideration: > > The RIPE NCC does not consider that 2023-04 changes the contact registration requirements in any way[1][2][3]. Absent any (rough) consensus in the Working Group to the contrary, we defer to the RIPE NCC?s judgement on this point. I answered ref [1] here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013860.html ref [2] (the IA) makes no comment regarding the impact on the registry and I answered ref [3] here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013896.html "we defer to the RIPE NCC?s judgement on this point". Policy is made by the community. If the RIPE NCC's interpretation of a policy point is not correct then the community can require that the RIPE NCC re-evaluates their interpretation. > The practice of creating assignments with all contact information delegated is already widespread. If this was a policy violation made possible due to the RIPE NCC implementing RIPE policy incorrectly, we would have expected the community to take action to correct this situation. However, no such policy proposal has been put forward by the community. There is a lot in this paragraph. The practice of documenting End User contact details in the optional "descr:" attributes is already widespread. That is likely because so many LIRs do understand the current policy. They have delegated the contact details in the mandatory attributes. But they realize the policy requires End User contact details so they add those details in other attributes. Given that you have put so much emphasis on the 'manual effort required to create assignment objects in the RIPE Database' I am sure so many LIRs have not entered this optional detail without good reason. "we would have expected the community to take action to correct this situation". The fact that 'the community' did not even realise this mis-interpretation of address policy by the RIPE NCC for so long, perhaps says more about the community than the RIPE NCC. There is no doubt that this is a policy violation. There are many other issues with the way address policy has been interpreted in recent years that I could talk about, but no one is interested. The reality is that much of 'the community' does not pay much attention to the fine detail of policy or the way it is interpreted. > Outsourcing and delegation of contact information is a common practice across many industries, including in networking and information technology. There is no policy language that explicitly prohibits this for IPv4 assignments. Absent that, we believe any implicit prohibition found ?between the lines? is essentially ?void for vagueness?[4]. You are correct that the policy does not prohibit the delegation of contact details. But the policy still clearly requires that End User contact details MUST be included 'somewhere'. The two points are not mutually exclusive. (Your ref to US criminal law is irrelevant.) > An obligation to publish the End User?s contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User?s contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence). Just as with the IA you have the 'person' mindset lock. Contacts should be roles, not people. As suggested in the privacy discussion last year, the roles can include optional person names if the people so wish. We should all stop using the term 'contact person' and refer to 'contact role'. > The policy?s stated goal of registering assignments is ?to ensure uniqueness and to provide information for Internet troubleshooting at all levels?[7]. Requiring LIRs to publish the contact information of End Users who often will not have any knowledge or capability to aid with troubleshooting does work towards this attaining goal. On the contrary, delegating the contact information to the LIR/ISP may well be the only way to attain this goal. You have been very selective here in your interpretation of the stated goals of the registry system. Firstly it does not state that 'uniqueness' and 'troubleshooting' form an exclusive list of the reasons for a public registry. Over the years the registry has evolved to the needs of other stakeholder groups. But if you want to take this wording literally it also says "The provision of a public registry documenting address space allocations and assignments must exist." An aggregation does not document assignments. It simply documents that a block of address space has been used for assignments. It is not documenting the actual assignments as required by these defined goals. You cannot take one sentence literally and then be flexible in your interpretation of the other sentence. cheers denis > > > [1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html > [2] https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > [4] https://www.law.cornell.edu/wex/void_for_vagueness > [5] https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms > [6] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e1888-1-1 > [7] https://www.ripe.net/publications/docs/ripe-804#3 > > 2. The ?assignment-size? attribute should be a CIDR prefix length > > Leaving it undefined could result in some LIRs using it to represent an IPv4 address count, while others would use it to represent a CIDR prefix length. > > Proposers? response: > > We agree ?assignment-size? should be a CIDR prefix length. We understand that, if proposal 2023-04 would be accepted, the RIPE NCC could implement the ?assignment-size? attribute for IPv4 inetnum objects to be a CIDR prefix length, and document it as such. Therefore we do not believe it is necessary to spell this out explicitly in the policy document (it is not spelled out in the IPv6 policy document either). > > > Thank you for your attention and enjoy your holidays! > > Best regards, > Jeroen and Tore > > > Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara het volgende geschreven: > > > Dear colleagues, > > Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA assignments?, is now in the Review Phase. > > The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. > > This proposal has been updated and it is now at version 2.0. The proposed policy text did not change, the only difference is that the section "Arguments opposing the proposal" includes a reference to the last round of discussion. > > The RIPE NCC has prepared an impact analysis on this proposal to support the community?s discussion. > > You can find the proposal and impact analysis at: > https://www.ripe.net/participate/policies/proposals/2023-04 > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > And the draft document at: > https://www.ripe.net/participate/policies/proposals/2023-04/draft > > As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue the discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. > > At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. > It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. > > We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg at ripe.net before 20 December 2023. > > Kind regards, > Angela Dall'Ara > Policy Officer > RIPE NCC > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From adallara at ripe.net Thu Dec 14 16:20:02 2023 From: adallara at ripe.net (Angela Dall'Ara) Date: Thu, 14 Dec 2023 16:20:02 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> Message-ID: <41182e70-8db3-4d8a-82e9-a7018c48f12f@ripe.net> Dear Denis and colleagues, I would like to provide some clarification about the scope of the Impact Analysis provided by the RIPE NCC on policy proposals. As per the RIPE Policy Development Process [1], the Impact Analysis is limited to: ? The RIPE NCC's understanding of the proposed policy ? Impact on the registry and addressing systems (including Internet resource consumption, aggregation and fragmentation) ? Impact on RIPE NCC operations/services/capacity ? Legal impact All of the above is exclusively from the RIPE NCC's point of view, and deliberate effort is taken to not include - and therefore not exclude - any other point of view. The discussion on the mailing list is open to all stakeholders to describe the impact they foresee if a proposal is accepted. I hope this helps. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC [1] https://www.ripe.net/publications/docs/ripe-781 On 14/12/2023 04:54, denis walker wrote: > Colleagues > > Here we go again. Let me start by saying that the emphasis and > phrasing of both this email that I am replying to and the impact > analysis seem to have been carefully chosen to show this proposal in a > good way. What I mean by this will become apparent as you read on. > > Just to be clear, I object to this proposal. The discussion at RIPE 87 > on the need for assignments in the RIPE Database and what contacts > they should contain was very inconclusive. What it did show was that > no one really understands what contacts are needed and what the > current policy required contacts actually mean. Until we have a clear > picture of what this data means and what different stakeholder groups > require, we should not be considering changes on this scale. The RIPE > NCC's impact analysis also completely ignored the impact of this > proposal on the registry system. > > On Wed, 13 Dec 2023 at 19:14, Jeroen Lauwers wrote: >> Dear colleagues, >> >> Though we recognise that most of you are probably busy preparing for the upcoming holidays, we would like to ask you to share your opinion on proposal 2023-04. Remember that Policy Development Process requires any comments made during the Discussion phase must be repeated during the Review phase in order to count towards or against rough consensus, as your views can now take the RIPE NCC?s Impact Analysis into account. > Let's look at the RIPE NCC's impact analysis (IA). The IA seems to > focus mostly on the impact this proposal has on the RIPE NCC and its > operations. I accept that the PDP (ripe-781) does suggest most of the > IA will be about the impact on the NCC. But it does also mention the " > registry and addressing systems". > > In Section A of the IA it says: > "Acceptance of this proposal will not change the fact that the RIPE > NCC cannot enforce which contact details members add to their IPv4 PA > assignments in the RIPE Database; this will remain their decision." > This is too vague. It is true that it is the LIRs decision if they add > contact A or contact B. However, the current policy says, as we all > know now, an assignment MUST include the contact details of the End > User. The RIPE NCC can and should enforce this policy requirement. The > type of contact should be enforced, but not the specific contact. > > Section B of the IA has the title "Impact of Policy on Registry and > Addressing System". The IA only refers to the impact on the addressing > system. It says nothing about the impact on the registry. The registry > has two parts. There is the internal, private registry. This is where > the RIPE NCC stores things like contact details for the NCC to contact > their members, the LIRs. This proposal probably doesn't have any > impact on this part of the registry. The IA should still say that. The > other part is the public registry, the RIPE Database. This proposal > potentially has a huge impact on the public registry, but nothing has > been said about this in the IA. So this raises a question about the > PDP policy itself. Should the RIPE NCC focus ONLY on the impact the > proposal has on the RIPE NCC or should it discuss wider implications > for the Internet and other stakeholders? > > In the legal impact (Section D) it says: > "the RIPE NCC would like to note that it is solely the responsibility > of the member to choose which contact details to insert in the INETNUM > object". > This has the same vagueness as the comment in Section A. It then > confuses the issue by talking about personal data. As I pointed out in > my first attempt at a privacy policy last year, 'contact data NOT > EQUAL personal data'. In 99% of INETNUM objects the End User contact > details can be included without making any reference to personal data. > The IA even refers to "contact person". As I pointed out last year, > all contacts should be roles and not people. We are still locked into > the mindset of referring to people. > >> Here are some questions for the WG to get the discussion started: Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way? Does 2023-04 address this use case well in its current form, or could you think of any potential improvements? > 'Convenience' is not the best parameter for determining internet > policy. The idea of aligning IPv4 and IPv6 registrations is becoming > an obsession. We should talk about aligning the two registration > systems 'where appropriate'. Also as I said early on in this > discussion, where two systems are mis-aligned, there are two ways to > bring them into alignment. We can make IPv6 registrations work the > same way as IPv4, with suitable technical improvements. > >> We hope you will find the time to let your voice be heard! >> >> The Policy Development Process requires the proposers to adequately address any suggestions for changes or objections to the proposal in each phase, which we will do below. >> >> 1. Does 2023-04 change the contact registration requirements for assignments? >> >> >> The argument made is that the statement ?When an End User has a network using public address space this must be registered separately with the contact details of the End User? found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy), implicitly requires LIRs to register non-delegated/outsourced contact information for the End User in the RIPE database, not necessarily in the mandatory ?admin-c? or ?tech-c? attributes, but possibly in an optional attribute like ?descr?, ?org? or ?remarks?. > Fundamentally changing registration policy requirements "in order to > bring the wording in line with that of the IPv6 policy" is absolutely > the wrong reason to make such a change. > >> Proposers? response: >> >> We do not believe so, for the following reasons, and keeping the current practice and policies in consideration: >> >> The RIPE NCC does not consider that 2023-04 changes the contact registration requirements in any way[1][2][3]. Absent any (rough) consensus in the Working Group to the contrary, we defer to the RIPE NCC?s judgement on this point. > I answered ref [1] here: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013860.html > ref [2] (the IA) makes no comment regarding the impact on the registry > and I answered ref [3] here: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013896.html > > "we defer to the RIPE NCC?s judgement on this point". Policy is made > by the community. If the RIPE NCC's interpretation of a policy point > is not correct then the community can require that the RIPE NCC > re-evaluates their interpretation. > >> The practice of creating assignments with all contact information delegated is already widespread. If this was a policy violation made possible due to the RIPE NCC implementing RIPE policy incorrectly, we would have expected the community to take action to correct this situation. However, no such policy proposal has been put forward by the community. > There is a lot in this paragraph. The practice of documenting End User > contact details in the optional "descr:" attributes is already > widespread. That is likely because so many LIRs do understand the > current policy. They have delegated the contact details in the > mandatory attributes. But they realize the policy requires End User > contact details so they add those details in other attributes. Given > that you have put so much emphasis on the 'manual effort required to > create assignment objects in the RIPE Database' I am sure so many LIRs > have not entered this optional detail without good reason. > > "we would have expected the community to take action to correct this > situation". The fact that 'the community' did not even realise this > mis-interpretation of address policy by the RIPE NCC for so long, > perhaps says more about the community than the RIPE NCC. There is no > doubt that this is a policy violation. There are many other issues > with the way address policy has been interpreted in recent years that > I could talk about, but no one is interested. The reality is that much > of 'the community' does not pay much attention to the fine detail of > policy or the way it is interpreted. > >> Outsourcing and delegation of contact information is a common practice across many industries, including in networking and information technology. There is no policy language that explicitly prohibits this for IPv4 assignments. Absent that, we believe any implicit prohibition found ?between the lines? is essentially ?void for vagueness?[4]. > You are correct that the policy does not prohibit the delegation of > contact details. But the policy still clearly requires that End User > contact details MUST be included 'somewhere'. The two points are not > mutually exclusive. (Your ref to US criminal law is irrelevant.) > >> An obligation to publish the End User?s contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User?s contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence). > Just as with the IA you have the 'person' mindset lock. Contacts > should be roles, not people. As suggested in the privacy discussion > last year, the roles can include optional person names if the people > so wish. We should all stop using the term 'contact person' and refer > to 'contact role'. > >> The policy?s stated goal of registering assignments is ?to ensure uniqueness and to provide information for Internet troubleshooting at all levels?[7]. Requiring LIRs to publish the contact information of End Users who often will not have any knowledge or capability to aid with troubleshooting does work towards this attaining goal. On the contrary, delegating the contact information to the LIR/ISP may well be the only way to attain this goal. > You have been very selective here in your interpretation of the stated > goals of the registry system. Firstly it does not state that > 'uniqueness' and 'troubleshooting' form an exclusive list of the > reasons for a public registry. Over the years the registry has evolved > to the needs of other stakeholder groups. But if you want to take this > wording literally it also says "The provision of a public registry > documenting address space allocations and assignments must exist." An > aggregation does not document assignments. It simply documents that a > block of address space has been used for assignments. It is not > documenting the actual assignments as required by these defined goals. > You cannot take one sentence literally and then be flexible in your > interpretation of the other sentence. > > cheers > denis > >> >> [1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html >> [2] https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis >> [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html >> [4] https://www.law.cornell.edu/wex/void_for_vagueness >> [5] https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms >> [6] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e1888-1-1 >> [7] https://www.ripe.net/publications/docs/ripe-804#3 >> >> 2. The ?assignment-size? attribute should be a CIDR prefix length >> >> Leaving it undefined could result in some LIRs using it to represent an IPv4 address count, while others would use it to represent a CIDR prefix length. >> >> Proposers? response: >> >> We agree ?assignment-size? should be a CIDR prefix length. We understand that, if proposal 2023-04 would be accepted, the RIPE NCC could implement the ?assignment-size? attribute for IPv4 inetnum objects to be a CIDR prefix length, and document it as such. Therefore we do not believe it is necessary to spell this out explicitly in the policy document (it is not spelled out in the IPv6 policy document either). >> >> >> Thank you for your attention and enjoy your holidays! >> >> Best regards, >> Jeroen and Tore >> >> >> Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara het volgende geschreven: >> >> >> Dear colleagues, >> >> Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA assignments?, is now in the Review Phase. >> >> The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. >> >> This proposal has been updated and it is now at version 2.0. The proposed policy text did not change, the only difference is that the section "Arguments opposing the proposal" includes a reference to the last round of discussion. >> >> The RIPE NCC has prepared an impact analysis on this proposal to support the community?s discussion. >> >> You can find the proposal and impact analysis at: >> https://www.ripe.net/participate/policies/proposals/2023-04 >> https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis >> And the draft document at: >> https://www.ripe.net/participate/policies/proposals/2023-04/draft >> >> As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue the discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. >> >> At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. >> It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. >> >> We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg at ripe.net before 20 December 2023. >> >> Kind regards, >> Angela Dall'Ara >> Policy Officer >> RIPE NCC >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ >> >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From tore at fud.no Thu Dec 14 16:34:21 2023 From: tore at fud.no (Tore Anderson) Date: Thu, 14 Dec 2023 16:34:21 +0100 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> Message-ID: <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> Hello Emmanuel, and thank you for your message! Please find our comments and questions inline below: On Wed, 2023-12-13 at 20:30 +0000, Kessler, Emmanuel wrote: > With this message, I would like to express from Europol perspective, > our questions and some clear concerns about the measure 2023-04 as > proposed. > ? > We have been very recently informed about the project of measure that > would indeed remove User assignment data from the RIPE Database > public registry. 2023-04 aims to *increase* the level of End User assignment coverage in the RIPE database, not remove or decrease it. Quoting from the proposal: ?As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs (?) Since the RIPE Database Requirements Task Force published their report in May 2021, the PA allocations without any child assignment have grown by 18.4 percent.? We hypothesise that this trend is least partially caused by LIRs considering that registering all assignments individually is too labour-intensive and not worth the effort, especially in highly dynamic environments where individual (but otherwise identical) assignments rapidly come and go. 2023-04 would provide these LIRs a less labour-intensive option to register such assignments. Whether or not they would avail themselves of the new option is of course an open question, but it seems clear that something has to be done if the current trend towards less assignment coverage in the database is to be reversed. > We have started a consultation of EU law enforcement services (that > however takes time), and informed the EU Commission. Did this consultation take the information in the Impact Analysis into account ? in particular the clarification made by the RIPE NCC that 2023-04 does *not* change the current policies and procedures when it comes to the registration requirements for End User contact information? If it did not, this concern may well be the same as the one we addressed in the message yesterday. Would it be possible for you to share the questionnaire that was sent to the LEAs with the working group? > The first negative impact will concern the swift availability of data > : with the new measure, LEA will systematically have to request > information to the LIRs, with a court order. Could you please detail or give some examples of exactly what kind of information the LEAs would need to request from the LIRs using court orders? Taking into account the current policies and procedures, we suspect that the information about the End Users that LEAs can obtain directly from the RIPE database is inserted there voluntarily in the first place. If that is the case, wouldn?t it be more efficient for the LEAs to first contact the published contact information (found either in the End User assignment, or its containing allocation) and request the information that way ? without going to the courts? Many LIRs would gladly help address any issues and are probably more capable in doing this than most End Users. Conversely, if the information requested is something the LIR prefers to withhold from the LEAs and the general public, it seems reasonable to assume that this information will not have been published in the public RIPE database in the first place. If so, a court order would be necessary - but that would be the case today, as well. > The other main impact will be on the quality of collected data. > In practice, the proposed policy could indeed allow assignments to be > somewhat anonymised. As clarified by the RIPE NCC in the Impact Analysis, the current policies and procedures are already allowing assignments to be ?somewhat anonymised?. This is not a change that 2023-04 will bring about. > The measure would have here an impact on data granularity : The shift > to aggregated assignments would result in less granular data > available to law enforcement. > 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.. As mentioned above it would be useful to know precisely what kind of information you are referring to here. We would appreciate it if you could share some examples. There is one thing we can think of, though - the assignment-size attribute. This is currently intended to be optional, as we did not see an independent justification for making it mandatory in IPv4. Given an LEA investigation into activity from 192.0.2.9, located within an aggregated inetnum object for 192.0.2.0/24 without the assignment- size attribute present, it would be impossible to deduce from the RIPE database alone if 192.0.2.10 is assigned to the same End User or not. If the assignment-size was present, the LEA would be able to answer that question without contacting the LIR. (assignment-size: <= /30 ? same End User; assignment-size: >= /31 ? different End User). This could be seen as an independent justification for making assignment-size mandatory in IPv4. If we amended 2023-04 accordingly, would that alleviate the LEAs concerns in this regard? > Identifying IPV4, remains highly challenging in many cases, as all > know, and IPV6 will not replace it at short term. The comparison with IPv6 is highly relevant. Apart from making the assignment-size attribute optional as discussed above, 2023-04 does not allow LIRs to do anything with their IPv4 assignments that has not already been allowed with IPv6 assignments for many years. The proposal is essentially a copy and paste from the IPv6 policy. With that in mind, do you see any principal difference between the proposed AGGREGATED-BY-LIR for IPv4 and the already existing AGGREGATED-BY-LIR for IPv6? Is the former more problematic for LEAs than the latter? If so, could you elaborate on why that is? Best regards, Tore and Jeroen From randy at psg.com Thu Dec 14 20:13:04 2023 From: randy at psg.com (Randy Bush) Date: Thu, 14 Dec 2023 11:13:04 -0800 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> Message-ID: hi, 2023-04 Add AGGREGATED-BY-LIR status for IPv4 PA assignments (which you may have mis-understood) aside, i am intellectually curious, but ianal, and i try not to play one on the net. i think i understand your concerns to a fair extent. the more and more accurate data leo can access without a court order makes life easier for leo. and, as a security guy who occasionally has to call leo, i have some sympathy for leo here. though in the extreme, we have a police state. but take anything to the extreme and it is silly. my point is that there is a spectrum. but as a privacy guy, i am interested in the tension between that and the privacy and data protection initiatives on which the eu seems to be in the lead (congrats). even operationally, we have a tension between privacy and data such as location (see geoloc: discussion), identity (whois), this proposal, etc. as i said, ianal, but i think the slow and frustrating court order is meant to dump that tradeoff on a judge. here, in our nerdy way, we're trying to automate it, but have the same tensions. so i wonder if you could shed some light on where you see the tradeoff here. randy, trying to move from positions to a conversation From jlauwers at a2b-internet.com Thu Dec 14 20:23:31 2023 From: jlauwers at a2b-internet.com (Jeroen Lauwers) Date: Thu, 14 Dec 2023 19:23:31 +0000 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> Message-ID: <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> Hello Denis, As proposers, we cannot address your objections against the RIPE NCC?s Impact Analysis, as we had no hand in producing it. However, we will try to address your points below that have not already been discussed at length. See inline: > Policy is made > by the community. If the RIPE NCC's interpretation of a policy point > is not correct then the community can require that the RIPE NCC > re-evaluates their interpretation. On this, we agree 100%. The question then becomes: is there someone willing to submit a policy proposal that would require that the RIPE NCC re-evaluate their interpretation? If there is, it would be prudent to put 2023-04 on hold, pending the outcome of that proposal. If not, that essentially amounts to a tacit acceptance by the community that the RIPE NCC?s interpretation of the current policy is correct, and we can proceed with 2023-04. > There is a lot in this paragraph. The practice of documenting End User > contact details in the optional "descr:" attributes is already > widespread. That is likely because so many LIRs do understand the > current policy. They have delegated the contact details in the > mandatory attributes. But they realize the policy requires End User > contact details so they add those details in other attributes. Given > that you have put so much emphasis on the 'manual effort required to > create assignment objects in the RIPE Database' I am sure so many LIRs > have not entered this optional detail without good reason. The practice differs greatly between LIRs. Some LIRs create database objects that are rife with optional information not mandated by policy (information about BGP communities, for example), while others prefer to create rather minimal objects that contain only the mandatory attributes. Your assumption that LIRs that include End User contact information in descr: do so because they believe policy compels them to may well be true for some LIRs, but other LIRs might do so out of their own free will. Neither of us can't know with any degree of certainty which is the most common case; trying to quantify the two groups of LIRs would be pure conjecture. That said, it is very easy to demonstrate that the ?out of their own free will? group of LIRs does exist and is significant in size. You can do that by downloading the inet6num database contents from the FTP and looking at the objects with the status ASSIGNED. You will find that there are *many* objects that contain the End User?s name, address, and other information in descr: None of that information is there because the LIRs in question have interpreted the policy to require them to publish this information, as the sentence ?When an End User has a network using public address space this must be registered separately with the contact details of the End User? does not occur in the IPv6 policy. The LIRs could easily have minimized their assignments, removing all descr: attributes, and/or registered them as part of an AGGREGATED-BY-LIR object. They have chosen not to do so, however. It seems safe to assume, therefore, that at least some of the LIRs that publish the same data in IPv4 inetnum objects do it voluntarily and not because they believe IPv4 policy compels them to. > Just as with the IA you have the 'person' mindset lock. Contacts > should be roles, not people. As suggested in the privacy discussion > last year, the roles can include optional person names if the people > so wish. We should all stop using the term 'contact person' and refer > to 'contact role' The policy needs to apply to assignments made to large enterprises with a dedicated NOC role, and to tiny one-person businesses whose only contact information is the owner?s personal Gmail address and mobile phone number. It is not feasible to require LIRs to only make assignments to End Users in the first category. It needs to also take into account End Users in the second category, whose contact person does not consent to the publication of their personal information in the RIPE database. > You have been very selective here in your interpretation of the stated > goals of the registry system. Firstly it does not state that > 'uniqueness' and 'troubleshooting' form an exclusive list of the > reasons for a public registry. Over the years the registry has evolved > to the needs of other stakeholder groups. But if you want to take this > wording literally it also says "The provision of a public registry > documenting address space allocations and assignments must exist." An > aggregation does not document assignments. Note that the IPv6 policy (section 3.3) contains very similar wording: ?Internet address space must be registered in a registry database accessible to appropriate members of the Internet community.? The community has decided that AGGREGATED-BY-LIR is compatible with this goal in the context of IPv6 assignments. Is there something unique about IPv4 assignments that makes ?The provision of a public registry documenting address space allocations and assignments must exist? not equally compatible with AGGREGATED-BY-LIR? Best regards, Tore and Jeroen From ripedenis at gmail.com Fri Dec 15 11:45:45 2023 From: ripedenis at gmail.com (denis walker) Date: Fri, 15 Dec 2023 11:45:45 +0100 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> Message-ID: Hi Tore Before I dig deeper into what you said let me first focus on two points that you just made. On Thu, 14 Dec 2023 at 16:34, Tore Anderson wrote: > > Hello Emmanuel, and thank you for your message! > > Please find our comments and questions inline below: > > Did this consultation take the information in the Impact Analysis into > account ? in particular the clarification made by the RIPE NCC that > 2023-04 does *not* change the current policies and procedures when it > comes to the registration requirements for End User contact > information? This is NOT clarified at all in the Impact Analysis. Why are you still saying this when I know, you know and by now probably every one knows, it is simply NOT true. You acknowledged again in your reply to me yesterday that this proposal removes that famous line from the current policy: "When an End User has a network using public address space this must be registered separately with the contact details of the End User." Removing this line *does* change current policies and would change procedures if the RIPE NCC was enforcing the current policy. We have been through this so many times. This is a very clear statement that says ALL assignments MUST contain the End User contact details. Removing this line means that assignments no longer need to contain any End User contact details. That is a significant change to the details that may or may not be entered into future assignment objects. > > As clarified by the RIPE NCC in the Impact Analysis, the current > policies and procedures are already allowing assignments to be > ?somewhat anonymised?. This is not a change that 2023-04 will bring > about. Again this is simply not true. That line you propose to remove does not currently permit anonymised assignments as they MUST include contact details of the End User. So this IS a change that 2023-04 WILL bring about. Will you please finally acknowledge that 2023-04 will allow totally anonymised, individual assignment objects that the current policy does not allow? (This is without even using the aggregated feature you are proposing to introduce.) cheers denis > > Best regards, > Tore and Jeroen From ripedenis at gmail.com Fri Dec 15 14:20:21 2023 From: ripedenis at gmail.com (denis walker) Date: Fri, 15 Dec 2023 14:20:21 +0100 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> Message-ID: Hi Tore We have been through all these arguments before, but it is the review phase now so they need to be repeated. On Thu, 14 Dec 2023 at 16:34, Tore Anderson wrote: > > Hello Emmanuel, and thank you for your message! > > Please find our comments and questions inline below: > > On Wed, 2023-12-13 at 20:30 +0000, Kessler, Emmanuel wrote: > > > > With this message, I would like to express from Europol perspective, > > our questions and some clear concerns about the measure 2023-04 as > > proposed. > > > > We have been very recently informed about the project of measure that > > would indeed remove User assignment data from the RIPE Database > > public registry. > > 2023-04 aims to *increase* the level of End User assignment coverage in > the RIPE database, not remove or decrease it. Quoting from the > proposal: > > ?As of August 2023, there were 19,221 PA allocations without any child > PA assignments held by 10,052 LIRs (?) Since the RIPE Database > Requirements Task Force published their report in May 2021, the PA > allocations without any child assignment have grown by 18.4 percent.? 18.4% of 19,221 is 3536. How many /24 allocations were made in that time period that quite likely don't have assignments? > > We hypothesise that this trend is least partially caused by LIRs > considering that registering all assignments individually is too > labour-intensive and not worth the effort, especially in highly dynamic > environments where individual (but otherwise identical) assignments > rapidly come and go. Pure speculation without any numbers. But what you are suggesting is that some LIRs don't consider it worth the effort to comply with RIPE policy and don't want to get involved in discussions to change the policy. I don't agree with your proposal but at least you are trying to change something you don't agree with. As for the labour intensity, we know the answer to that, but no one will even talk about updating the 25 - 30 year old RIPE Database design, data model and technology... As for 2023-04 increasing the level of End User assignment coverage, this is pure fantasy. In theory you could perhaps argue that the 'coverage' has increased if many LIRs create aggregated objects and claim that many assignments have been made from within that block. But the End User details will be completely lost within that amorphous block. Not even the assignment boundaries can be deduced. Many other LIRs may well anonymize their future or even already existing assignments by removing all references to the End User's identity and contact details. This may be done at the request of the End User. Or it may be done because the LIR has adopted a policy of not entering any details of their customers (End Users) into a public database. I have spoken to LIRs who have made it clear that it is already their policy regardless of current RIPE address policy requirements. They consider it commercially sensitive data. There are technical solutions to mitigate this but again no one will talk about the database. > > 2023-04 would provide these LIRs a less labour-intensive option to > register such assignments. Whether or not they would avail themselves > of the new option is of course an open question, but it seems clear > that something has to be done if the current trend towards less > assignment coverage in the database is to be reversed. Less labour intensive by dumping the detail. This is about eliminating a problem rather than solving the problem, again because no one will talk about technical solutions. You cannot define a trend based on two measurement points. I agree something does need to be done to get more LIRs complying with RIPE policies. But changing the registration rules so that more people appear to follow them is not the way forward. > > > We have started a consultation of EU law enforcement services (that > > however takes time), and informed the EU Commission. > > Did this consultation take the information in the Impact Analysis into > account ? in particular the clarification made by the RIPE NCC that > 2023-04 does *not* change the current policies and procedures when it > comes to the registration requirements for End User contact > information? > > If it did not, this concern may well be the same as the one we > addressed in the message yesterday. > > Would it be possible for you to share the questionnaire that was sent > to the LEAs with the working group? > > > The first negative impact will concern the swift availability of data > > : with the new measure, LEA will systematically have to request > > information to the LIRs, with a court order. > > Could you please detail or give some examples of exactly what kind of > information the LEAs would need to request from the LIRs using court > orders? > > Taking into account the current policies and procedures, we suspect > that the information about the End Users that LEAs can obtain directly > from the RIPE database is inserted there voluntarily in the first > place. Or because some LIRs have correctly interpreted the current policy. > > If that is the case, wouldn?t it be more efficient for the LEAs to > first contact the published contact information (found either in the > End User assignment, or its containing allocation) and request the > information that way ? without going to the courts? Many LIRs would > gladly help address any issues and are probably more capable in doing > this than most End Users. > > Conversely, if the information requested is something the LIR prefers > to withhold from the LEAs and the general public, it seems reasonable > to assume that this information will not have been published in the > public RIPE database in the first place. If so, a court order would be > necessary - but that would be the case today, as well. > > > The other main impact will be on the quality of collected data. > > In practice, the proposed policy could indeed allow assignments to be > > somewhat anonymised. > > As clarified by the RIPE NCC in the Impact Analysis, the current > policies and procedures are already allowing assignments to be > ?somewhat anonymised?. This is not a change that 2023-04 will bring > about. > > > The measure would have here an impact on data granularity : The shift > > to aggregated assignments would result in less granular data > > available to law enforcement. > > 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.. > > As mentioned above it would be useful to know precisely what kind of > information you are referring to here. We would appreciate it if you > could share some examples. > > There is one thing we can think of, though - the assignment-size > attribute. This is currently intended to be optional, as we did not see > an independent justification for making it mandatory in IPv4. > > Given an LEA investigation into activity from 192.0.2.9, located within > an aggregated inetnum object for 192.0.2.0/24 without the assignment- > size attribute present, it would be impossible to deduce from the RIPE > database alone if 192.0.2.10 is assigned to the same End User or not. > > If the assignment-size was present, the LEA would be able to answer > that question without contacting the LIR. (assignment-size: <= /30 ? > same End User; assignment-size: >= /31 ? different End User). > > This could be seen as an independent justification for making > assignment-size mandatory in IPv4. If we amended 2023-04 accordingly, > would that alleviate the LEAs concerns in this regard? > > > Identifying IPV4, remains highly challenging in many cases, as all > > know, and IPV6 will not replace it at short term. > > The comparison with IPv6 is highly relevant. Apart from making the > assignment-size attribute optional as discussed above, 2023-04 does not > allow LIRs to do anything with their IPv4 assignments that has not > already been allowed with IPv6 assignments for many years. The proposal > is essentially a copy and paste from the IPv6 policy. It is a good idea to align the IPv4 and IPv6 systems of registration 'where appropriate'. But maybe copy and paste without due consideration is not the best way to do it. There are differences. In those "many years" of aggregating IPv6 assignments not much of the internet was using IPv6. So it is not a valid argument to say there have been no problems with aggregating IPv6 over those "many years" so it must be OK. As more of the internet moves to IPv6, maybe we will start to see the problems that have been insignificant in the past. Maybe we will need to expand the IPv6 registration of assignments to match the current IPv4 policy. Again there are technical solutions here that no one will talk about. cheers denis > > With that in mind, do you see any principal difference between the > proposed AGGREGATED-BY-LIR for IPv4 and the already existing > AGGREGATED-BY-LIR for IPv6? Is the former more problematic for LEAs > than the latter? If so, could you elaborate on why that is? > > Best regards, > Tore and Jeroen > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From tore at fud.no Fri Dec 15 14:28:13 2023 From: tore at fud.no (Tore Anderson) Date: Fri, 15 Dec 2023 14:28:13 +0100 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> Message-ID: <4f1a3cc1ee654f8f46614a9bf14edc22a4d89a18.camel@fud.no> Hi Denis, On Fri, 2023-12-15 at 11:45 +0100, denis walker wrote: > On Thu, 14 Dec 2023 at 16:34, Tore Anderson wrote: > > > > Did this consultation take the information in the Impact Analysis into > > account ? in particular the clarification made by the RIPE NCC that > > 2023-04 does *not* change the current policies and procedures when it > > comes to the registration requirements for End User contact > > information? > > This is NOT clarified at all in the Impact Analysis. Why are you still > saying this when I know, you know and by now probably every one knows, > it is simply NOT true. (?) > > As clarified by the RIPE NCC in the Impact Analysis, the current > > policies and procedures are already allowing assignments to be > > ?somewhat anonymised?. This is not a change that 2023-04 will bring > > about. > > Again this is simply not true. That line you propose to remove does > not currently permit anonymised assignments as they MUST include > contact details of the End User. So this IS a change that 2023-04 WILL > bring about. > > Will you please finally acknowledge that 2023-04 will allow totally > anonymised, individual assignment objects that the current policy does > not allow? (This is without even using the aggregated feature you are > proposing to introduce.) As we mentioned in our message on Wednesday, Jeroen and I simply defer to the RIPE NCC?s interpretation of what current policy allows and does not allow. We will be happy to acknowledge that 2023-04 changes something the moment the RIPE NCC acknowledges the same. Let me remind you of the example assignment made by ?SuperLIR GmbH? to ?CarFactory GmbH?, registered in the RIPE database as follows: inetnum: 192.0.2.0 - 192.0.2.128 netname: ABCDEFGHIJKLMNOPQRSTUVWXYZ country: DE admin-c: SUPERLIR-NOC-RIPE tech-c: SUPERLIR-NOC-RIPE status: ASSIGNED PA mnt-by: SUPERLIR-MNT source: RIPE We assume that you agree that the above is a ?totally anonymised, individual assignment object?? We asked the RIPE NCC whether or not the above object was compliant with *current* IPv4 address policy or not. The RIPE NCC Policy Officer answered as follows: ?The above registration compliant with current IPv4 address policy. ?? (For the full answer, see https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html ). This sentiment is echoed in the 2023-04 Impact Analysis (section A, paragraph 3). In light of this, we remain convinced that we accurately and truthfully represent the RIPE NCC?s interpretation of the current policy in our messages to the working group, and also that we accurately and truthfully represent the RIPE NCC?s view that 2023-04 will not change the contact registration requirements. (While admin-c and tech-c will remain mandatory, they can be delegated as in the example object above.) We are well aware that you strongly disagree with the RIPE NCC ? and by extension, Jeroen and I ? in this interpretation. That is of course totally fine. However, if you would like to see the actual implementation of the policy brought in line with your interpretation of it, you would need to persuade the RIPE NCC to change their mind ? not Jeroen or I. Jeroen or I cannot change the RIPE NCC?s procedures. To that end, you might want to submit a policy proposal that would clarify for the RIPE NCC what the correct implementation should be, so that their procedures are brought in line with your expectations. If you do that, we can put 2023-04 on hold pending the outcome of your proposal. Best regards, Tore and Jeroen From phessler at theapt.org Fri Dec 15 14:33:41 2023 From: phessler at theapt.org (Peter Hessler) Date: Fri, 15 Dec 2023 14:33:41 +0100 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: <4f1a3cc1ee654f8f46614a9bf14edc22a4d89a18.camel@fud.no> References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> <4f1a3cc1ee654f8f46614a9bf14edc22a4d89a18.camel@fud.no> Message-ID: On 2023 Dec 15 (Fri) at 14:28:13 +0100 (+0100), Tore Anderson wrote: :To that end, you might want to submit a policy proposal that would :clarify for the RIPE NCC what the correct implementation should be, so :that their procedures are brought in line with your expectations. If :you do that, we can put 2023-04 on hold pending the outcome of your :proposal. : Please don't do that. Denis wishing to change policy should not block this proposal. Additionally, I believe that Denis' proposal on this topic is unlikely to reach concensous, as you can guess from reading the acrimonious discussion across several lists. :Best regards, :Tore and Jeroen -peter From frettled at gmail.com Fri Dec 15 14:58:40 2023 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 15 Dec 2023 14:58:40 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> Message-ID: Hello, Can the proposers please clarify how a change, that is claimed to change nothing, is a necessary change? Unless this is resolved, I oppose the change. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripedenis at gmail.com Fri Dec 15 15:04:38 2023 From: ripedenis at gmail.com (denis walker) Date: Fri, 15 Dec 2023 15:04:38 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> Message-ID: Hi Jeroen Looking back over this email, there are two things that really stand out to me. "Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way?" "the statement ?When an End User has a network using public address space this must be registered separately with the contact details of the End User? found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy)" These two statements that you made basically sum up this policy proposal. You are suggesting we fundamentally change IPv4 address policy for the 'convenience' of operators and to 'align' some words between two different policies regardless of the consequences. When you add to this a comment Gert made at RIPE 87 when he said that after 30 years we have no clue as to what the "admic-c:" attribute means or why anyone would want to contact them or what they would expect to get from such contact. We have maybe 5 or 6 million inetnum objects in the RIPE Database, a few million inet6num objects and probably tens of thousands of aut-num objects. They all have a mandatory admin-c and we don't know why it is there. All we have is a 30 year old definition that says it must be an on-site contact for the End User in the case of assignment and ASNs. This is a dreadful situation to be in. I suggest that 2023-04 is withdrawn. Then we have a wide reaching consultation with many stakeholder groups who use the RIPE Database. Determine what their needs are for a public registry. What information they need and would like to have in the RIPE Database. Basically do what I expected the last database task force to do, produce a business requirements document for the RIPE Database as a public registry. Then see where we go from there. cheers denis On Wed, 13 Dec 2023 at 19:14, Jeroen Lauwers wrote: > > Dear colleagues, > > Though we recognise that most of you are probably busy preparing for the upcoming holidays, we would like to ask you to share your opinion on proposal 2023-04. Remember that Policy Development Process requires any comments made during the Discussion phase must be repeated during the Review phase in order to count towards or against rough consensus, as your views can now take the RIPE NCC?s Impact Analysis into account. > > Here are some questions for the WG to get the discussion started: Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way? Does 2023-04 address this use case well in its current form, or could you think of any potential improvements? > > We hope you will find the time to let your voice be heard! > > The Policy Development Process requires the proposers to adequately address any suggestions for changes or objections to the proposal in each phase, which we will do below. > > 1. Does 2023-04 change the contact registration requirements for assignments? > > > The argument made is that the statement ?When an End User has a network using public address space this must be registered separately with the contact details of the End User? found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy), implicitly requires LIRs to register non-delegated/outsourced contact information for the End User in the RIPE database, not necessarily in the mandatory ?admin-c? or ?tech-c? attributes, but possibly in an optional attribute like ?descr?, ?org? or ?remarks?. > > Proposers? response: > > We do not believe so, for the following reasons, and keeping the current practice and policies in consideration: > > The RIPE NCC does not consider that 2023-04 changes the contact registration requirements in any way[1][2][3]. Absent any (rough) consensus in the Working Group to the contrary, we defer to the RIPE NCC?s judgement on this point. > The practice of creating assignments with all contact information delegated is already widespread. If this was a policy violation made possible due to the RIPE NCC implementing RIPE policy incorrectly, we would have expected the community to take action to correct this situation. However, no such policy proposal has been put forward by the community. > Outsourcing and delegation of contact information is a common practice across many industries, including in networking and information technology. There is no policy language that explicitly prohibits this for IPv4 assignments. Absent that, we believe any implicit prohibition found ?between the lines? is essentially ?void for vagueness?[4]. > An obligation to publish the End User?s contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User?s contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence). > The policy?s stated goal of registering assignments is ?to ensure uniqueness and to provide information for Internet troubleshooting at all levels?[7]. Requiring LIRs to publish the contact information of End Users who often will not have any knowledge or capability to aid with troubleshooting does work towards this attaining goal. On the contrary, delegating the contact information to the LIR/ISP may well be the only way to attain this goal. > > > [1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html > [2] https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > [4] https://www.law.cornell.edu/wex/void_for_vagueness > [5] https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms > [6] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e1888-1-1 > [7] https://www.ripe.net/publications/docs/ripe-804#3 > > 2. The ?assignment-size? attribute should be a CIDR prefix length > > Leaving it undefined could result in some LIRs using it to represent an IPv4 address count, while others would use it to represent a CIDR prefix length. > > Proposers? response: > > We agree ?assignment-size? should be a CIDR prefix length. We understand that, if proposal 2023-04 would be accepted, the RIPE NCC could implement the ?assignment-size? attribute for IPv4 inetnum objects to be a CIDR prefix length, and document it as such. Therefore we do not believe it is necessary to spell this out explicitly in the policy document (it is not spelled out in the IPv6 policy document either). > > > Thank you for your attention and enjoy your holidays! > > Best regards, > Jeroen and Tore > > > Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara het volgende geschreven: > > > Dear colleagues, > > Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA assignments?, is now in the Review Phase. > > The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. > > This proposal has been updated and it is now at version 2.0. The proposed policy text did not change, the only difference is that the section "Arguments opposing the proposal" includes a reference to the last round of discussion. > > The RIPE NCC has prepared an impact analysis on this proposal to support the community?s discussion. > > You can find the proposal and impact analysis at: > https://www.ripe.net/participate/policies/proposals/2023-04 > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > And the draft document at: > https://www.ripe.net/participate/policies/proposals/2023-04/draft > > As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue the discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. > > At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. > It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. > > We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg at ripe.net before 20 December 2023. > > Kind regards, > Angela Dall'Ara > Policy Officer > RIPE NCC > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From phessler at theapt.org Fri Dec 15 15:11:42 2023 From: phessler at theapt.org (Peter Hessler) Date: Fri, 15 Dec 2023 15:11:42 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: I still support the proposal as-is. The proposed change does not weaken any data that is in the database, and in fact may allow it to be more obvious that these address ranges are used by end users rather than be unclear what their status is. Furthermore, I will state that Denis' objections are not relevant to the proposal. The proposers, various people on the lists (including myself), and the RIPE NCC themselves all state the opposite of what Denis is saying. In addition the proposers have, in my opinion, addressed the concerns stated. -peter On 2023 Nov 21 (Tue) at 11:13:57 +0100 (+0100), Angela Dall'Ara wrote: : :Dear colleagues, : :Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA :assignments?, is now in the Review Phase. : :The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for :IPv4 PA assignments to reduce LIR efforts in registration and maintenance. : :This proposal has been updated and it is now at version 2.0. The proposed :policy text did not change, the only difference is that the section :"Arguments opposing the proposal" includes a reference to the last round of :discussion. : :The RIPE NCC has prepared an impact analysis on this proposal to support the :community?s discussion. : :You can find the proposal and impact analysis at: :https://www.ripe.net/participate/policies/proposals/2023-04 :https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis :And the draft document at: :https://www.ripe.net/participate/policies/proposals/2023-04/draft : :As per the RIPE Policy Development Process (PDP), the purpose of this :four-week Review Phase is to continue the discussion of the proposal taking :the impact analysis into consideration, and to review the full draft RIPE :Policy Document. : :At the end of the Review Phase, the Working Group (WG) Chairs will determine :whether the WG has reached rough consensus. :It is therefore important to provide your opinion, even if it is simply a :restatement of your input from the previous phase. : :We encourage you to read the proposal, impact analysis and draft document and :to send any comments to address-policy-wg at ripe.net before 20 December 2023. : :Kind regards, :Angela Dall'Ara :Policy Officer :RIPE NCC From max at rfc2324.org Fri Dec 15 15:32:45 2023 From: max at rfc2324.org (Maximilian Wilhelm) Date: Fri, 15 Dec 2023 15:32:45 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: <20231215143245.GA1138@principal.rfc2324.org> Hi folks, Anno domini 2023 Peter Hessler scripsit: > I still support the proposal as-is. The proposed change does not > weaken any data that is in the database, and in fact may allow it to be > more obvious that these address ranges are used by end users rather than > be unclear what their status is. > > Furthermore, I will state that Denis' objections are not relevant to the > proposal. The proposers, various people on the lists (including myself), > and the RIPE NCC themselves all state the opposite of what Denis is > saying. In addition the proposers have, in my opinion, addressed the > concerns stated. +1 to what Peter said. Cheers, Max From sander at steffann.nl Fri Dec 15 18:14:38 2023 From: sander at steffann.nl (Sander Steffann) Date: Fri, 15 Dec 2023 18:14:38 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <20231215143245.GA1138@principal.rfc2324.org> References: <20231215143245.GA1138@principal.rfc2324.org> Message-ID: <504E4688-ACB0-48B7-9E65-3807ECF86EC4@steffann.nl> Hi, > On 15 Dec 2023, at 15:32, Maximilian Wilhelm wrote: > > Hi folks, > > Anno domini 2023 Peter Hessler scripsit: > >> I still support the proposal as-is. The proposed change does not >> weaken any data that is in the database, and in fact may allow it to be >> more obvious that these address ranges are used by end users rather than >> be unclear what their status is. >> >> Furthermore, I will state that Denis' objections are not relevant to the >> proposal. The proposers, various people on the lists (including myself), >> and the RIPE NCC themselves all state the opposite of what Denis is >> saying. In addition the proposers have, in my opinion, addressed the >> concerns stated. > > +1 to what Peter said. > > Cheers, > Max I?ll add my +1 as well. I think this discussion has brought the issue to the attention of this community extensively. After reading the history on this mailing list and looking at the impact analysis, I think we have reached the point in rough consensus where Denis? concerns have been addressed, but not accommodated. This is a valid outcome: "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated? Cheers, Sander From tore at fud.no Sat Dec 16 19:53:03 2023 From: tore at fud.no (Tore Anderson) Date: Sat, 16 Dec 2023 19:53:03 +0100 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> Message-ID: <4639fc8510133b5631594d238d9e455230e77484.camel@fud.no> Hi Denis, On Fri, 2023-12-15 at 14:20 +0100, denis walker wrote: > We have been through all these arguments before, but it is the review > phase now so they need to be repeated. Indeed. We will now restate our responses too, as required by the PDP. That said, there are no new arguments presented, so anyone reading this should feel free to skip the rest of this message. > On Thu, 14 Dec 2023 at 16:34, Tore Anderson wrote: > > > > ?As of August 2023, there were 19,221 PA allocations without any child > > PA assignments held by 10,052 LIRs (?) Since the RIPE Database > > Requirements Task Force published their report in May 2021, the PA > > allocations without any child assignment have grown by 18.4 percent.? > > 18.4% of 19,221 is 3536. How many /24 allocations were made in that > time period that quite likely don't have assignments? We will ask the RIPE NCC to provide the working group with the updated statistics you request here. > > > We hypothesise that this trend is least partially caused by LIRs > > considering that registering all assignments individually is too > > labour-intensive and not worth the effort, especially in highly dynamic > > environments where individual (but otherwise identical) assignments > > rapidly come and go. > > Pure speculation without any numbers. We have no hard data that prove (or disprove) this hypothesis, that is true. We have not surveyed the LIRs in question to ask them why they opt not to register assignments. That said, as we do have quite a bit of experience as LIR hostmasters (including working with highly dynamic network environments), we would prefer to call the hypothesis an educated guess, rather than pure speculation. > But what you are suggesting is that some LIRs don't consider it worth > the effort to comply with RIPE policy and don't want to get involved > in discussions to change the policy. Regrettably, yes. > I don't agree with your proposal but at least you are trying to > change something you don't agree with. We do appreciate you recognising that. > As for the labour intensity, we know the answer to that, but no one > will even talk about updating the 25 - 30 year old RIPE Database > design, data model and technology... We don't doubt that updating the RIPE database design, data model and technology is a good idea, but we believe this question falls outside of the scope of proposal 2023-04 (and the AP-WG charter entirely). > As for 2023-04 increasing the level of End User assignment coverage, > this is pure fantasy. In theory you could perhaps argue that the > 'coverage' has increased if many LIRs create aggregated objects and > claim that many assignments have been made from within that block. If a WHOIS lookup of an IPv4 address that today will return an ALLOCATED PA object (even though it is in fact assigned and in use) but after the implementation of 2023-04 will return an AGGREGATED-BY-LIR object, then we consider that the assignment coverage has increased. > But the End User details will be completely lost within that > amorphous block. We believe this concern has been addressed in the following message, under the heading ?Does 2023-04 change the contact registration requirements for assignments??. https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html > Not even the assignment boundaries can be deduced. As mentioned in the proposal text itself, we did not see any independent justification for making the assignment-size attribute mandatory in IPv4, as its use in the calculation of the HD-ratio in IPv6 is not applicable. That said, if you or anyone else in the working group can identify and clearly articulate an independent justification for making the assignment-size attribute mandatory in IPv4 too, then we will certainly give that due consideration and possibly amend the proposal accordingly. > Many other LIRs may well anonymize their future or even already > existing assignments by removing all references to the End User's > identity and contact details. This may be done at the request of the > End User. Or it may be done because the LIR has adopted a policy of > not entering any details of their customers (End Users) into a public > database. I have spoken to LIRs who have made it clear that it is > already their policy regardless of current RIPE address policy > requirements. They consider it commercially sensitive data. We believe these concerns have been addressed in the following message, under the heading ?Does 2023-04 change the contact registration requirements for assignments??. https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html > There are technical solutions to mitigate this but again no one will > talk about the database. We assume you refer to improving the RIPE database technology here, which we have answered earlier on in this message. > > > 2023-04 would provide these LIRs a less labour-intensive option to > > register such assignments. Whether or not they would avail themselves > > of the new option is of course an open question, but it seems clear > > that something has to be done if the current trend towards less > > assignment coverage in the database is to be reversed. > > Less labour intensive by dumping the detail. This is about > eliminating a problem rather than solving the problem, again because > no one will talk about technical solutions. You cannot define a trend > based on two measurement points. I agree something does need to be > done to get more LIRs complying with RIPE policies. But changing the > registration rules so that more people appear to follow them is not > the way forward. We believe the concerns about ?dumping the detail? and ?changing the registration rules? have been addressed in the following message, under the heading ?Does 2023-04 change the contact registration requirements for assignments??. https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html As for the ?technical solutions? part, we assume you refer to improving the RIPE database technology, which we have answered earlier in this message. > > > > Taking into account the current policies and procedures, we suspect > > that the information about the End Users that LEAs can obtain > > directly from the RIPE database is inserted there voluntarily in > > the first place. > > Or because some LIRs have correctly interpreted the current policy. We do not believe that interpretation to be correct, as noted in the following message, under the heading ?Does 2023-04 change the contact registration requirements for assignments??. https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html > > It is a good idea to align the IPv4 and IPv6 systems of registration > 'where appropriate'. Agreed. > But maybe copy and paste without due consideration is not the best > way to do it. We believe we have given this due consideration prior to submitting the proposal. We have looked at how AGGREGATED-BY-LIR is being used in IPv6 (it appears to be popular amongst LIRs as there are almost 60k such objects in the database) and contrasted this with how there is an ongoing challenge with LIRs not registering their IPv4 assignments at all (cf. ripe-767 section 6.1.2). We truly believe AGGREGATED-BY-LIR strikes a good balance here, otherwise we would not have submitted our proposal. > There are differences. In those "many years" of aggregating IPv6 > assignments not much of the internet was using IPv6. So it is not a > valid argument to say there have been no problems with aggregating > IPv6 over those "many years" so it must be OK. As more of the > internet moves to IPv6, maybe we will start to see the problems that > have been insignificant in the past. IPv6 is extensively used nowadays, yet so far we have not seen anyone describing any problems caused by AGGREGATED-BY-LIR in IPv6 (much less attempt to fix them). If there truly were any problems with IPv6 AGGREGATED-BY-LIR, we would have expected them to manifest by now. We have not seen any reason to expect that IPv4 AGGREGATED-BY-LIR would be any more (or less) problematic than IPv6 AGGREGATED-BY-LIR. > Maybe we will need to expand the IPv6 registration of assignments to > match the current IPv4 policy. That is certainly something the community could do if it wanted. That would not be our preferred approach, though, as we fear this might import the problem of LIRs not registering assignments (cf. ripe-767 section 6.1.2) from IPv4 into IPv6, do nothing to help with the labour intensiveness of keeping the RIPE database up to date in highly dynamic environments (rather it would introduce or aggravate that problem in IPv6), as well as leave us with a major headache about what to do with the ~60k invalidated AGGREGATED-BY-LIR inet6num objects. > Again there are technical solutions here that no one will talk about. We assume you refer to improving the RIPE database technology here, which we have answered earlier on in this message. Best regards, Jeroen and Tore From tore at fud.no Sat Dec 16 19:55:20 2023 From: tore at fud.no (Tore Anderson) Date: Sat, 16 Dec 2023 19:55:20 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> <582BE1A4-DFAA-4223-BA11-1FEA14586D69@a2b-internet.com> Message-ID: <798d3a173bb75962739c1fd9396a3a577ea00b8f.camel@fud.no> Hi Jan, On Fri, 2023-12-15 at 14:58 +0100, Jan Ingvoldstad wrote: > Can the proposers please clarify how a change, that is claimed to > change nothing, is a necessary change? > > Unless this is resolved, I oppose the change. Certainly - we are happy to clarify. We believe we are actually talking about two different changes here. The first one is intentional, as it is the actual intended goal of the proposal ? namely to allow LIRs to aggregate multiple assignments with the same purpose and contact details into a single aggregated object. For example, if you are an LIR/ISP that today have the following two customer assignments in the database: inetnum: 192.0.2.0 - 192.0.2.127 netname: JAN-ISP country: NO admin-c: JAN-RIPE tech-c: JAN-RIPE status: ASSIGNED PA mnt-by: JAN-MNT source: RIPE inetnum: 192.0.2.128 - 192.0.2.255 netname: JAN-ISP country: NO admin-c: JAN-RIPE tech-c: JAN-RIPE status: ASSIGNED PA mnt-by: JAN-MNT source: RIPE If 2023-04 passes, you will be able to (but will not be required to) replace your above two objects in the database with the following aggregated object, similar to what you already can do in IPv6: inetnum: 192.0.2.0 - 192.0.2.255 netname: JAN-ISP country: NO admin-c: JAN-RIPE tech-c: JAN-RIPE status: AGGREGATED-BY-LIR mnt-by: JAN-MNT source: RIPE You cannot create such aggregated objects today, so that is clearly an intentional change that 2023-04 will bring about. There is no dispute that this change will take place. The second ? alleged ? change is the one that has been discussed the most on the mailing list. The argument here is that your two ASSIGNED PA objects above are actually in violation of *current* policy, because they delegate all the contact information to you (the ISP/LIR). The claim is that current policy requires non-delegated contact information for the End User to be published in the object (not necessarily in admin-c/tech-c, but ?somewhere?). If 2023-04 passes, your two ASSIGNED PA assignments above will definitely be policy compliant (even before they are possibly replaced with an AGGREGATED-BY-LIR object). There is no disagreement about this, as far as we know. So the question is whether or not your two ASSIGNED PA objects are permitted under *current* policy. If they are, then 2023-04 does not change anything in this regard; the ?legal status? of your objects will remain the same ? i.e., they are not violating policy ? after 2023-04 passes (or fails) as it is under current policy. We believe your two objects are not in violation of today?s policy, which means 2023-04 will exact no change to their ?legal status?. We have elaborated on why in this message, under the heading ?Does 2023-04 change the contact registration requirements for assignments??: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html We hope this provides the clarification you requested. Best regards, Jeroen and Tore From me at cynthia.re Sun Dec 17 13:14:44 2023 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Sun, 17 Dec 2023 13:14:44 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: <95D9287F-25D6-40FC-9D22-4C2841BB36FC@a2b-internet.com> Message-ID: I still oppose this policy and mostly agree with denis. I don't think it makes sense to push through this policy currently given the concerns raised and the quite limited potential benefits. -Cynthia On Fri, 15 Dec 2023, 15:05 denis walker, wrote: > Hi Jeroen > > Looking back over this email, there are two things that really stand out > to me. > > "Do you already use AGGREGATED-BY-LIR when registering IPv6 > assignments? Would you find it convenient and useful to be able to > register IPv4 assignments in the same way?" > > "the statement ?When an End User has a network using public address > space this must be registered separately with the contact details of > the End User? found in the current policy (and removed by 2023-04 in > order to bring the wording in line with that of the IPv6 policy)" > > These two statements that you made basically sum up this policy > proposal. You are suggesting we fundamentally change IPv4 address > policy for the 'convenience' of operators and to 'align' some words > between two different policies regardless of the consequences. > > When you add to this a comment Gert made at RIPE 87 when he said that > after 30 years we have no clue as to what the "admic-c:" attribute > means or why anyone would want to contact them or what they would > expect to get from such contact. We have maybe 5 or 6 million inetnum > objects in the RIPE Database, a few million inet6num objects and > probably tens of thousands of aut-num objects. They all have a > mandatory admin-c and we don't know why it is there. All we have is a > 30 year old definition that says it must be an on-site contact for the > End User in the case of assignment and ASNs. > > This is a dreadful situation to be in. I suggest that 2023-04 is > withdrawn. Then we have a wide reaching consultation with many > stakeholder groups who use the RIPE Database. Determine what their > needs are for a public registry. What information they need and would > like to have in the RIPE Database. Basically do what I expected the > last database task force to do, produce a business requirements > document for the RIPE Database as a public registry. Then see where we > go from there. > > cheers > denis > > > On Wed, 13 Dec 2023 at 19:14, Jeroen Lauwers > wrote: > > > > Dear colleagues, > > > > Though we recognise that most of you are probably busy preparing for the > upcoming holidays, we would like to ask you to share your opinion on > proposal 2023-04. Remember that Policy Development Process requires any > comments made during the Discussion phase must be repeated during the > Review phase in order to count towards or against rough consensus, as your > views can now take the RIPE NCC?s Impact Analysis into account. > > > > Here are some questions for the WG to get the discussion started: Do you > already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you > find it convenient and useful to be able to register IPv4 assignments in > the same way? Does 2023-04 address this use case well in its current form, > or could you think of any potential improvements? > > > > We hope you will find the time to let your voice be heard! > > > > The Policy Development Process requires the proposers to adequately > address any suggestions for changes or objections to the proposal in each > phase, which we will do below. > > > > 1. Does 2023-04 change the contact registration requirements for > assignments? > > > > > > The argument made is that the statement ?When an End User has a network > using public address space this must be registered separately with the > contact details of the End User? found in the current policy (and removed > by 2023-04 in order to bring the wording in line with that of the IPv6 > policy), implicitly requires LIRs to register non-delegated/outsourced > contact information for the End User in the RIPE database, not necessarily > in the mandatory ?admin-c? or ?tech-c? attributes, but possibly in an > optional attribute like ?descr?, ?org? or ?remarks?. > > > > Proposers? response: > > > > We do not believe so, for the following reasons, and keeping the current > practice and policies in consideration: > > > > The RIPE NCC does not consider that 2023-04 changes the contact > registration requirements in any way[1][2][3]. Absent any (rough) consensus > in the Working Group to the contrary, we defer to the RIPE NCC?s judgement > on this point. > > The practice of creating assignments with all contact information > delegated is already widespread. If this was a policy violation made > possible due to the RIPE NCC implementing RIPE policy incorrectly, we would > have expected the community to take action to correct this situation. > However, no such policy proposal has been put forward by the community. > > Outsourcing and delegation of contact information is a common practice > across many industries, including in networking and information technology. > There is no policy language that explicitly prohibits this for IPv4 > assignments. Absent that, we believe any implicit prohibition found > ?between the lines? is essentially ?void for vagueness?[4]. > > An obligation to publish the End User?s contact information in the RIPE > database will constitute a violation of Article 6(3) of the RIPE Database > Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End > User?s contact person has not given explicit consent to such publication. > We believe that the RIPE policy cannot reasonably be interpreted to require > LIRs to break EU law (and even if it explicitly did require that, EU law > would still take precedence). > > The policy?s stated goal of registering assignments is ?to ensure > uniqueness and to provide information for Internet troubleshooting at all > levels?[7]. Requiring LIRs to publish the contact information of End Users > who often will not have any knowledge or capability to aid with > troubleshooting does work towards this attaining goal. On the contrary, > delegating the contact information to the LIR/ISP may well be the only way > to attain this goal. > > > > > > [1] > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html > > [2] > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > > [3] > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html > > [4] https://www.law.cornell.edu/wex/void_for_vagueness > > [5] > https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms > > [6] > https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e1888-1-1 > > [7] https://www.ripe.net/publications/docs/ripe-804#3 > > > > 2. The ?assignment-size? attribute should be a CIDR prefix length > > > > Leaving it undefined could result in some LIRs using it to represent an > IPv4 address count, while others would use it to represent a CIDR prefix > length. > > > > Proposers? response: > > > > We agree ?assignment-size? should be a CIDR prefix length. We understand > that, if proposal 2023-04 would be accepted, the RIPE NCC could implement > the ?assignment-size? attribute for IPv4 inetnum objects to be a CIDR > prefix length, and document it as such. Therefore we do not believe it is > necessary to spell this out explicitly in the policy document (it is not > spelled out in the IPv6 policy document either). > > > > > > Thank you for your attention and enjoy your holidays! > > > > Best regards, > > Jeroen and Tore > > > > > > Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara het > volgende geschreven: > > > > > > Dear colleagues, > > > > Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA > assignments?, is now in the Review Phase. > > > > The goal of this proposal is to introduce the AGGREGATED-BY-LIR status > for IPv4 PA assignments to reduce LIR efforts in registration and > maintenance. > > > > This proposal has been updated and it is now at version 2.0. The > proposed policy text did not change, the only difference is that the > section "Arguments opposing the proposal" includes a reference to the last > round of discussion. > > > > The RIPE NCC has prepared an impact analysis on this proposal to support > the community?s discussion. > > > > You can find the proposal and impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2023-04 > > > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > > And the draft document at: > > https://www.ripe.net/participate/policies/proposals/2023-04/draft > > > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Review Phase is to continue the discussion of the proposal taking > the impact analysis into consideration, and to review the full draft RIPE > Policy Document. > > > > At the end of the Review Phase, the Working Group (WG) Chairs will > determine whether the WG has reached rough consensus. > > It is therefore important to provide your opinion, even if it is simply > a restatement of your input from the previous phase. > > > > We encourage you to read the proposal, impact analysis and draft > document and to send any comments to address-policy-wg at ripe.net before 20 > December 2023. > > > > Kind regards, > > Angela Dall'Ara > > Policy Officer > > RIPE NCC > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://mailman.ripe.net/ > > > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://mailman.ripe.net/ > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://mailman.ripe.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boggits at gmail.com Mon Dec 18 12:01:21 2023 From: boggits at gmail.com (boggits) Date: Mon, 18 Dec 2023 11:01:21 +0000 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 at 10:14, Angela Dall'Ara wrote: > > Dear colleagues, > > Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA > assignments?, is now in the Review Phase. > > The goal of this proposal is to introduce the AGGREGATED-BY-LIR status > for IP In general, i'm in favour of the proposal, however, it has raised several questions that I think as a community need to address before we can decide on the correct approach. What is the purpose of the registrations on assignments in the RipeDB? I always understood them as a way of recording who/what was using a piece of address space so that you can contact the right organisation in the case of an issue. In this case, there were explicit carve-outs for blocks of dynamic address space so that the ISP could be contacted to determine who was using that particular piece of address space at a single time. Where address space was allocated on a more permanent basis the contact details of the end site would be added so the organisation who was trying to address the problem had a direct route to contact that end network. From a technical point of view, it was useful as a reference to be able to work out if several IP addresses in a subnet had been allocated to the same customer or if there was a wider issue. This means that having the assignment size fixed for each block and included in the RipeDB entry is rather important. Over time we have become more concerned about privacy, contact details being shared, and the maintainability of the database. As such when IPv6 entries were added a specific additional label was created AGGREGATED-BY-LIR that allowed an LIR to say this block of address space is allocated to lots of individual organisations, with a boundary of /X please contact us if you need the contact details for them. Part of the reason for this was it gave the network operator to create long-lasting address allocations that were non-dynamic (as opposed to being static) and force them to register every single end user if they were going to try and be efficient in their allocation of addresses. For IPv6 I've not seen any issues raised about the creation of this class of address (I did ask earlier but got zero feedback) How does this Policy impact this use? This policy appears to take the standard approach for IPv6 and apply it to IPv4 (this is a good thing) it will reduce the number of individual entries in the system (neutral) and hopefully increase the accuracy (a good thing) but at the loss of explicitly including the contact details of the end user site and replacing it with a contact for the LIR (neutral). The last step appears to be the most controversial as it stops people from going directly to the source as it were. I think the operational impact here is a potential issue, some LIRs are less than stellar in dealing with requests about things listed in the RipeDB (mostly because of spam) so I can see the concern that some have raised about not being able to get hold of people. However that's not a Ripe issue explicitly but rather a function of the world of capitalism (it's free to send an email, let's send lots of emails, we only need a few people to respond to make money...) If we want to fix this problem then maybe we need to add a new capability onto the db that allows authenticated users to contact LIRs about their address space (without using the published contact details) in a way that would allow anti-abuse and LEAs to access the information they need, that is very much not something that needs discussion in the WG because were here to talk about address policy. This policy is optional... I think people have missed this, from my reading an LIR is not prevented from continuing to put entries without marking them as aggregated so from that point of view if you want to continue to include customer details (and you have their consent) you can still do it. So with all that said, I think I still support the policy with the caveat about assignment size mentioned earlier Thx J -- James Blessing 07989 039 476 -------------- next part -------------- An HTML attachment was scrubbed... URL: From edwin.verheul at surf.nl Mon Dec 18 16:49:20 2023 From: edwin.verheul at surf.nl (Edwin Verheul) Date: Mon, 18 Dec 2023 15:49:20 +0000 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 at 10:14, Angela Dall'Ara > wrote: Dear colleagues, Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA assignments?, is now in the Review Phase. The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for IP Hi Jeroen, I support this proposal. Since this policy introduces convenience for LIR by aligning ipv4 object policy to the ipv6 policy, unclear usage of the admin contact should not prevent this improvement in policy. Kind regards, Edwin Verheul SURF -------------- next part -------------- An HTML attachment was scrubbed... URL: From abscoco at gmail.com Mon Dec 18 22:11:31 2023 From: abscoco at gmail.com (Sylvain Baya) Date: Mon, 18 Dec 2023 22:11:31 +0100 Subject: [address-policy-wg] [policy-announce] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: Dear address-policy WG, Hope this email finds you in good health! Please see my comments below, inline... Thanks. Le vendredi 15 d?cembre 2023, Peter Hessler a ?crit : > I still support the proposal as-is. The proposed change does not > weaken any data that is in the database, and in fact may allow it to be > more obvious that these address ranges are used by end users rather than > be unclear what their status is. > > Hi Peter, Thanks for your email, brother. > > Furthermore, I will state that Denis' objections are not relevant to the > proposal. > ...this statement might have not sufficiently considered the fundamental issues raised by him. > The proposers, various people on the lists (including myself), > and the RIPE NCC themselves all state the opposite of what Denis is > saying. > ...i have to step in; because i think it should not be about the number of occurrence of an argument. ...imho! consensus should not be attained when fundamental issues such as a misinterpretation of a policy, or its misimplementation, might have occured silently. What's the process in the event of such a claim ? ...imho, i'm not sure that we should just move on without first correcting the mistinterpretation issue identified :-/ Without restoring the truth, it would be really tough to correctly evaluate the risks regarding proposed changes around the actual policy. > In addition the proposers have, in my opinion, addressed the > concerns stated. > ...as the core problem is above them; they stated that they refer to the Staff who produced the IA (Impact Analysis); avoiding the hot topic :-/ The issue raised by Denis remains unaddressed... ...imho! ...i stand with him; asking for a pause regarding the progress of this policy proposal. Shalom, --sb. > -peter > > > On 2023 Nov 21 (Tue) at 11:13:57 +0100 (+0100), Angela Dall'Ara wrote: > [...] -- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]| Subscribe to Mailing List: __ #?LASAINTEBIBLE?|#?Romains15?:33?Que LE ?#?DIEU? de ?#?Paix? soit avec vous tous! ?#?Amen?!? ?#?MaPri?re? est que tu naisses de nouveau. #Chr?tiennement? ?Comme une biche soupire apr?s des courants d?eau, ainsi mon ?me soupire apr?s TOI, ? DIEU!?(#Psaumes42:2) -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele at blacknight.com Tue Dec 19 15:22:19 2023 From: michele at blacknight.com (Michele Neylon - Blacknight) Date: Tue, 19 Dec 2023 14:22:19 +0000 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: All I was supportive of the proposed policy earlier in the process and still am. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours. From: address-policy-wg on behalf of Angela Dall'Ara Date: Tuesday, 21 November 2023 at 10:14 To: RIPE Address Policy Working Group Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. 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 at ripe.net before 20 December 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Emmanuel.Kessler at europol.europa.eu Wed Dec 20 12:07:19 2023 From: Emmanuel.Kessler at europol.europa.eu (Kessler, Emmanuel) Date: Wed, 20 Dec 2023 11:07:19 +0000 Subject: [address-policy-wg] @EXT: FW: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Message-ID: <969c2e1a10b24f429aff7e99703e2a5f@europol.europa.eu> Dear all, Thanks for the various points provided after my last message of the 13th December. we are assessing them with our colleagues of the police forces and we have shared with cybersecurity actors the EU. >From Law enforcement perspective, we would consider highly reasonable that RIPE organises a full consultation with relevant stakeholder groups that use RIPE data basis, to fully assess the impact and their needs. Such consultation would be necessary and legitimate as considering the official agreement signed on 2016 between RIPE NCC and EUROPOL that states that both parties, in accordance with their respective mandates, inform each other about the implementation of their respective mandates in the area of cybercrime, inform each other of programmes of potential interest in order to identify possibilities for joint activities and mutual contributions. As already mentioned, we were informed only recently about the proposal that would need full assessment that takes time. Any new loss of information linked with aggregation of IPV4, would mean less criminals identified and more victims targeted or in life danger. Such losses of information would also conflict with current EU regulatory activities against the "going dark matter" (loss of access to information for LE authorities for judicial purposes). This problem is highly identify at EU level, and I would also prefer to prevent any future misunderstanding between actors in RIPE and EU actors, would the measure be adopted in an hasty way... >From reading your points, I observe that beyond text, is the matter of the real implementation by LIRs and others...we need to clarify and ensure that. Thanks for your understanding and constructive spirit. Regards Emmanuel KESSLER Emmanuel KESSLER Head of Team - Prevention/Outreach Europol - O3 European Cyber Crime Centre (EC3) Eisenhowerlaan 73, 2517 KK The Hague, The Netherlands Phone: [Moderated] / mobile [Moderated] www.europol.europa.eu [cid:image001.png at 01D8169D.5B765D70] -----Original Message----- From: denis walker Sent: 15 December 2023 15:05 To: Jeroen Lauwers Cc: RIPE Address Policy Working Group ; Gert Doering ; Kessler, Emmanuel 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 at gmail.com Hi Jeroen Looking back over this email, there are two things that really stand out to me. "Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way?" "the statement found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy)" These two statements that you made basically sum up this policy proposal. You are suggesting we fundamentally change IPv4 address policy for the 'convenience' of operators and to 'align' some words between two different policies regardless of the consequences. When you add to this a comment Gert made at RIPE 87 when he said that after 30 years we have no clue as to what the "admic-c:" attribute means or why anyone would want to contact them or what they would expect to get from such contact. We have maybe 5 or 6 million inetnum objects in the RIPE Database, a few million inet6num objects and probably tens of thousands of aut-num objects. They all have a mandatory admin-c and we don't know why it is there. All we have is a 30 year old definition that says it must be an on-site contact for the End User in the case of assignment and ASNs. This is a dreadful situation to be in. I suggest that 2023-04 is withdrawn. Then we have a wide reaching consultation with many stakeholder groups who use the RIPE Database. Determine what their needs are for a public registry. What information they need and would like to have in the RIPE Database. Basically do what I expected the last database task force to do, produce a business requirements document for the RIPE Database as a public registry. Then see where we go from there. cheers denis On Wed, 13 Dec 2023 at 19:14, Jeroen Lauwers wrote: > > Dear colleagues, > > Though we recognise that most of you are probably busy preparing for the upcoming holidays, we would like to ask you to share your opinion on proposal 2023-04. Remember that Policy Development Process requires any comments made during the Discussion phase must be repeated during the Review phase in order to count towards or against rough consensus, as your views can now take the RIPE NCC's Impact Analysis into account. > > Here are some questions for the WG to get the discussion started: Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way? Does 2023-04 address this use case well in its current form, or could you think of any potential improvements? > > We hope you will find the time to let your voice be heard! > > The Policy Development Process requires the proposers to adequately address any suggestions for changes or objections to the proposal in each phase, which we will do below. > > 1. Does 2023-04 change the contact registration requirements for assignments? > > > The argument made is that the statement found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy), implicitly requires LIRs to register non-delegated/outsourced contact information for the End User in the RIPE database, not necessarily in the mandatory or attributes, but possibly in an optional attribute like , or . > > Proposers' response: > > We do not believe so, for the following reasons, and keeping the current practice and policies in consideration: > > The RIPE NCC does not consider that 2023-04 changes the contact registration requirements in any way[1][2][3]. Absent any (rough) consensus in the Working Group to the contrary, we defer to the RIPE NCC's judgement on this point. > The practice of creating assignments with all contact information delegated is already widespread. If this was a policy violation made possible due to the RIPE NCC implementing RIPE policy incorrectly, we would have expected the community to take action to correct this situation. However, no such policy proposal has been put forward by the community. > Outsourcing and delegation of contact information is a common practice across many industries, including in networking and information technology. There is no policy language that explicitly prohibits this for IPv4 assignments. Absent that, we believe any implicit prohibition found "between the lines" is essentially [4]. > An obligation to publish the End User's contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User's contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence). > The policy's stated goal of registering assignments is [7]. Requiring LIRs to publish the contact information of End Users who often will not have any knowledge or capability to aid with troubleshooting does work towards this attaining goal. On the contrary, delegating the contact information to the LIR/ISP may well be the only way to attain this goal. > > > [1] > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-Septemb > er/013856.html [2] > https://www.ripe.net/participate/policies/proposals/2023-04#impact-ana > lysis [3] > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-Novembe > r/013892.html [4] https://www.law.cornell.edu/wex/void_for_vagueness > [5] > https://www.ripe.net/manage-ips-and-asns/db/support/documentation/term > s [6] > https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0 > 679#d1e1888-1-1 [7] https://www.ripe.net/publications/docs/ripe-804#3 > > 2. The attribute should be a CIDR prefix length > > Leaving it undefined could result in some LIRs using it to represent an IPv4 address count, while others would use it to represent a CIDR prefix length. > > Proposers' response: > > We agree should be a CIDR prefix length. We understand that, if proposal 2023-04 would be accepted, the RIPE NCC could implement the attribute for IPv4 inetnum objects to be a CIDR prefix length, and document it as such. Therefore we do not believe it is necessary to spell this out explicitly in the policy document (it is not spelled out in the IPv6 policy document either). > > > Thank you for your attention and enjoy your holidays! > > Best regards, > Jeroen and Tore > > > Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara het volgende geschreven: > > > Dear colleagues, > > Policy proposal 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 PA assignments", is now in the Review Phase. > > The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. > > This proposal has been updated and it is now at version 2.0. The proposed policy text did not change, the only difference is that the section "Arguments opposing the proposal" includes a reference to the last round of discussion. > > The RIPE NCC has prepared an impact analysis on this proposal to support the community's discussion. > > You can find the proposal and impact analysis at: > https://www.ripe.net/participate/policies/proposals/2023-04 > https://www.ripe.net/participate/policies/proposals/2023-04#impact-ana > lysis > 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 at ripe.net before 20 December 2023. > > Kind regards, > Angela Dall'Ara > Policy Officer > RIPE NCC > > -- > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://mailman.ripe.net/ > > > -- > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://mailman.ripe.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 1.jpg Type: image/jpeg Size: 1994 bytes Desc: Picture (Device Independent Bitmap) 1.jpg URL: From tore at fud.no Wed Dec 20 16:59:08 2023 From: tore at fud.no (Tore Anderson) Date: Wed, 20 Dec 2023 16:59:08 +0100 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: <4639fc8510133b5631594d238d9e455230e77484.camel@fud.no> References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> <4639fc8510133b5631594d238d9e455230e77484.camel@fud.no> Message-ID: <936fe77d-1be5-449f-a97e-c58803bd62a4@fud.no> Hello again Denis, On 16/12/23 19:53, Tore Anderson wrote: > On Fri, 2023-12-15 at 14:20 +0100, denis walker wrote: >> On Thu, 14 Dec 2023 at 16:34, Tore Anderson wrote: >>> ?As of August 2023, there were 19,221 PA allocations without any child >>> PA assignments held by 10,052 LIRs (?) Since the RIPE Database >>> Requirements Task Force published their report in May 2021, the PA >>> allocations without any child assignment have grown by 18.4 percent.? >> 18.4% of 19,221 is 3536. How many /24 allocations were made in that >> time period that quite likely don't have assignments? > We will ask the RIPE NCC to provide the working group with the updated > statistics you request here. We just received the following response from the RIPE NCC: ?6843 inetnum PA allocations were created since 01-MAY-2021, and 4551 of those (67%) do not have any PA assignments. Please note that this number may include new inetnum objects created from transfers.? Best regards, Tore and Jeroen From ripedenis at gmail.com Wed Dec 20 17:27:54 2023 From: ripedenis at gmail.com (denis walker) Date: Wed, 20 Dec 2023 17:27:54 +0100 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: <936fe77d-1be5-449f-a97e-c58803bd62a4@fud.no> References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> <4639fc8510133b5631594d238d9e455230e77484.camel@fud.no> <936fe77d-1be5-449f-a97e-c58803bd62a4@fud.no> Message-ID: Hi Tore On Wed, 20 Dec 2023 at 16:59, Tore Anderson wrote: > > Hello again Denis, > > On 16/12/23 19:53, Tore Anderson wrote: > > On Fri, 2023-12-15 at 14:20 +0100, denis walker wrote: > >> On Thu, 14 Dec 2023 at 16:34, Tore Anderson wrote: > >>> ?As of August 2023, there were 19,221 PA allocations without any child > >>> PA assignments held by 10,052 LIRs (?) Since the RIPE Database > >>> Requirements Task Force published their report in May 2021, the PA > >>> allocations without any child assignment have grown by 18.4 percent.? > >> 18.4% of 19,221 is 3536. How many /24 allocations were made in that > >> time period that quite likely don't have assignments? > > We will ask the RIPE NCC to provide the working group with the updated > > statistics you request here. > > We just received the following response from the RIPE NCC: > > ?6843 inetnum PA allocations were created since 01-MAY-2021, and 4551 of > those (67%) do not have any PA assignments. Most of these allocations are /24. So if 4551 of these /24 allocations have no assignments, and the increase in allocations without assignments is only 3536, then we actually have more allocations with assignments than we had before, putting aside the /24 allocation issue. So the trend is downwards. The overall number of allocations without assignments is decreasing. cheers denis > > Please note that this number may include new inetnum objects created > from transfers.? > > Best regards, > > Tore and Jeroen > From ripedenis at gmail.com Wed Dec 20 17:50:56 2023 From: ripedenis at gmail.com (denis walker) Date: Wed, 20 Dec 2023 17:50:56 +0100 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> <4f1a3cc1ee654f8f46614a9bf14edc22a4d89a18.camel@fud.no> Message-ID: Hi Peter On Fri, 15 Dec 2023 at 14:33, Peter Hessler wrote: > > On 2023 Dec 15 (Fri) at 14:28:13 +0100 (+0100), Tore Anderson wrote: > :To that end, you might want to submit a policy proposal that would > :clarify for the RIPE NCC what the correct implementation should be, so > :that their procedures are brought in line with your expectations. If > :you do that, we can put 2023-04 on hold pending the outcome of your > :proposal. > : The idea of writing a policy to change the way the RIPE NCC interprets other policies makes no sense. The RIPE community simply needs to request that the RIPE NCC reviews its interpretation of the current address policy and explains it on the list for further community discussion. > > Please don't do that. Denis wishing to change policy should not block > this proposal. I don't want to change policy but keep this part under discussion, as it is right now. > > Additionally, I believe that Denis' proposal on this topic is unlikely to > reach concensous, as you can guess from reading the acrimonious > discussion across several lists. It's a pity many people choose to discuss policy on several (private) lists rather than contribute to the open, transparent, archived discussion on the official address policy list. Maybe someone can sumarise these acrimonious discussions... cheers denis > > > :Best regards, > :Tore and Jeroen > > -peter > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From tore at fud.no Wed Dec 20 18:16:01 2023 From: tore at fud.no (Tore Anderson) Date: Wed, 20 Dec 2023 18:16:01 +0100 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> <4639fc8510133b5631594d238d9e455230e77484.camel@fud.no> <936fe77d-1be5-449f-a97e-c58803bd62a4@fud.no> Message-ID: On 20/12/23 17:27, denis walker wrote: > Most of these allocations are /24. So if 4551 of these /24 allocations > have no assignments, and the increase in allocations without > assignments is only 3536, then we actually have more allocations with > assignments than we had before, putting aside the /24 allocation > issue. So the trend is downwards. The overall number of allocations > without assignments is decreasing. Hello Denis, What do you mean when you say ?the /24 allocation issue?, exactly? Tore From kix at kix.es Wed Dec 20 19:11:54 2023 From: kix at kix.es (=?utf-8?Q?Rodolfo_Garc=C3=ADa_Pe=C3=B1as_=28kix=29?=) Date: Wed, 20 Dec 2023 18:11:54 +0000 Subject: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04 In-Reply-To: References: <437aaa22adc541828c9cbbea5ebaa9a6@europol.europa.eu> <96033fb500e4017acab9cb29b9d18d3565744f15.camel@fud.no> <4639fc8510133b5631594d238d9e455230e77484.camel@fud.no> <936fe77d-1be5-449f-a97e-c58803bd62a4@fud.no> Message-ID: On Wednesday, December 20th, 2023 at 18:16, Tore Anderson wrote: > On 20/12/23 17:27, denis walker wrote: > > > Most of these allocations are /24. So if 4551 of these /24 allocations > > have no assignments, and the increase in allocations without > > assignments is only 3536, then we actually have more allocations with > > assignments than we had before, putting aside the /24 allocation > > issue. So the trend is downwards. The overall number of allocations > > without assignments is decreasing. > > > Hello Denis, > > What do you mean when you say ?the /24 allocation issue?, exactly? > > Tore > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ Hello, I would like to express my opinion. It is a personal opinion and does not represent any organization. I think that the proposal to include the AGGREGATED-BY-LIR option in IPv4 made is very interesting and correct, but I also think that the opinion expressed by Denis and other members of the working group is completely reasonable. I think we should make a modification that all parties agree on. In my opinion, I think we should ask ourselves what is going on and what are the reasons why information is being recorded in the DB in a non-uniform way. In this sense, I believe that the database shows a series of information that can be used to contact IP address holders, but this information is also used to attack organizations, either by identifying address ranges or by phishing and other types of attacks through the exposed means of contact. And for this reason, it is possible that some members may prefer not to register the information (not following the policy), register "anonymous" end-user ranges as LIR's own, etc. In this sense, I think it would be interesting to make a proposal to modify the policy (before or after the 2023-04 proposal), specifying what can and cannot be done, as well as what is recommended. For example, in IPv4, an assignment may be used for a pool of DSL client addresses, in which case the LIR must be registered as the owner, because there is no defined end user. It is logical that in IPv6, where there is a variable prefix length size, AGGREGATED-BY-LIR is used for this type of registration. On the other hand, in IPv4 the policy requires registering a range assigned to an end user as the users's own, but does not include the options for not including end-user information (if so desired) and thus hiding the information from possible attacks, including the netname, contact addresses, etc. Perhaps the only currently valid option is to register it in the name of the LIR, as has been shown with some DB objects. However, using AGGREGATED-BY-LIR for this purpose, I think (in my opinion) is not the right thing to do. I think that if we do not specify what can and cannot be done the database will end up with information that will only indicate the LIR as the user of the addresses. If we are able to specify the specific use of each state of the inetnum objects that includes the needs of all LIRs, the proposal made by Tore and Jeroen to include AGGREGATED-BY-LIR in IPv4 and thus homogenice the inetnum objects of both protocols will be accepted by the majority. Best regards. kix From wusel+ml at uu.org Wed Dec 20 19:26:42 2023 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 20 Dec 2023 19:26:42 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: <85114e07-c57a-4c69-ae18-e85a1fdbbbcf@uu.org> Am 15.12.23 um 15:11 schrieb Peter Hessler: > I still support the proposal as-is. The proposed change does not > weaken any data that is in the database, and in fact may allow it to be > more obvious that these address ranges are used by end users rather than > be unclear what their status is. > > Furthermore, I will state that Denis' objections are not relevant to the > proposal. The proposers, various people on the lists (including myself), > and the RIPE NCC themselves all state the opposite of what Denis is > saying. In addition the proposers have, in my opinion, addressed the > concerns stated. > > -peter +1 Regards, -kai -- "Getdate firmly believes that years after 1999 do not exist; getdate will have to be killed by the year 2000." -- From the "Bugs" section of cnews-020592/libc/getdate.3 From sebastian at karotte.org Thu Dec 21 11:25:06 2023 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Thu, 21 Dec 2023 11:25:06 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: <20231221102506.66c55hhibwr6e4ok@vimes.home.karotte.org> * Angela Dall'Ara [2023-11-21 11:15]: > > Dear colleagues, > > Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA > assignments?, is now in the Review Phase. Still supporting this. Best Regards and Happy Holidays Sebastian -- 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From jlauwers at a2b-internet.com Thu Dec 21 13:06:47 2023 From: jlauwers at a2b-internet.com (Jeroen Lauwers) Date: Thu, 21 Dec 2023 12:06:47 +0000 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: <2BB44D4B-3E82-4841-A269-5E8AFCF08C27@a2b-internet.com> Hi James, Thank you for your message. > I always understood them as a way of recording who/what was using a piece of address space so that you can contact the right organisation in the case of an issue. In this case, there were explicit carve-outs for blocks of dynamic address space so that the ISP could be contacted to determine who was using that particular piece of address space at a single time. > > Where address space was allocated on a more permanent basis the contact details of the end site would be added so the organisation who was trying to address the problem had a direct route to contact that end network. I think in cases of the AGGREGATED-BY-LIR it will be used for LIRs that are also something like an ISP. LIRs that delegate their prefix to another entity would use sub-allocated pa for doing this. Personally, I prefer as an LIR/ISP to use our contact information in the assignments that we also delegate to customers this is because I value knowing what is going on by our customers in matters of technical problems and abuse cases that are using our network and IP space. I am convinced that in this way, we can advise and help our customers better and also solve the problem sooner. > From a technical point of view, it was useful as a reference to be able to work out if several IP addresses in a subnet had been allocated to the same customer or if there was a wider issue. This means that having the assignment size fixed for each block and included in the RipeDB entry is rather important. Is it possible to give a detailed example of this? > This policy appears to take the standard approach for IPv6 and apply it to IPv4 (this is a good thing) it will reduce the number of individual entries in the system (neutral) and hopefully increase the accuracy (a good thing) but at the loss of explicitly including the contact details of the end user site and replacing it with a contact for the LIR (neutral). The last step appears to be the most controversial as it stops people from going directly to the source as it were. > > I think the operational impact here is a potential issue, some LIRs are less than stellar in dealing with requests about things listed in the RipeDB (mostly because of spam) so I can see the concern that some have raised about not being able to get hold of people. However that's not a Ripe issue explicitly but rather a function of the world of capitalism (it's free to send an email, let's send lots of emails, we only need a few people to respond to make money...) > > If we want to fix this problem then maybe we need to add a new capability onto the db that allows authenticated users to contact LIRs about their address space (without using the published contact details) in a way that would allow anti-abuse and LEAs to access the information they need, that is very much not something that needs discussion in the WG because were here to talk about address policy. It would be good if some research would be done on your point of why LIRs become less stellar in dealing with the requests. Is it indeed because of the spam or just because the abuse department is an easy thing to save money on? In both or other cases it is good to see what we can do to improve the situation. I think that AGGREGATED-BY-LIR won?t affect this because a customer next to being portably less technically capable, can just as good save money on their abuse department or be annoyed by the spam as the LIR. > This policy is optional... > > I think people have missed this, from my reading an LIR is not prevented from continuing to put entries without marking them as aggregated so from that point of view if you want to continue to include customer details (and you have their consent) you can still do it. Yes, indeed it is optional. Regards, Jeroen and Tore. From leo at vegoda.org Thu Dec 21 19:36:15 2023 From: leo at vegoda.org (Leo Vegoda) Date: Thu, 21 Dec 2023 10:36:15 -0800 Subject: [address-policy-wg] Extend Review Phase for 2023-04 - "Add AGGREGATED-BY-LIR status for IPv4 PA assignments" Message-ID: 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 From leo at vegoda.org Thu Dec 21 19:37:06 2023 From: leo at vegoda.org (Leo Vegoda) Date: Thu, 21 Dec 2023 10:37:06 -0800 Subject: [address-policy-wg] @EXT: FW: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <969c2e1a10b24f429aff7e99703e2a5f@europol.europa.eu> References: <969c2e1a10b24f429aff7e99703e2a5f@europol.europa.eu> Message-ID: Dear Emmanuel KESSLER, Thank you for participating in the RIPE community. You referenced the 2016 MoU between RIPE NCC and EUROPOL in your most recent comment. It's important to note that this Working Group is a RIPE community activity and not a RIPE NCC activity. The RIPE community is open to participation by anyone and is not a legal entity. The RIPE NCC is the legal entity that provides secretariat services to the RIPE community. We welcome your participation in RIPE's Policy Development Process and input on the current proposal. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs On Wed, 20 Dec 2023 at 03:07, Kessler, Emmanuel wrote: > > Dear all, > > Thanks for the various points provided after my last message of the 13th December. > we are assessing them with our colleagues of the police forces and we have shared with cybersecurity actors the EU. > > From Law enforcement perspective, we would consider highly reasonable that RIPE organises a full consultation with relevant stakeholder groups that use RIPE data basis, to fully assess the impact and their needs. > > Such consultation would be necessary and legitimate as considering the official agreement signed on 2016 between RIPE NCC and EUROPOL that states that both parties, in accordance with their respective mandates, inform each other about the implementation of their respective mandates in the area of cybercrime, inform each other of programmes of potential interest in order to identify possibilities for joint activities and mutual contributions. > As already mentioned, we were informed only recently about the proposal that would need full assessment that takes time. > > Any new loss of information linked with aggregation of IPV4, would mean less criminals identified and more victims targeted or in life danger. > > Such losses of information would also conflict with current EU regulatory activities against the "going dark matter" (loss of access to information for LE authorities for judicial purposes). > This problem is highly identify at EU level, and I would also prefer to prevent any future misunderstanding between actors in RIPE and EU actors, would the measure be adopted in an hasty way? > > From reading your points, I observe that beyond text, is the matter of the real implementation by LIRs and others...we need to clarify and ensure that. > > Thanks for your understanding and constructive spirit. > > Regards > > Emmanuel KESSLER > > Emmanuel KESSLER > > Head of Team - Prevention/Outreach > > Europol - O3 European Cyber Crime Centre (EC3) > > Eisenhowerlaan 73, 2517 KK > The Hague, The Netherlands > Phone: [Moderated] / mobile [Moderated] > > > www.europol.europa.eu > > > > > > > > > > > > -----Original Message----- > From: denis walker > Sent: 15 December 2023 15:05 > To: Jeroen Lauwers > Cc: RIPE Address Policy Working Group ; Gert Doering ; Kessler, Emmanuel > 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 at gmail.com > > > Hi Jeroen > > Looking back over this email, there are two things that really stand out to me. > > "Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way?" > > "the statement ?When an End User has a network using public address space this must be registered separately with the contact details of the End User? found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy)" > > These two statements that you made basically sum up this policy proposal. You are suggesting we fundamentally change IPv4 address policy for the 'convenience' of operators and to 'align' some words between two different policies regardless of the consequences. > > When you add to this a comment Gert made at RIPE 87 when he said that after 30 years we have no clue as to what the "admic-c:" attribute means or why anyone would want to contact them or what they would expect to get from such contact. We have maybe 5 or 6 million inetnum objects in the RIPE Database, a few million inet6num objects and probably tens of thousands of aut-num objects. They all have a mandatory admin-c and we don't know why it is there. All we have is a > 30 year old definition that says it must be an on-site contact for the End User in the case of assignment and ASNs. > > This is a dreadful situation to be in. I suggest that 2023-04 is withdrawn. Then we have a wide reaching consultation with many stakeholder groups who use the RIPE Database. Determine what their needs are for a public registry. What information they need and would like to have in the RIPE Database. Basically do what I expected the last database task force to do, produce a business requirements document for the RIPE Database as a public registry. Then see where we go from there. > > > > > cheers > denis > > > On Wed, 13 Dec 2023 at 19:14, Jeroen Lauwers wrote: > > > > Dear colleagues, > > > > Though we recognise that most of you are probably busy preparing for the upcoming holidays, we would like to ask you to share your opinion on proposal 2023-04. Remember that Policy Development Process requires any comments made during the Discussion phase must be repeated during the Review phase in order to count towards or against rough consensus, as your views can now take the RIPE NCC?s Impact Analysis into account. > > > > Here are some questions for the WG to get the discussion started: Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way? Does 2023-04 address this use case well in its current form, or could you think of any potential improvements? > > > > We hope you will find the time to let your voice be heard! > > > > The Policy Development Process requires the proposers to adequately address any suggestions for changes or objections to the proposal in each phase, which we will do below. > > > > 1. Does 2023-04 change the contact registration requirements for assignments? > > > > > > The argument made is that the statement ?When an End User has a network using public address space this must be registered separately with the contact details of the End User? found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy), implicitly requires LIRs to register non-delegated/outsourced contact information for the End User in the RIPE database, not necessarily in the mandatory ?admin-c? or ?tech-c? attributes, but possibly in an optional attribute like ?descr?, ?org? or ?remarks?. > > > > Proposers? response: > > > > We do not believe so, for the following reasons, and keeping the current practice and policies in consideration: > > > > The RIPE NCC does not consider that 2023-04 changes the contact registration requirements in any way[1][2][3]. Absent any (rough) consensus in the Working Group to the contrary, we defer to the RIPE NCC?s judgement on this point. > > The practice of creating assignments with all contact information delegated is already widespread. If this was a policy violation made possible due to the RIPE NCC implementing RIPE policy incorrectly, we would have expected the community to take action to correct this situation. However, no such policy proposal has been put forward by the community. > > Outsourcing and delegation of contact information is a common practice across many industries, including in networking and information technology. There is no policy language that explicitly prohibits this for IPv4 assignments. Absent that, we believe any implicit prohibition found ?between the lines? is essentially ?void for vagueness?[4]. > > An obligation to publish the End User?s contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User?s contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence). > > The policy?s stated goal of registering assignments is ?to ensure uniqueness and to provide information for Internet troubleshooting at all levels?[7]. Requiring LIRs to publish the contact information of End Users who often will not have any knowledge or capability to aid with troubleshooting does work towards this attaining goal. On the contrary, delegating the contact information to the LIR/ISP may well be the only way to attain this goal. > > > > > > [1] > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-Septemb > > er/013856.html [2] > > https://www.ripe.net/participate/policies/proposals/2023-04#impact-ana > > lysis [3] > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-Novembe > > r/013892.html [4] https://www.law.cornell.edu/wex/void_for_vagueness > > [5] > > https://www.ripe.net/manage-ips-and-asns/db/support/documentation/term > > s [6] > > https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0 > > 679#d1e1888-1-1 [7] https://www.ripe.net/publications/docs/ripe-804#3 > > > > 2. The ?assignment-size? attribute should be a CIDR prefix length > > > > Leaving it undefined could result in some LIRs using it to represent an IPv4 address count, while others would use it to represent a CIDR prefix length. > > > > Proposers? response: > > > > We agree ?assignment-size? should be a CIDR prefix length. We understand that, if proposal 2023-04 would be accepted, the RIPE NCC could implement the ?assignment-size? attribute for IPv4 inetnum objects to be a CIDR prefix length, and document it as such. Therefore we do not believe it is necessary to spell this out explicitly in the policy document (it is not spelled out in the IPv6 policy document either). > > > > > > Thank you for your attention and enjoy your holidays! > > > > Best regards, > > Jeroen and Tore > > > > > > Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara het volgende geschreven: > > > > > > Dear colleagues, > > > > Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA assignments?, is now in the Review Phase. > > > > The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. > > > > This proposal has been updated and it is now at version 2.0. The proposed policy text did not change, the only difference is that the section "Arguments opposing the proposal" includes a reference to the last round of discussion. > > > > The RIPE NCC has prepared an impact analysis on this proposal to support the community?s discussion. > > > > You can find the proposal and impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2023-04 > > https://www.ripe.net/participate/policies/proposals/2023-04#impact-ana > > lysis > > 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 at ripe.net before 20 December 2023. > > > > Kind regards, > > Angela Dall'Ara > > Policy Officer > > RIPE NCC > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > > change your subscription options, please visit: > > https://mailman.ripe.net/ > > > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > > change your subscription options, please visit: > > https://mailman.ripe.net/ > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From khung at ripe.net Fri Dec 22 10:24:33 2023 From: khung at ripe.net (Karen Hung) Date: Fri, 22 Dec 2023 10:24:33 +0100 Subject: [address-policy-wg] 2023-04 Extended Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Message-ID: Dear colleagues, The policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA assignments? is now in the extended Review Phase. 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 at ripe.net before 18 January 2024. Kind regards, Karen Hung On behalf of Policy Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: