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

Attachment: signature.asc
Description: PGP signature

-- 

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

Reply via email to