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

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

by Nick Hilliard

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, 1 month

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

by Jan Ingvoldstad

On Sat, Dec 16, 2023 at 7:55 PM Tore Anderson <tore(a)fud.no> wrote: > Hi Jan, > Hi Tore, thanks for responding, and sorry for the extreme response lag on my part. 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/013… > > We hope this provides the clarification you requested. > Regrettably it does not, and it also raises the question of whether you have forgotten the definition of "end user" and confused it with "private person". 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). This is misleading, as posting the contact details of an end user **does not necessarily require that you post PII** (person identifying information). You can use a company role and a company role's email address. This is also quite common in the RIPE database today, as far as I can tell. Additionally, this is what we in the registrar business consider a solved problem. In the event that the end user is a private person, you instead by default post anonymized information and e-mail addresses. In the case of e-mail addresses, the typical solution is to post a randomized e-mail address that acts as a forwarding address, and that this address is rotated according to the registrar's internal criteria. In the case of RIPE, it would be the LIR's responsibility, I guess. So this argument regarding publication of PII is void. -- Jan

9 months, 3 weeks

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

by Kai 'wusel' Siering

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. > 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. > proceed with all haste to No haste visible at all; this is about 2023-04 — we already are in 2024-04. Regards, -kai

6 months, 4 weeks

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

by Sander Steffann

Hi, > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 PA assignments" > is now available for discussion. > > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. I agree with this proposal. I have used the AGGREGATED-BY-LIR status for IPv6, and I'd love to be able to do the same for IPv4. I am only a small LIR, so I won't have many objects with AGGREGATED-BY-LIR status, but nonetheless it will allow me to express the way I use my allocated IP addresses better. And I hope it will encourage others to do the same :) Cheers, Sander

1 year, 1 month

Re: [address-policy-wg] 2023-04 Who do I speak for?

by Kai 'wusel' Siering

People, could we take a minute and reflect on this thread's subject? "[address-policy-wg] 2023-04 Who do I speak for?" — this is the AP wg's mailing list, and the discussion is not at all about something related to Address Policy. All the prior talk about the RIPE DB doesn't belong here, either. If changes to the (operation or design of the) RIPE DB require changes to Address Policies, let's discuss about it here. Anything else, AFAICS, belongs into its own wg and accompanied mailing list. Thanks, -kai (writing as a netizen)

1 year

2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Leo Vegoda

Dear WG, The Discussion Phase of policy proposal 2023-04 "Add AGGREGATED-BY-LIR status for IPv4 PA assignments" has now ended. Many thanks to all for your comments. The proposal will now move forward to the Review Phase. The RIPE NCC will prepare an impact analysis and a draft RIPE Document. More details about the phases of the Policy Development Process are published here: https://www.ripe.net/publications/docs/ripe-781 You'll also see an announcement from the RIPE NCC soon. Kind regards, Leo Vegoda for the co-chairs

1 year

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

by boggits

On Mon, 4 Sept 2023 at 10:54, Angela Dall'Ara <adallara(a)ripe.net> wrote: > > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA > assignments to reduce LIR efforts in registration and maintenance. > That sounds like a great idea, I'm just wondering if external viewers of the RIPEdb might infer things from this status that don't match its actual intent... Has anyone had any issues with the IPv6 version? Thx J -- James Blessing 07989 039 476

1 year, 1 month

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

by Peter Hessler

On 2023 Sep 11 (Mon) at 16:09:58 +0000 (+0000), Brian Storey wrote: :Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something? : This behaves the same as the IPv6 version, which has not had this problem yet. -- MESSAGE ACKNOWLEDGED -- The Pershing II missiles have been launched.

1 year, 1 month

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

by denis walker

On Tue, 3 Oct 2023 at 17:00, Sander Steffann <sander(a)steffann.nl> wrote: > > > - realise that the current internet is not the internet that this DB was designed for > > > > Might as well stop issuing policy at all, then. > > The thought did cross my mind ;) or redesign the DB to fit the internet we have today!!! An option that still, nobody will even discuss. How much more proof do we need that this 25 year old design needs attention? (Well you could read Ed's latest impact analysis on a small DB feature change to assignments.) cheers denis co-chair DB-WG > > Cheers! > Sander > > > -- > > 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] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Gert Doering

Hi, On Wed, Nov 29, 2023 at 12:28:04PM +0100, Peter Hessler wrote: > I propose that we define this to be a CIDR assignment and they put in > the number of bits of the netmask, so the above example would be > assignment-size of /32. Seconded. Well spotted. Maybe even make the syntax require the "/", at all times, so it's visually clear right away. "This is a /32, not a 32 which might be either" gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

11 months

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