[address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

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:
https://www.ripe.net/publications/docs/ripe-767

- 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,
James


On Tue, Oct 4, 2022 at 7:56 PM Jérôme Nicolle <jerome at ceriz.fr> wrote:

> 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:
> https://mailman.ripe.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20221006/23bec89d/attachment.html>