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


-- 

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

Reply via email to