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

Hi Denis, All,

The DBTF recommendation doesn't go into the detail of use cases. That
level should be deliberated and teased out by the WG, and the
associated RIPE policies considered along with other methods such as
training material, best practice/support documentation, ARCs, etc. So,
here we are :)

Question for the WG:
A primary purpose for registering PA assignments in the RIPE database
was to show the LIR's utilization of their existing allocated space in
order to justify their request for an additional allocation from the
RIPE NCC. As that purpose is now obsolete, is there another reason for
policy to insist ("must") LIRs register PA assignments rather than
giving LIRs the choice ("may') to do so or not?

On Mon, May 16, 2022 at 2:35 PM denis walker <ripedenis at gmail.com> wrote:
>
> Hi James
>
> On Sun, 15 May 2022 at 19:38, James Kennedy <jameskennedy001 at gmail.com> wrote:
> >
> > Hi,
> >
> > On Sun, 15 May 2022 at 18:01, Gert Doering <gert at space.net> wrote:
> > > Those that register high amounts of detail even though they are not
> > > required to do so - what makes you think that they would stop if they
> > > are no longer required to do so?
> >
> > I think removing the policy mandate to register all infra pa
> > assignments would reduce the potential for some LIRs to misinterpret
> > the intent of the policy, e.g. think they must register loads of /32s.
> > Personally I don’t see this proposal as a silver bullet to resolve all
> > LIR IPv4 registration issues, but a helpful piece in the larger
> > puzzle.
> >
> > Another option could be to more clearly explain what exactly is and is
> > not intended by the policy. And I’m sure the author would appreciate
> > additional constructive suggestions.
> >
>
> I am confused by the DBTF recommendation which I think also needs more
> clarity. The recommendation says:
> "recommends that as resource holders have full responsibility over the
> registration of their IPv4 PA assignment(s), they are free to make
> assignments or not....and documenting IPv4 PA assignment(s) will stop
> being a policy requirement."
>
> I read this as meaning ALL assignments. This policy proposal seems to
> be suggesting to only change policy for an LIR's infrastructure
> assignments, leaving all assignment blocks to end users as a 'must'
> still be documented. So what is the intention here?

You're right, the differentiation of issuing PA space to third parties
is not made in that recommendation statement but the following:
"However, if a resource holder wants to sub-allocate or partition part
of their IPv4 resources to another entity, the task force strongly
recommends documenting this sub-allocation or assignment in the RIPE
Database."

If the author and WG don't agree with "assignment" in that last
sentence, indeed the scope for consideration can be *all* PA
assignments ("can" rather than "must" be registered in the RIPE
Database).

> > > In other words: I still find it totally unclear what the underlying
> > > problem statement of this proposal is.  Your attempt to do so by
> > > referring to "large amount of objects put into the DB for infrastructure"
> > > didn't make it any clearer.
> >
> > I can’t speak on behalf of the proposal as I’m not the author. I’m
> > only giving context to the DBTF recommendation.
> >
> > > [..]
> > > > > 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.
> > >
> > > Help enforce, and plain help LIRs to better understand what is expected
> > > from them, even if not written down.  The DBTF seems to want "less detailed
> > > infrastructure objects", though I fail the reasoning for that - but if
> > > that is the goal, it could be done by adding the expected level of detail
> > > to the LIR training.
> >
> > Agree this would also help but unfortunately not all LIR
> > administrators attend training courses. No matter how many tasty
> > cookies are on offer :(
> >
> > > > > 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:
> > >
> > > Yes.  So what is the intended benefit when aiming for a reduction of registry
> > > entries?
> >
> > Improve data accuracy for one. From personal experience of managing
> > multiple LIRs of vastly varying sizes, I found maintaining fewer
> > objects far easier to keep data up-to-date in the RIPE database.
> >
>
> I don't see this as an issue of numbers. The real question should be
> "What is the purpose of storing this data?" If there is a valid
> purpose for this data then reducing numbers of valid data to improve
> the quality of what remains is the wrong approach.

Agree with valid purpose being the baseline driver for (any) data
storage. But I don't see that as being mutually exclusive to not
having registrations that seemingly don't have valid purpose, e.g.
assignments under /24s PA allocations.

Regards,
James
DBTF (apwg co-chair hat still off)


> cheers
> denis
> co-chair DB-WG
>
> > But of course that’s a personal anecdote. I would be very interested
> > to hear other people’s real life experiences, opinions and
> > suggestions.
> >
> > Regards,
> > James
> > DBTF
> >
> >
> > On Sun, May 15, 2022 at 6:01 PM Gert Doering <gert at space.net> wrote:
> > >
> > > Hi,
> > >
> > > On Sun, May 15, 2022 at 04:53:59PM +0200, James Kennedy wrote:
> > > > > 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.
> > >
> > > Technically, they have never been obliged to register this in fine
> > > detail ever.  Though, some do, and some do not.  Setting aside a /24
> > > and marking this as "infrastructure" has always been good enough
> > > (modulo AW and Infra-AW and all the fine print).
> > >
> > > Those that register high amounts of detail even though they are not
> > > required to do so - what makes you think that they would stop if they
> > > are no longer required to do so?
> > >
> > >
> > > In other words: I still find it totally unclear what the underlying
> > > problem statement of this proposal is.  Your attempt to do so by
> > > referring to "large amount of objects put into the DB for infrastructure"
> > > didn't make it any clearer.
> > >
> > > [..]
> > > > > 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.
> > >
> > > Help enforce, and plain help LIRs to better understand what is expected
> > > from them, even if not written down.  The DBTF seems to want "less detailed
> > > infrastructure objects", though I fail the reasoning for that - but if
> > > that is the goal, it could be done by adding the expected level of detail
> > > to the LIR training.
> > >
> > > >  Current policy
> > > > has resulted in considerable PA assignment registration
> > > > inconsistencies by LIRs (see
> > > > https://www.ripe.net/publications/docs/ripe-767#612).
> > >
> > > Ignoring for the moment that not all LIRs are identical, that still sounds
> > > to me like "training and ARC" - and why would the proposal being discussed
> > > here have an effekt on these inconsistencies?
> > >
> > > [..]
> > > > > 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:
> > >
> > > Yes.  So what is the intended benefit when aiming for a reduction of registry
> > > entries?
> > >
> > > 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
> >
> > --
> >
> > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/