IPv4 PA assignments policy change draft proposal
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@a2b-internet.com<mailto:jlauwers@a2b-internet.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”.
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
* 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
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@fud.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
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
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
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
Hi, On Sun, 15 May 2022 at 18:01, Gert Doering <gert@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.
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@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
Hi James On Sun, 15 May 2022 at 19:38, James Kennedy <jameskennedy001@gmail.com> wrote:
Hi,
On Sun, 15 May 2022 at 18:01, Gert Doering <gert@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?
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@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://lists.ripe.net/mailman/listinfo/address-policy-wg
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@gmail.com> wrote:
Hi James
On Sun, 15 May 2022 at 19:38, James Kennedy <jameskennedy001@gmail.com> wrote:
Hi,
On Sun, 15 May 2022 at 18:01, Gert Doering <gert@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@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://lists.ripe.net/mailman/listinfo/address-policy-wg
participants (5)
-
denis walker -
Gert Doering -
James Kennedy -
Jeroen Lauwers -
Tore Anderson