Hi Denis, It would appear to me that your opposition to 2023-04 is largely based on the premise that it introduces a new possibility for anonymous assignments, a change which you do not want to see happen. This premise also appears to underpin many of your musings in your «The bigger picture» message. I disagree with this premise, as I believe this possibility is already there in current policy. Rather than decide to agree to disagree on that point, or endlessly quarrel about it, I realised that it does not really matter what you or I believe the policy requirements are - what matters is the RIPE NCC's understanding of the policy and how they are implementing it. So I simply asked their Policy Officer (Angela) to clarify this. Her answers, which I with permission quote in full along with my questions below, unequivocally confirms that that current policy does indeed allow assignments to be registered anonymously in the RIPE database. Hence, your opposition to proposal 2023-04 in this regard appears to rest on a fundamentally flawed assumption. Tore: «The context here is an IPv4 assignment that is not made to an individual and that is not used solely for the connection of an End User to a service provider. 1. Does current address policy as implemented by the NCC allow an End User to delegate/outsource the contact information represented by the mandatory "tech-c" and "admin-c" attributes to another entity, typically (but not necessarily) the issuing LIR? (There does not appear to be any disagreement on this point, but I include this question anyway in case we are both wrong.)» Angela: «Yes, you are correct. An End User is allowed to delegate/outsource the contact information represented by the mandatory "tech-c" and "admin-c" attributes to another entity, typically (but not necessarily) the issuing LIR.» Tore: «2. Assuming "yes" to question 1, for an assignment where the "tech-c" and "admin-c" has been delegated in this manner: Does current address policy require the corresponding "inetnum" database object to contain some additional contact information, that is not delegated to a third party, i.e., it must be refer to a point of contact that is handled in-house by the End User him/herself?» Angela: «The current address policy does not require the corresponding "inetnum" database object to contain some additional contact information that is not delegated to a third party. LIRs can use the “netname” attribute to link assignments to end users and their contact details in internal records. There is a particular case: when the RIPE NCC receives a request for assigning an AS number to an End User using a PA assignment, the IPv4 network to be announced by the requested AS must be registered in an “inetnum” object showing the End User’s name. This can be in the "descr” attribute or recursively in the "org" object added as attribute.» Tore: «3. Assuming "yes" to question 2, what kind of other contact information is required, and in which "inetnum" database attribute(s) must it be located? Here are some possible examples off the top of my head, would any or all of these satisfy the policy requirement for an in-house non-delegated contact information? 1. A street address 2. A (snail) mail address 3. An e-mail address 4. A fax number 5. A phone number» Angela: «The answer to question 2 was “no’, however one way to record End Users’ contact details is to create an “org” object to be added as optional attribute in the “inetnum” object. In “org” objects name, address and email are mandatory. In “inetnum” objects the mandatory contact information are “admin-c” and “tech-c”.» Tore: «4. Assuming "yes" to question 2, is it mandatory to identify the End User by name, or would it be sufficient with, e.g., a street address without an organisation name (assuming there is only a single entity located at that address), a post box snail mail address, a generic user123@gmail.com e-mail address, or a phone/fax number that is not listed in the white or yellow pages?» Angela: «The answer to question 2 was “no’,...» Tore (in a new e-mail): «I will ask you a couple of follow-up questions just to make absolutely, 150%, certain I do not misunderstand you and end up misrepresenting you to the mailing list: 1. When you write «LIRs can use the “netname” attribute to link assignments to end users and their contact details in internal records», this "can" is a MAY, not a MUST, to use IETF lingo? That is, the LIR is free to instead use the "inetnum" attribute, i.e., the IP address(es), to link the assignment to the End User in their internal record? If that is the case, would it be correct to say that the LIR are free to set the "netname" attribute to essentially anything, including a meaningless string of random characters?» Angela: «Your interpretation is correct, the answer is yes to all three questions. Please also consider that the "netname" is not required to be unique, LIRs can use the same one for multiple assignments.» Tore: «2. When you write «one way to record End Users’ contact details is to create an “org” object to be added as optional attribute in the “inetnum” object», this is also a MAY, not a MUST? That is, the LIR is free to omit the "org" attribute, even though the only other contact information contained in the object is the (LIR-delegated) "tech-c" and "admin-c" attributes?» Angela: «Yes, the LIR is free to omit the "org" attribute, even though the only other contact information contained in the object is the (LIR-delegated) "tech-c" and "admin-c" attributes. If the LIR requests an AS number on behalf of an end user to announce a PA assignment, then the PA assignment MUST include the legal name of the end user in the "descr" attribute or in the '"org" object set as "org" attribute in the "inetnum" object.» Tore: «3. To use a concrete example: Let's say «SuperLIR GmbH» delegated 192.0.2.0/25 to the End User «CarFactory GmbH». (CarFactory GmbH is not an individual, and the assignment is not used solely for the connection to the provider, nor to justify an application for an AS number). SuperLIR inserts the following minimal database object: 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 In the event of an audit, SuperLIR GmbH will be able to inform the RIPE NCC auditors that this object has been delegated to CarFactory GmbH. Is the above registration compliant with current IPv4 address policy, or will the auditors demand any kind of changes be made?» Angela: «The above registration compliant with current IPv4 address policy. During an audit we could ask the LIR whether the assignment is still in use. It does not matter for the RIPE NCC who is using the assignment, as long as the LIR is maintaining the registration up to date and is able to contact the end user. This means that if the LIR moves the assignment delegation from CarFactory GmbH to another end user in the same country for which is acting as "admin- c" and "tech-c", the "inetnum" object would still be valid. It is the LIR's responsibility to keep their internal records up to date accordingly with the new end user.» In light of the above, I hope that you will reconsider your opposing arguments and either withdraw them or restate them in a way that does not rely on this incorrect assumption. Anticipating this, I will only address your remaining points that are not based on the misunderstanding that 2023-04 opens up for anonymous assignments.
It should not be permitted to aggregate a single assignment to a single End User.
While I agree that "aggregating" a single assignment seems like a pointless practice, I do not quite see why it is necessary to introduce policy language to ban it. It is, as I understand it, possible to use AGGREGATED-BY-LIR with an assignment-size identical to the prefix length in the inet6num attribute today, but I cannot find a single example of this being done. (Presumably because it is pointless to do so.) It is also possible today to "aggregate" a single IPv4 assignment under the «solely for connection» exception. Whether or not that has been done is impossible for me to say, but even if it has I fail to understand why it would constitute an actual problem. I am not being totally dismissive towards adding a condition à la «an object with status AGGREGATED-BY-LIR must contain at least two individual assignments» to the proposal, but I would first like to better understand the reasons why you feel this is a necessity.
But the IPv6 policy also includes this: "When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED'." I don't see your equivalent of this copied from the IPv6 policy into your new IPv4 policy. Maybe more than a /24 might be an equivalent in IPv4 terms. You refer to 'that specific sentence' so casually, yet this is the main element of the current IPv4 assignment policy. Dropping this sentence is a major change to the assignment policy. This has far more consequences than just adding an optional construct.
In IPv6, /48 is the limit beyond which extra documentation requirements ("need basis") kicks in. Assignments /48 or longer can be freely made by an LIR without any supporting documentation, and this is presumably why such assignments can be freely registered under a single AGGREGATED-BY-LIR object. In other words, assignments shorter than /48 has more stringent documentation requirements, and therefore also more stringent registration requirements. See https://www.ripe.net/publications/docs/ripe-738#assignments_shorter As there is no "need basis" for assignments in IPv4 regardless of size, there simply is no equivalent value, not /24 nor anything else. (Well, I suppose you could say that /0 is the equivalent value.)
Note that this is not really much different than what you have to do today for abuse coming from customer assignments that are «registered as part of the service provider's internal infrastructure», cf. ripe-708 section 6.2.
Doesn't that suggest they are DSL customers with a single IP address?
No, it does not say anything about the number of addresses in the assignment nor the layer-1 technology used. It is very common for point-to-point links (the example given in section 6.2) to be assigned /31 or /30. If the service provider and/or the customer is using a first-hop redundancy protocol such as VRRP, it is necessary to assign a /29 or larger. In any case, there is no technological reason nor any policy limitation that would prevent a service provider from assigning a preposterously large prefix to a point-to-point link, like a /16, let's say.
Assuming an LIR has chosen to use this new 'optional' status value. As many LIRs already have aggregated their DSL customers and tagged them as such in remarks attributes, why should they change it?
We do not expect the RIPE NCC to start a mass migration project as a result of this policy proposal. It is our intention that assignments made under the old policy would be grandfathered in, similar to how you still see many objects with the obsoleted INFRA-AW tag remain in the database today. LIRs would of course be free to change the status value at any point, should they want to do so.
If it has this new aggregated status you still don't know if it is a block of maybe 1000 DSL customers of a collection of randomly sized assignments to End Users. You still need the free text remarks to avoid confusion.
You do not know that today, either, when it comes to aggregated assignments made under the «solely for the connection» exception in current IPv4 policy. Such objects do not contain an assignment-size attribute, nor does policy demand that all individual assignments contained within are of a specific and uniform prefix length. Therefore, such assignments may contain a hodgepodge of DSL customers, FTTH customers, business customers, connected with or without VRRP, and so on. This would continue to be permitted with AGGREGATED-BY-LIR. Tore