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 <[email protected]> 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 -- 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
