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

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

by denis walker

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 <jlauwers(a)a2b-internet.com> 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/01… > [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/013… > [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#d… > [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 <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 > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

1 year, 5 months

Re: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26)

by Carlos Friaças

Greetings, I would like to express my support to this proposal, as it aims to extend the usability of the IXP reserved pool, without any impact on operations of new IXPs. Regards, CArlos On Wed, 24 May 2023, Tore Anderson wrote: > On Mon, 2023-04-24 at 09:01 +0200, Angela Dall'Ara wrote: > >> The policy proposal 2023-01, "Reducing IXP IPv4 assignment default >> size to a /26" is now in the extended Discussion Phase. >> >> This proposal modifies the default size of IPv4 assignments for IXPs >> from a /24 to /26 and clarifies the return of the assignments >> previously issued for their IXP peering LAN. > > I believe this proposal is a step in the right direction, so I support > advancing it to the review phase. > > Tore > > -- > > 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

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

by Cynthia Revström

I think I mostly agree with Nick here and I feel like Tore is a bit dismissive of the concerns raised by denis. I don't really feel that strongly about this policy proposal in itself but I do now see that it is a significantly larger change than Tore suggests that it is. I wouldn't be surprised if more people who have said "+1" to this proposal did so without realizing that it's not such a minor change. As such, I really think that there needs to be more discussion about this in the context of changing a meaningful part of the policy. -Cynthia P.S. I want to make it clear that I don't think that Tore is being malicious in any way here but rather just focusing too much on the current RIPE NCC interpretation of the policy rather than what the policies actually say. On Fri, Sep 29, 2023 at 3:46 PM Nick Hilliard <nick(a)foobar.org> wrote: > > 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 > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

1 year, 8 months

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

by Sebastian-Wilhelm Graf

Dear Denis! I strongly disagree on this notion of derferring everything to the "higher power" of RIPE. If we want a solution that integrates with IPAM Systems, then we (the community) should organise that, preferably systems that are "open" by design/license. And if only a minority of the community wishes for such a solution, then only said minority should fund that development. Especially if the benefit is mostly towards external commercial organisations.... I also reject the notion that just because the "tooling" is there (theoretically), that the accuracy would improve. But that is a disucssion further up in this thread. And personally i think aggregated-by-lir makes a ton of sense. cheers On 9/28/23 10:50, denis walker wrote: > Hi Nick > > I feel your pain on this one. I can understand that no LIR wants to > invest time or money in developing this as a one off, in-house > solution. Something like this needs to be done at a higher level. > That's why you pay fees to the RIPE NCC. They should be talking to the > developers of the commercial IPAM systems about syncing with the RIPE > Database. Whether or not it could be done with the current data model > and software I don't know. But it is time to consider these things. > > cheers > denis > co-chair DB-WG > > > On Wed, 27 Sept 2023 at 22:57, Nick Hilliard <nick(a)foobar.org> wrote: >> denis walker wrote on 24/09/2023 17:12: >>> So are you saying >>> that in 2023 we can't manage a distributed database without >>> overwhelming repetitive tasks? >> yes, correct. People are stuck using the tools that they have. Most >> off-the-shelf tools don't implement server-client or 2way database >> synchronisation between the local ipam system and the ripe db, and >> there's ~zero financial inventive to build this sort of functionality >> in-house. The outcome is that the ripedb ends up with manual updates, or >> else with low quality / 1-way synchronisation with little or no cleanup. >> >> The result of this is that the ASSIGNED-PA objects in the ripedb are >> generally of low average accuracy. >> >> Nick

1 year, 8 months

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

by Tore Anderson

Hello Denis, On 11/01/24 01:40, denis walker wrote: > So personal data does not always need consent of the data > subject. But you only ever refer to (a) consent. There are indeed other possible lawful bases than consent, and this fact is precisely why I wrote (emphasis added): «Publishing this information requires *a* lawful basis, *e.g.*, consent.» Consent is however the only lawful basis singled out by the RIPE NCC in the RIPE Database Terms and Conditions and in the 2023-04 Impact Analysis, so it seems reasonable to assume that some LIRs will seek consent. Therefore we need to examine what that actually means in practice. You sum it up quite accurately below: > If we take the latest revelation in the IA on 2023-04, ALL PII needs > consent, this has HUGE implications for the RIPE NCC and RIPE policy > generally. We MUST have a good understanding of the legal basis for > entering PII into the RIPE Database. Consent cannot be conditional. So > if a resource holder who is a natural person withdraws their consent > to have their PII in the database, it MUST be removed. That may leave > an allocation and organisation with no identity or contacts. That > would be a policy violation. BUT the resource cannot be reclaimed as > that would have made the consent conditional. Also we have an abuse > policy that requires all resources to have an abuse contact. If that > contact is a natural person and they withdraw their consent their > details must be deleted. Again that creates a policy violation. But > the resource cannot be reclaimed again as that would have made the > contact details consent conditional. Your conclusion that this situation results in a policy violation, is however entirely contingent on your interpretation of the current policy as mandating the publication of the End User's (non-delegated) contact information. Under the RIPE NCC's interpretation of the current policy, on the other hand, this situation is entirely unproblematic. Under their interpretation, the LIR has, quote, «freedom to take over the responsibility as the point of contact for their End User». No PII, no GDPR, no problem. https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013… > Again you have selected just one example that can support your > argument, Farmer Fred. I could have used KPN or Apple Inc as an > example which would negate your argument. KPN or Apple would not be relevant examples, as they (presumably) would use non-personal NOC roles which are not PII, and thus out of scope of the GDPR. There are certainly many End Users whose contact information is not PII, but that does not «negate» the fact that there are also many End Users whose contact information *is* PII. Both types of End Users must be catered to by the address policy. Tore & Jeroen

1 year, 4 months

Re: [address-policy-wg] Draft Address Policy WG Agenda for RIPE 87, Rome

by Leo Vegoda

Hi, We have updated the agenda again. We have a new item G: Our Policy Development Process – the implementation Kind regards, Leo Session 1 starts: 09:00 A. Introduction [5 min] B. Chair Selection [10 min] C. NRO NC / ICANN ASO AC Update [10 min] Hervé Clement and/or Sander Steffann D. Registry Services Update Followed by Q&A [15 min] Marco Schmidt, RIPE NCC E. Policy Update Followed by Q&A [15 min] Angela Dall'Ara, RIPE NCC F. Discussion: What is the purpose of IPv4 assignment registration in 2024? [30 mins] [co-chairs to show 1 discussion slide] Session 1 ends: 11:00 ☕ Session 2 starts: 11:30 G. Our Policy Development Process – the implementation H. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins] Jeroen Lauwers, A2B Internet Tore Anderson, Redpill Linpro I. The Future of IPv6 Policy [25 mins] Introdicuing ideas for change and setting priorities (Discussion) On Mon, 20 Nov 2023 at 16:04, Leo Vegoda <leo(a)vegoda.org> wrote: > > Hi, > > Here's an updated agenda. Item H has changed to a broader discussion. > > Kind regards, > > Leo > > Session 1 starts: 09:00 > > A. Introduction [5 min] > > B. Chair Selection [10 min] > > C. NRO NC / ICANN ASO AC Update [10 min] > Hervé Clement and/or Sander Steffann > > D. Registry Services Update Followed by Q&A [15 min] > Marco Schmidt, RIPE NCC > > E. Policy Update Followed by Q&A [15 min] > Angela Dall'Ara, RIPE NCC > > F. Discussion: What is the purpose of IPv4 assignment registration in > 2024? [30 mins] > [co-chairs to show 1 discussion slide] > > Session 1 ends: 11:00 > > ☕ > > Session 2 starts: 11:30 > > G. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins] > Jeroen Lauwers, A2B Internet > Tore Anderson, Redpill Linpro > > H. The Future of IPv6 Policy [25 mins] > Introdicuing ideas for change and setting priorities > (Discussion) > > I. AOB [10 mins] > > Session 2 ends: 12:30 > > On Thu, 9 Nov 2023 at 11:57, Leo Vegoda <leo(a)vegoda.org> wrote: > > > > Hi, > > > > Here is our draft agenda for Rome. > > > > We can make refinements if needed, so please contact the chairs if you > > would like us to add or change something. > > > > Kind regards, > > > > Leo > > > > Session 1 starts: 09:00 > > > > A. Introduction [5 min] > > > > B. Chair Selection [10 min] > > > > C. NRO NC / ICANN ASO AC Update [10 min] > > Hervé Clement and/or Sander Steffann > > > > D. Registry Services Update Followed by Q&A [15 min] > > Marco Schmidt, RIPE NCC > > > > E. Policy Update Followed by Q&A [15 min] > > Angela Dall'Ara, RIPE NCC > > > > F. Discussion: What is the purpose of IPv4 assignment registration in > > 2024? [30 mins] > > [co-chairs to show 1 discussion slide] > > > > Session 1 ends: 11:00 > > > > ☕ > > > > Session 2 starts: 11:30 > > > > G. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins] > > Jeroen Lauwers, A2B Internet > > Tore Anderson, Redpill Linpro > > > > H. Improving IPv6 PI Policy [25 mins] > > Tobias Fiebig > > > > I. AOB [10 mins] > > > > Session 2 ends: 12:30

1 year, 6 months

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

by Michele Neylon - Blacknight

Tore Thanks for the clear explanation of the use case. The proposal seems to be “sane” so, unless somene can point out a fundamental flaw with it, we’d be supportive. 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 <address-policy-wg-bounces(a)ripe.net> on behalf of Tore Anderson <tore(a)fud.no> Date: Monday, 4 September 2023 at 12:21 To: Andrii Syrovatko <andrey_syrovatko(a)trifle.net>, address-policy-wg(a)ripe.net <address-policy-wg(a)ripe.net>, adallara(a)ripe.net <adallara(a)ripe.net> Cc: APEX NCC ORG <registry(a)apex.dp.ua>, Trifle NOC <noc(a)trifle.net> Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) [EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources. * APEX NCC ORG > Hello, Team! > I read the offer provided: > https://www.ripe.net/participate/policies/proposals/2023-04 > three times. > However, I still don't understand the real reason for introducing the > AGGREGATED-BY-LIR status > The text of the proposal contains only general provisions. > Can you provide a more detailed description and examples? Hi Andrii! There are several possible examples, but let me give you just one: Let's say you're a small cloud VPS provider in the business of leasing out virtual machines to small businesses and private individuals. Your cloud management software dynamically assigns IPv4 addresses out of 192.0.2.0/24 to customers, so you have for example: 192.0.2.1/32 = assigned to Alice's first VM - used for a web server 192.0.2.2/32 = assigned to Bob - used for a Minecraft server 192.0.2.3/32 = assigned to Bob's hair salon business = web server 192.0.2.4/32 = assigned to Alice's second VM - mail server …and so on. Current policy requires you to register four individual INETNUM assignments of size /32 for the above four virtual machines. However, due to the GDPR requirements, you usually cannot put Alice's and Bob's names or contact info into the RIPE database, so instead you typically substitute your own (this is allowed by policy). That means you have now four individual INETNUMs with identical contact information (your own). You need to add or remove these /32 INETNUMs as customer VMs come and go. You can automate this, but it is a pointless exercise in any case. To avoid this, we propose allowing you to create a single INETNUM that covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can already do with any IPv6 assignments made to the same VMs. This aggregated object will cover all customer VMs in your cloud infrastructure, present and future, and makes it so that you don't have to send a RIPE database update every time a customer VM is provisioned or discontinued. Tore -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

1 year, 9 months

Re: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26)

by Tore Anderson

On Mon, 2023-04-24 at 09:01 +0200, Angela Dall'Ara wrote: > The policy proposal 2023-01, "Reducing IXP IPv4 assignment default > size to a /26" is now in the extended Discussion Phase. > > This proposal modifies the default size of IPv4 assignments for IXPs > from a /24 to /26 and clarifies the return of the assignments > previously issued for their IXP peering LAN. I believe this proposal is a step in the right direction, so I support advancing it to the review phase. Tore

2 years

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

by Jeroen Lauwers

Hi Emmanuel, > The matter is the loss of opportunities of identification that will vanish for investigators... This is a subject that has been covered extensively during the previous two phases of the policy development process and is as such is already addressed, but we will summarise the main points below for your convenience. During the previous discussion of 2023-04 it has been made adamantly clear by the RIPE NCC that any information inserted into the RIPE database that identifies the End User is inserted voluntarily by the LIR. There exists no policy requirement that compels LIRs to publish the identities of their End Users, this is simply an option that some LIRs avail themselves of. It is important to realize that the policy proposed by 2023-04 does not in any way whatsoever restrict or prohibit LIRs from voluntarily publishing the identities of their End Users in the RIPE database. LIRs that have a policy to do so today, will be able to continue to do so in the future in the exact same way after 2023-04 is implemented. Indeed, these LIRs are free to ignore 2023-04 completely – 2023-04 does not deprecate or remove the ASSIGNED PA inetnum status, it may still be used as before. It follows logically that 2023-04 does not cause any loss of End User identification. Investigators may continue to look up IP addresses in the RIPE database, but whether or not it will yield the End User's identity (as opposed to «a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR», as the working group chairs put it) will depend entirely on the issuing LIR's policies and procedures, just as it does under today. For a demonstration of this taking place in practice, take a look at the IPv6 part of the RIPE database. The AGGREGATED-BY-LIR status has been available for inet6num objects since forever, but this has not prevented LIRs from to registering their End User assignments using the ASSIGNED status instead, often including the End User's identity, contact information, and other optional details. There is no reason to expect that this will be any different in IPv4 following the implementation of 2023-04, as we see it. Best regards, Jeroen & Tore > Op 7 apr 2024, om 17:45 heeft Kessler, Emmanuel <Emmanuel.Kessler(a)europol.europa.eu> het volgende geschreven: > > Dear All, > I would have some comments about the previous points that mentions Europol > Thanks for your cooperation spirit > Regards > Emmanuel Kessler > > -----Original Message----- > From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> On Behalf Of Kai 'wusel' Siering via address-policy-wg > Sent: vendredi 5 avril 2024 21:41 > To: address-policy-wg(a)ripe.net > Subject: Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status > > Moin, > > am 05.04.24 um 16:51 schrieb denis walker: >> I used to wonder why no one >> would even talk about bringing the RIPE Database into the modern >> world. > Because this is address-policy (»The Address Policy Working Group develops policies relating to the management and registration of Internet number resources.«), not database (»The Database Working Group deals […]«). > >> Europol has expressed serious concerns about these changes. > Europol has the means to challenge the maintainer of the address space for more information on individual usage; there is no real thread to Europol's operation by the change, it might just become less convenient to get the wanted information. > > --> Sorry, but reading this, I observe that you may indeed have only a fuzzy/limited idea of what Europol does, and the impact on LE operations.. > As knowing the scope of Europol and digital investigation (we work here), we repeat that the matter is not only being less convenient. The matter is the loss of opportunities of identification that will vanish for investigators... > > > >> If someone had informed them earlier >> of the changes being considered that may affect them, > Well, this is happening all in the open. IF Europol is depending so greatly on the RIPE DB, they SHOULD be following the PDP already for years and years and voiced their concerns more timely. > > --> the matter is not just Europol, but the impact on investigations of LE services....Europol has been regularly well active in various working groups of RIPE... > Please consider that capacities of investigators are impacted by a large number of negotiation processes : at E-governance level (ICANN, RIPE,..), UN treaties, Council of Europe conventions, numerous EU legislations (Nis2, E-evidence package, DSA,...), national levels ones... (and I may forget some..?!).... > linked with judicial cooperation frameworks, companies regulations, cybersecurity actors, technological standards in permanent evolution, .... The number of working groups, regulations, proposals, legal acts, is the most consequent...it is a "jungle" of processes that have to be covered,...you can believe me... > in spite of the efforts of our committed people, we are unfortunately not omniscient an always present everywhere....(nobody is...!). As in all organisations, capacities are not infinite and we have sometimes to prioritize those we have, under emergencies and the various agendas.. > > ...but whatever the raised questions, THE relevant question is overall that a joint work in open spirit is THE best way...beyond considering the only question of a seat gap at a moment... --> The matter should remain in the end, which impact (positive/negative...) ? > when all know new popping processes from the beginning, it allows to formalize swiftly a full knowledge about impact, and prevent 2 undesirable ends that are : wasting time on a proposal that should be given up/ or persisting on the difficult adoption of a measure that will bring damage on victims protection... > > we can do great job to secure digital space, (just see Lockbit and the latest operations against ransomwares : https://www.europol.europa.eu/media-press/newsroom?q=cyber ) including protecting private sector and companies that are essential for business and the economic health of our countries, > but if we lose the access to data, it means less operational achievements/ and criminals being more in capacity to target companies and peoples, who still "pay the bill" of crimes... > > > >> proceed with all haste to > No haste visible at all; this is about 2023-04 — we already are in 2024-04. > > Regards, > -kai > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

1 year, 1 month

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

by Tore Anderson

* Brian Storey: > There is a subtly here which I don't think is fully appreciated. > > I previously highlighted my surprise to the RIPE NNCs interpretation > of the existing policy; as have others. Why is that? I think it's very > important to recognise that LIRs act and publish certain End User data > because it was deemed that this was a requirement and that not doing > so could see a breach of policy, therefore leading to Allocated PAs > being reclaimed - not good with scarce resources! They did this > because they understood they HAD to not because they WANTED to. > > If this school of thought no longer applies, then it is reasonable to > expect that some will reevaluate how much effort they continue to put > in and the consequences of that. Hi Brian, We have certainly no difficulty understanding that you and others might have not been aware of this before. But now you are, and so is anyone else that are following the RIPE policy development process. The cat is out of the bag, so to speak. Withdrawing 2023-04 would not undo this, because this is not a property of the proposal itself, but knowledge of the of the RIPE NCC's interpretation of the *current* address policy. Or as the working group chairs put it: «It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time.» Furthermore, it is clear that this comes as no surprise at all to many LIRs, who have done this for a long time. Again quoting the working group chairs: «…changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects» https://www.ripe.net/ripe/mail/archives/address-policy-wg/2024-January/0139… > The two questions I previously posed here: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01… > were:- > > "For me it comes down to this. As a community & considering the permitted > exceptions (individuals & P2P assignments):- > > 1) Is the publication of End User entities for an assignment important? Perhaps, perhaps not. That is for the working group to decide. It is however outside the scope of 2023-04. Again quoting the working group chairs from the previously linked-to message: «…we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one». > 2) Is the publication of a prefix assignment boundary between end users > important?" We address this question in the proposal itself, see https://www.ripe.net/membership/policies/proposals/2023-04/#12-differences-…. The gist of it is that since IPv4 assignments tend to be right-sized (rather than gigantic "one size fits all" prefixes like in IPv6), and that there is no HD-Ratio that needs calculating, we found it more appropriate to leave the assignment-size attribute optional. > Now, I've not commented since (for various reasons), however I have > followed the discussion of this closely. Internally, I've been > highlighting that a Business Risk item based on previous > interpretation could evolve and how we manage our exposure changes if > this proposal become policy. What this means in reality is that we can > choose how much effort we continue to place on updating our > Assignments as the end user customer base churns. There are end > customers who like their association to a PA Assignment to be > published and there are those who don't. It may well be easier for me > only publish by exception. I'm still thinking it through pending what > happens next with a few other indirect considerations. > > I don't believe I'll be the only one doing this. You and everyone else can do this right now. You do not need to wait for the possible acceptance of 2023-04. As mentioned above, you have in fact been free to do this «since at leas [sic] the late 1990s». Best regards, Jeroen & Tore

1 year, 1 month

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