Hi, In my opinion, if we are having this discussion for so long, perhaps it is because the original objective of the proposal, which is "Add AGGREGATED-BY-LIR status for IPv4 PA assignments", is being overstepped.
Constructively, I think that adding the AGGREGATED-BY-LIR option for IPv4 PA assignments is a good idea and should be confined to Section 7.0 (Types of Address Space), as is the case with the other types. Section 6.2 does not currently refer to any type. In my opinion, it is compatible to include the new type AGGREGATED-BY-LIR while keeping the information in the current section 6.2 to facilitate consensus. It may be important to analyze situations of non-recording of information in the database, anonymization of information, etc., but this is not related to the proposal to include the new type and should be analyzed separately. Best Regards, kix -- Rodolfo García (kix) http://www.kix.es/ "I asked him once how to change the key bindings and Dave said 'You use the Change Configuration command. On Unix it is abbreviated as cc.' Dave Conroy and Lawrence Stewart. Disclaimer: This email expresses my personal views only and does not necessarily reflect the views or policies of any company, organization or institution. On Tuesday, April 9th, 2024 at 16:50, Gert Doering <g...@space.net> wrote: > Hi, > > On Tue, Apr 09, 2024 at 04:31:06AM +0200, denis walker wrote: > > > Tore you are absolutely right, the cat is out of the bag...but which > > cat? You seem fine about how the RIPE NCC has been mis-interpreting > > policy for 10 years and how they have no power to enforce it other > > than the nuclear option, which we all know they will not use. The > > revelations from this discussion have completely changed the landscape > > for RIPE policy. It has been totally undermined. > > > There is no "change of landscape" or "undermining of policy" here - to > anyone following address policy it was always clear that there is > some leeway in registering end user assignments (INFRA-AW), and that > the NCC cannot enforce correctness of all data. > > They can and do audits, and back when there was still new space to > be had, such an audit could have very unpleasant consequences - namely, > reducing the AW to 0, and refusing allocation of new blocks, until > documentation was fixed. Since there is no more v4 space at the NCC, > all these levers are gone (through no fault of policy or the NCC). > > > Also it was discussed a number of times here on the list and in the > meetings what LIRs should put into the admin-c: and tech-c:, given that > natural persons being involved might not agree to be listed in a public > database with their personal information. So "register the NOC here", > and for single user end customers "register the LIR contacts" has been > established practice for a long time. > > > So while I totally agree that we all (as "the LIRs in the RIPE region") > might not have been following policy to the letter, overall most of us > followed it to the spirit - "put someone in there that will take > responsibility and can take action if needed" (which the letter "put > someone in who is on-site" will not achieve). > > Should we work on improving the documents? By all means, yes. > > > Has this anything to do with 2023-04, or the last call for it? Hardly. > > Gert Doering > -- speaking as LIR contact, and with some policy experience > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, > Ingo Lalla, Karin Schuler > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -- > > 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
