This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Previous message (by thread): [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Next message (by thread): [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Sat Dec 16 19:55:20 CET 2023
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
- Previous message (by thread): [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Next message (by thread): [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]