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-principle... https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/database-requir... Regards, James DBTF On Sun, May 15, 2022 at 2:55 PM Gert Doering <gert@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