You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.2

Address Policy Working Group

Threaded
Collapse

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

User Image

Jeroen Lauwers

2022-05-14 14:47:11 CET

Dear community,

My name is Jeroen and I am new to the community. Ripe 84 is gonna be for me the first in-person Ripe meeting.

I thought it would be nice as a newcomer to contribute something to the Ripe Community. In consultation with some of the chairs, we decided I could try to pick up the recommendation from the RIPE Database Requirements Task Force.

Last November the DBTF recommended changing the address policy for IPv4 PA  assignments (for own usage) from mandatory to recommended. Before I would send it as an official proposal to the RIPE NCC I would like to share it with the community to see what they think about it. I also would give a short presentation about it on RIPE 84 Where there would be space for discussion and feedback. You can find the draft version down in this mail.

Feel free to reach me.

Kind regards,

Jeroen Lauwers



#### Policy Draft Proposal ####

Remove mandatory IPv4 PA Self assignment registration in the RIPE Database.

Number:
Author:  Jeroen Lauwers
jlauwers _at_ a2b-internet _dot_ comjlauwers _at_ a2b-internet _dot_ com>
A2B Internet
Proposal Version:
Submission Date:
Suggested RIPE WG:  Address Policy
Proposal Type:  Modification
Policy Term:  Indefinite

Summary of Proposal

In its final report, the RIPE Database Requirements Task Force (DBTF) recommended dropping IPv4 PA assignment(s) as a policy requirement [ 1 ]. This recommendation was motivated by the fact that existing LIRs are no longer eligible to request additional IPv4 prefixes from the RIPE NCC. This partially obsoletes the requirement for LIRs to document the assignment of used/reserved prefixes in the RIPE Database. This proposal aims to change the policy on assigned IPv4 PA space from “must" to "may", which will address the issue of unnecessary registration and verification of certain prefixes for LIRs and the RIPE NCC. However, it would still be possible (and recommended) for LIRs to register PA assignments.

[1] https://www.ripe.net/publications/docs/ripe-767#612

Policy

1.0 Introduction

In the past, LIRs could request a new IPv4 prefix when their current pool was sufficiently used. However, since the RIPE NCC started to run out of IPv4, LIRs with existing IPv4 prefixes have not been eligible to receive additional IPv4 prefixes from the RIPE NCC. This resulted in unnecessary efforts by LIRs to register IPv4 prefixes and by the RIPE NCC to ensure that LIRs complied with the policy. This has also led to inconsistencies in the RIPE Database, as some resource holders registered more information than necessary, while many others did not make any PA assignments. The DBTF reported that in May 2021, there were 16,232 PA allocations without any child PA assignments and 9,986 LIRs held PA allocations containing no PA assignments.

The current policy states that you must register a PA assignment for each prefix that an LIR uses. If this specific policy were changed from “must” to “may” for IPv4 PA assignments, the RIPE NCC would not need to spend resources on enforcing compliance with LIRs that have not followed this policy. This policy change would also serve the goal to keep the database limited to what is needed.

However, it would still be recommended and possible to register IPv4 PA assignments in the RIPE Database. Also, LIRs would still be obligated to make assignments in the database when they want to sub-allocate or partition part of their IPv4 resources to another entity (sub-allocated PA/assignments).

2.0 Policy Text

Current policy text [ 2 ]
4.0 Registration Requirements
All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations.

Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status, etc.) must be correct at all times (i.e. they have to be maintained).

New Policy Text
4.0 Registration Requirements
Allocations and assignments to third parties must be registered in the RIPE Database to be considered valid. For IPv4 PA assignments used for the LIR's own network infrastructure, registration is recommended but not mandatory.

This is necessary to ensure uniqueness and to support network operations.
Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status, etc.) which filled in the database, must be correct at all times.

[ 2 ] https://www.ripe.net/publications/docs/ripe-733#4

3.0 What about legacy space?

As the RIPE NCC does not audit RIPE NCC members on their legacy space or how they use it, this policy change does not have an impact on legacy space or legacy space holders.

4.0 Attribution

This document was developed by the RIPE community, and more specifically by Jeroen Lauwers, based on the findings of the RIPE Database Requirements Task Force.

Rationale
a. Arguments supporting the proposal
• One of the main reasons for registering IPv4 PA assignments was that LIRs could show their use of IPv4 and thus justify an additional IPv4 allocation from the RIPE NCC. However, this requirement has become obsolete since the IPv4 run-out.
• The application of IPv4 assignment registration policies in the RIPE Database is inconsistent. Some resource holders flood the database with tiny assignments (e.g. assignments for individual IP addresses), while many others do not register any assignments.
• Resource holders of a /24 allocation are required to create at least two assignments (/25 or smaller).
• This is in line with the data consistency and data minimization principles (as defined in the DBTF report):
– Data stored in the RIPE Database should be adequate, relevant, and limited to only what is necessary.
– It is recommended that resource registration requirements are applied consistently.
• More flexibility

b. Arguments opposing the proposal
• An exception to the main rule does not make the overall policy more understandable.
• It is questionable whether other arguments for public tracking of the use of designated prefixes are weak enough to move from “must” to “may”.





User Image

Gert Doering

2022-05-14 22:42:13 CET

Hi,

On Sat, May 14, 2022 at 12:47:11PM +0000, Jeroen Lauwers wrote:
> b. Arguments opposing the proposal
> ??? An exception to the main rule does not make the overall policy more understandable.

This.  

I am not convinced why adding a special-case "may" for "LIR to itself" 
while keeping the "must" for "LIR to others" would be a good idea of any 
sorts.

"The database has issues with having an allocation being used all-in-one
for one specific customer (the LIR itself)" is an implementation detail,
but policy should not be driven by "database stuff is hard".


Now, relaxing the overall mandate on customer data registration to
something that just states "this is assigned, and the responsible
tech/abuse contacts are as follows" without requiring to name any
customers would be something I find a useful thought, given that the
argument "assignments used to be necessary to document allocation 
usage, when coming back to the NCC" is as valid for LIR-to-itself
as for LIR-to-third-parties.


Gert Doering
-- 
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
User Image

Tore Anderson

2022-05-15 10:36:31 CET

* Gert Doering

> I am not convinced why adding a special-case "may" for "LIR to itself" 
> while keeping the "must" for "LIR to others" would be a good idea of any 
> sorts.

Maybe a compromise would be to add a «LIR to many others [with
identical contact info]» type of database entry, analogous to the
AGGREGATED-BY-LIR inet6num status.

Tore

User Image

James Kennedy

2022-05-15 13:55:33 CET

Hi,

> I am not convinced why adding a special-case "may" for "LIR to itself"
> while keeping the "must" for "LIR to others" would be a good idea of any
> sorts.

I believe this relates to the DBTF recommendation - "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."

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".

Regards,
James
(DBTF hat on)

On Sun, May 15, 2022 at 10:36 AM Tore Anderson <tore _at_ fud _dot_ no> wrote:
>
> * Gert Doering
>
> > I am not convinced why adding a special-case "may" for "LIR to itself"
> > while keeping the "must" for "LIR to others" would be a good idea of any
> > sorts.
>
> Maybe a compromise would be to add a «LIR to many others [with
> identical contact info]» type of database entry, analogous to the
> AGGREGATED-BY-LIR inet6num status.
>
> Tore
>
> --
>
> 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

User Image

Gert Doering

2022-05-15 14:55:08 CET

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
User Image

James Kennedy

2022-05-15 16:53:59 CET

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 _dot_ 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

User Image

Gert Doering

2022-05-15 18:01:37 CET

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
User Image

James Kennedy

2022-05-15 19:38:01 CET

Hi,

On Sun, 15 May 2022 at 18:01, Gert Doering <gert _at_ space _dot_ 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.

> 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.

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 _dot_ 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

denis walker

2022-05-16 14:34:41 CET

Hi James

On Sun, 15 May 2022 at 19:38, James Kennedy <jameskennedy001 _at_ gmail _dot_ com> wrote:
>
> Hi,
>
> On Sun, 15 May 2022 at 18:01, Gert Doering <gert _at_ space _dot_ 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?

> > 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.

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 _dot_ 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://lists.ripe.net/mailman/listinfo/address-policy-wg

User Image

James Kennedy

2022-05-17 12:36:11 CET

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 _dot_ com> wrote:
>
> Hi James
>
> On Sun, 15 May 2022 at 19:38, James Kennedy <jameskennedy001 _at_ gmail _dot_ com> wrote:
> >
> > Hi,
> >
> > On Sun, 15 May 2022 at 18:01, Gert Doering <gert _at_ space _dot_ 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 _dot_ 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://lists.ripe.net/mailman/listinfo/address-policy-wg