<div dir="ltr">Hello, Just want to summarize my thoughts as a member of, but not speaking on behalf of, the Database Requirements Task Force. APWG co-chair hat off. Resulting report from the TF’s work is available here, including purposes of the database, requirements, and resulting recommendations: <a href="https://www.ripe.net/publications/docs/ripe-767">https://www.ripe.net/publications/docs/ripe-767</a> - I don’t read this policy proposal as a revolution to solve all RIPE database issues. It's more a timely pruning exercise of policy that is and has been extremely inconsistently applied (and comprehended?) by users of the database. Clean-ups of existing data is not in scope. - Whether or not it was an original intention, documenting assignments in the database absolutely became *the* key functional mechanism for justifying additional IPv4 PA space from the RIPE NCC. That very real and very important function is now obsolete. - Registering assignments would still be possible and is recommended in this proposal “especially when LIRs want to sub-allocate or assign to another entity (sub-allocated PA/assignments) parts of the IPv4 resources they hold”. Indeed contact information for administrative and technical matters was reported by the TF as a baseline requirement for the database. Note LIR contact details are already in the database for every IP resource they hold, and they could share different info for separate\more specific networks if they so choose. No change there. However, *those who do not want to* would not be forced by policy to pump additional inetnum objects into a public database that the community has complained about already containing much unreliable info (paraphrasing from multiple feedback). Are those orgs and individuals really likely to keep such data accurate and up-to-date? - Re: GDBR, forcing IPv4 holders to create and maintain less entries can only have a positive (albeit probably negligible) effect on personal data in the database imho. - Re: Abuse, good point and important topic. Open question – considering orgs could still register assignments, how would this proposal have any practical effect on potential abuse or fraudulent use of IP space? Re: next steps – does the APWG see any value in exploring this topic further in its current or any other form? Regards, <div>James </div><div> </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 4, 2022 at 7:56 PM Jérôme Nicolle <<a href="mailto:jerome@ceriz.fr">jerome@ceriz.fr</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hell all, I'm thorned on this one. While I fully understand RIPE NCC' willingness reduce the administrative burden on something that's supposed to be deprecated, we all know that the scarcity will introduce new challenges against fraudulent use of address space. If not with a fully documented assignments' database, we would loose a tool to mitigate abuse. On the other hand, let's be realistic, only a very few of us document assignments in full, and in a way that's not actually bloating the database. As far as I'm concerned, I see two scenarios : - An ISP who wants to distinguish its infrastructure from its customers - A more general provider delegating prefixes routed from other ASNs. The second case is clearly closed : to get a route object, the INETNUM has to be specified. On the former though, I know of some large ISPs moving customers behing CGNs using former infrastructure space and didn't declare it within the database. It's a nightmare when trying to enforce aggressive anti-spam policies. Does it matter ? I think not. I'd like to postpone this proposal until we get reports on clear cases and arguments to alleviate the administrative burden and cleanse the database, if any stands. The current policy being not uphold to the best standards doesn't seem to me as a meaningful reason to lighten what _should_ be our responsibility. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14 -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: <a href="https://mailman.ripe.net/" rel="noreferrer" target="_blank">https://mailman.ripe.net/</a> </blockquote></div>