[address-policy-wg] IPv4 PA assignments policy change draft proposal

Hi,

> assignment-to-self would still be possible, just
> no more mandatory.

Correct, I believe that's the aim of this proposal. LIRs will no
longer be obliged by policy to register all their infrastructure
assignments in the RIPE Database.

Keep in mind under current policy, resource holders of a /24 PA
allocation must create at least two PA assignments (/25 or smaller).
If a /24 is used for the LIR's infrastructure, this policy proposal
would remove those relatively arbitrary PA assignment registration
requirements.

> This sounds more like a task for the training department or for the ARCs
> than for a policy change to me.

The training department and ARCs help enforce policy. Current policy
has resulted in considerable PA assignment registration
inconsistencies by LIRs (see
https://www.ripe.net/publications/docs/ripe-767#612).

> OTOH: from a database utilization perspective, why would "I put all of
> my /22 in the DB in form of /29 and /30" be worse than "I use a /16
> for customer assignments, /30../24, and register them all (as I MUST
> do)"?  The latter would be many times more objects...

Mitigating one case issue doesn't impact the other. But indeed this
proposal could possibly be scoped out to further consider customer
assignments if the proposal author and WG wish.

> Are we no longer aiming for accurate registration, because the DBTF finds
> that too resource consuming?  I'm not sure I understand that line of
> argument.

I've not seen that being made as an argument by anyone. Data accuracy
is very high on the list of Data Management Principles:
https://www.ripe.net/publications/docs/ripe-767#5--data-management-principles
https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/database-requirements-task-force-recommendations

Regards,
James
DBTF

On Sun, May 15, 2022 at 2:55 PM Gert Doering <gert at space.net> wrote:
>
> Hi,
>
> On Sun, May 15, 2022 at 01:55:33PM +0200, James Kennedy wrote:
> > 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".
>
> This policy proposal would be the wrong vehicle to achieve any outcome
> towards *that* account - assignment-to-self would still be possible, just
> no more mandatory.
>
> This sounds more like a task for the training department or for the ARCs
> than for a policy change to me.
>
> OTOH: from a database utilization perspective, why would "I put all of
> my /22 in the DB in form of /29 and /30" be worse than "I use a /16
> for customer assignments, /30../24, and register them all (as I MUST
> do)"?  The latter would be many times more objects...
>
> Are we no longer aiming for accurate registration, because the DBTF finds
> that too resource consuming?  I'm not sure I understand that line of
> argument.
>
> (Especially if used as an enterprise IPAM - or, more likely, as a mirror
> of the IPAM - accuracy is likely higher than if someone just manually puts
> aggregates into the DB whenever he feels like it.  No?)
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279