Search results for "2023-04" - address-policy-wg

Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?

by Nick Hilliard

denis walker wrote on 28/09/2023 11:31: > We are talking about one sentence in the current address policy that > this proposal removes. that's ok: the RIPE Community is entitled to voice an opinion on changing RIPE policy. If this policy nullifies the requirement to register end-user PA assignments in the RIPE DB, I don't necessarily view this as a bad thing, given the poor quality of the existing data, and the fact that fixing this is - whether we accept this or not - a largely intractable problem. That said, it's important that any change of this scope should be done with the community's eyes open so that we can make an informed decision based on merit. Nick

2 years, 4 months

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

by Randy Bush

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

2 years, 1 month

[Moderated]

by unknown＠example.com

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

2 years

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Edward Shryane

Hi Tore, > On 29 Nov 2023, at 13:33, Tore Anderson <tore(a)fud.no> wrote: > ... > > (I also suggest that while the NCC is at it, they should document > assignment-size as being a CIDR prefix length for inet6num as well. As > you point the formal definition is not crystal clear there either, > which was a bit of a surprise to me, honestly. But all current inet6num > objects have an assignment-size within the range 31-128, so I guess > LIRs simply get it - unless the database software enforces it by > rejecting updates with values above 128.) > > Tore > I confirm that the verbose help text for "assignment-size:" currently states: assignment-size Specifies the size of blocks assigned to end users from this aggregated inet6num assignment. Specifies a numeric value. We will update the text to include CIDR prefix length for inet6num. Regards Ed Shryane RIPE NCC

2 years, 2 months

Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status

by Tore Anderson

* Brian Storey > I only have a short window to reply, however I would clarify that I fall in > to the " Registering a PA Assignment with something like "CUSTOMER-1234" and > an email address pointing to the LIR has been acceptable for all this > time.»" category. I am therefore looking at this through the lens of this > approach. > > In which-ever form the end user is illustrated, it's the total permitted > absence of that which is the surprise; Unless I have misunderstood the > recently shared RIPE NNC interpretation. Hi again Brian, To be clear, "CUSTOMER-1234" above was not meant to be substituted with the actual name of the customer, but rather taken as verbatim netname attribute value. While one may infer from that string that it is indeed a customer assignment (as opposed a self-assignment to the LIR's own infrastructure), as well as revealing a possible customer account number, even those bits of information are optional to include. Below you will find an example of a complete inetnum object representing an assignment to the End User «CarFactory GmbH» by the LIR «SuperLIR GmbH», which RIPE NCC explicitly confirmed to be compliant with current address policy (see https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01…) 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 If you, or anyone else, want to "minimise" your assignments as shown in the above example, you can do so already today. It is already considered accepted practice and has been for decades. 2023-04's fate is totally irrelevant as to whether or not you or any other LIR can adopt this practice, assuming you want to. Best regards, Jeroen & Tore

1 year, 9 months

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Tore Anderson

Hello again Jan, On 10/01/24 11:25, Jan Ingvoldstad wrote: > Basically, any public company register would be illegal according to > the interpretation you lean on here. Public company registries also need a lawful basis for processing. The Norwegian public company registry, for example, uses the lawful basis «exercise of official authority» – Article 6(1)(e) GDPR – as its lawful basis, see https://www.brreg.no/en/privacy-statement/. I would assume that to be the case in most other countries as well. (Most) LIRs are not official authorities, so unlike public company registries LIRs cannot use this lawful basis for publishing PII in the RIPE Database. In any case, all of this is rather off-topic. 2023-04 does not change the legal obligations on the LIRs relating to the publication of End User contact information, nor does it change the RIPE Database Terms and Conditions. If you want to publish PII in the RIPE Database, you need a lawful basis. That's true today, and that will continue to be true if 2023-04 passes. > Or you could take the other stance and stop publishing *any* contact > details regarding an object, because you cannot know whether the > information is personal data or not. Exactly. LIRs may (but are not required to) chose this approach already *today*. This is a common and long-standing practice which the RIPE NCC has repeatedly clarified as compliant with today's policy. It will continue to be compliant with the policy after 2023-04 passes, as well. Thus, 2023-04 effects no change on the LIRs' obligations in this regard. > I think that because the WG discussion has almost exclusively revolved > around this alleged changing of policy requirements to publish End > User contact information (which may or may not be PII), it is easy to > lose track of what this proposal is *actually* all about. We are > talking about two different things: > > 1) The actual intention behind the proposal: Making it possible to > aggregate multiple IPv4 End User assignments that have consistent > contact information and purpose into a single database object. > This is not possible today, and that is what we want to make that > possible, in the same way it is already possible in IPv6. > > 2) The *alleged* change to what kind of End User contact > information is required to be published in the RIPE database. We > have never had any intention of changing this in any way, and the > Impact Analysis and other statements from the RIPE NCC confirm > that the proposal does not change it either. > > In short: 1) is an intentional and desired change from today, > while 2) is *not* a change from today – intentionally so. > > This (regarding item 2) is simply not true. Any change in text *is a > change*. We are not making the claim that the policy text does not change. That it clearly does – in order to achieve the desired change described in item 1 above. We are however claiming that the *meanings* of the old and the new policy texts are exactly the same, with regards to how they translate into operational procedures and requirements for the publication of End User contact information (item 2). As the RIPE NCC writes in the Impact Analysis (emphasis added): «Acceptance of this proposal **will not change** the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this **will remain** their decision.» So, once again: which End User contact details LIRs publish (if any) is their decision today, and it will be continue to be their decision if 2023-04 passes. Hence, 2023-04 does not effect any change in this regard. > So maybe we could discuss 1) instead of 2) going forward? :-) > > I have no problem with 1), as already stated. We're happy to hear that! > I do agree with you that this is distracting from the proper meat of > your proposal. Which is why I suggest that you drop this part of it. > Again, drop the part of the proposal that people have a beef with. > > Don't make the change that you claim is not a change. This «beef» is based on reading current policy to mean that which End User contact details LIRs publish in the database (if any) is *not* the LIRs' decision today. But the RIPE NCC has repeatedly clarified that that is simply not the case: it *is* the LIRs' decision today, and it will continue to be LIRs' decision should 2023-04 pass. Given that, it is hard to see how we could possibly amend the proposal to change this particular point to an even lesser extent than what is already the case? Tore & Jeroen

2 years

Last Call - 2023-04 (Add AGGREGATED-BY-LIR status

by Leo Vegoda

Dear Address Policy WG, There was a consensus on this proposal and we are moving it forward to Last Call. The RIPE NCC will publish an announcement with dates. There was a request, in Rome, for clarity over whether aggregated assignments needed to have a fixed size or could vary. The proposers suggested that a fixed size should be optional. We extended the list discussion by a month and the two issues raised have been addressed. One was End User sites not having the End User's own admin-c instead of the LIR's. There has been extensive discussion of this. One key reason given is that it is common and acceptable to outsource a part of an organisation's operations to another, more skilled, operator. The RIPE NCC's impact analysis noted that the proposal "simply leaves the status quo unchanged." It would not need to update its operational processes. Concerns were also raised that aggregating assignments would impact criminal investigations. But this proposal is intended to improve the quality of data registered by offering LIRs a less arduous way to share registration data. At the end of 2023 there were over 19,000 PA allocations without any assignments. Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

1 year, 10 months

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Sebastian-Wilhelm Graf

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/01… > <https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01…> > [2] > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > <https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis> > [3] > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013… > <https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013…> > [4] https://www.law.cornell.edu/wex/void_for_vagueness > <https://www.law.cornell.edu/wex/void_for_vagueness> > [5] > https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms > <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#d… > <https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d…> > [7] https://www.ripe.net/publications/docs/ripe-804#3 > <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 <adallara(a)ripe.net> >> 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(a)ripe.net >> before 20 December 2023. >> >> Kind regards, >> Angela Dall'Ara >> Policy Officer >> RIPE NCC >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or >> change your subscription options, please visit: >> https://lists.ripe.net/mailman/listinfo/address-policy-wg > >

2 years, 1 month

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Tore Anderson

Hi Denis, On 11/01/24 03:20, denis walker wrote: > On Wed, 10 Jan 2024 at 13:02, Tore Anderson <tore(a)fud.no> wrote: >> >> On 10/01/24 11:25, Jan Ingvoldstad wrote: >>> Or you could take the other stance and stop publishing *any* contact >>> details regarding an object, because you cannot know whether the >>> information is personal data or not. >> Exactly. LIRs may (but are not required to) chose this approach already >> *today*. This is a common and long-standing practice which the RIPE NCC >> has repeatedly clarified as compliant with today's policy. > This is one of your biggest false statements. The ONLY person > repeatedly saying this is YOU. Let's do a fact check here. Yes, let us indeed do a fact check: Exhibit 1: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01… Exhibit 2: https://www.ripe.net/participate/policies/proposals/2023-04 (specifically the «counter-argument», which the RIPE NCC Policy Officer confirmed to the proposers and the WG chairs as correctly representing the RIPE NCC's interpretation) Exhibit 3: https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis Exhibit 4: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013… Four repetitions so far, all saying the same thing. How many more do you need? We note that you have requested further clarifications from the RIPE NCC tonight, which we of course look forward to. > This is total madness. You keep saying you have no intention of > changing anything else. You keep saying the wording change actually > changes nothing in practice. Some other people don't agree with you. > Just don't change wording that you claim changes NOTHING and has > nothing to do with aggregation and everyone is happy. The fact that > you are pushing so hard to make this wording change, you refuse to > back down or compromise, you insist on changing wording that changes > nothing and has nothing to do with aggregation...proves that you don't > believe that yourself. The fact is, I suspect that this is the real > change you want. You want to drop the current policy requirement to > define assignments with End User contacts. It is the aggregation that > is the side issue here. There is no other explanation for why you are > insisting so strongly on changing wording that changes nothing. Here we find ourselves in conspiracy theory land, frankly. It makes zero sense, too: If our ulterior goal was to remove the End User contacts from our own assignments we can just go ahead and do so, right now. The RIPE NCC is already on the record saying that's totally OK, and we would be following in the footsteps of many other LIRs who have already done so. Why on Earth would we waste our time on a policy proposal? If our ulterior goal was to remove the End User contacts from other LIRs' assignments, 2023-04 simply doesn't accomplish this goal, because it conveys no requirement on LIRs to remove anything from the database whatsoever. The RIPE NCC has not identified any unintended or ulterior side effect caused by 2023-04 either, does that mean they are a part of the conspiracy too? >> As the RIPE NCC writes in the Impact Analysis (emphasis added): >> >> «Acceptance of this proposal **will not change** the fact that the >> RIPE NCC cannot enforce which contact details members add to their IPv4 >> PA assignments in the RIPE Database; this **will remain** their decision.» >> >> So, once again: which End User contact details LIRs publish (if any) is >> their decision today, and it will be continue to be their decision if >> 2023-04 passes. Hence, 2023-04 does not effect any change in this regard. > This really does make me cry. The wording in the IA is poor. You have > applied an interpretation to this which I do not believe is what was > meant. Then the RIPE NCC legal team has remained silent. So I am > asking the RIPE NCC legal team to clearly explain what they meant by > this wording. The explanation you request was posted two days after the Impact Analysis was: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013… «LIRs are free to choose how to provide services and to who, this includes their freedom to take over the responsibility as the point of contact for their End User as well as having their maintainer in the IPv4 PA assignments they register.» This explanation aligns perfectly with our interpretation of the statement in the Impact Analysis. >> Given that, it is hard to see how we could possibly amend the proposal >> to change this particular point to an even lesser extent than what is >> already the case? > Let me help you. Do NOT remove a sentence that has nothing to do with > the stated goal of the proposal to aggregate assignments and that you > claim does not change anything. This sentence also has a lot to do with the stated goal of aggregating assignments, because it mandates that assignments must be «registered separately». That is clearly incompatible with aggregation. It would of course be possible to retain the old sentence as-is by combining it with the new one copied from the IPv6 policy by using an either/or construct, e.g.: «When an End User has a network using public address space this must be registered separately with the contact details of the End User or by inserting an object with a status value of 'AGGREGATED-BY-LIR'». That said, the actual policy outcome would as far as we can tell be exactly the same as 2023-04 in its current form, so we assume you would object to this language as well? Tore & Jeroen

2 years

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

by Tore Anderson

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

2 years, 1 month

address-policy-wg search results for query "2023-04"