Hi,
I am not convinced why adding a special-case "may" for "LIR to itself" while keeping the "must" for "LIR to others" would be a good idea of any sorts.
I believe this relates to the DBTF recommendation - "if a resource holder wants to sub-allocate or partition part of their IPv4 resources to another entity, the task force strongly recommends documenting this sub-allocation or assignment in the RIPE Database." The DBTF didn't identify a need to change the policy for LIRs registering/documenting blocks of PA that they issue to third parties in the RIPE Database. But we did see the need to change the policy for LIR Infrastructure PA Assignments - some LIRs flood the Database with huge volumes of very small infrastructure PA Assignments that would be extremely difficult to keep up-to-date, and the TF recommends "limiting and discouraging the use of the RIPE Database as an enterprise IPAM solution". Regards, James (DBTF hat on) On Sun, May 15, 2022 at 10:36 AM Tore Anderson <tore@fud.no> wrote:
* Gert Doering
I am not convinced why adding a special-case "may" for "LIR to itself" while keeping the "must" for "LIR to others" would be a good idea of any sorts.
Maybe a compromise would be to add a «LIR to many others [with identical contact info]» type of database entry, analogous to the AGGREGATED-BY-LIR inet6num status.
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