Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
Dear Address Policy WG, There was a consensus on this proposal and we are moving it forward to Last Call. The RIPE NCC will publish an announcement with dates. There was a request, in Rome, for clarity over whether aggregated assignments needed to have a fixed size or could vary. The proposers suggested that a fixed size should be optional. We extended the list discussion by a month and the two issues raised have been addressed. One was End User sites not having the End User's own admin-c instead of the LIR's. There has been extensive discussion of this. One key reason given is that it is common and acceptable to outsource a part of an organisation's operations to another, more skilled, operator. The RIPE NCC's impact analysis noted that the proposal "simply leaves the status quo unchanged." It would not need to update its operational processes. Concerns were also raised that aggregating assignments would impact criminal investigations. But this proposal is intended to improve the quality of data registered by offering LIRs a less arduous way to share registration data. At the end of 2023 there were over 19,000 PA allocations without any assignments. Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs
Colleagues I am not surprised this policy proposal (2023-04) has gone to last call. I expected this from the start, no matter what anyone said. And I won't be surprised when it is approved. I used to wonder why no one would even talk about bringing the RIPE Database into the modern world. Why continue to use an ancient, broken tool that is barely fit for purpose? It is quite obvious now. Playing on the complexity and difficulties with using the database allows people to justify changing the purpose and the rules, to make it more convenient. That is simpler and cheaper than fixing the tool. It is easy for a small vocal group to sell 'simple and cheap' to a silent majority. Convenience is easier to do than right. But it may have consequences. The proposers have assured us all that this proposal is about nothing more than introducing this optional, minor, inconsequential feature that changes nothing. They have argued that the RIPE NCC has "repeatedly" verified their claim that this proposal changes nothing 'of significance'. This is based on the RIPE NCC legal team's confusing impact analysis and the comments made once and referred to once by the RIPE NCC Registration Services through messages passed on by the policy officer. The legal team declined to clarify the confusing wording of their impact analysis. No one from Registration Services was willing to discuss the claims that they have been wrongly applying the policy for a number of years, or the reason why and when they stopped correctly applying the policy. I thought RIPE NCC staff were being encouraged to be more involved in community discussions? It has been said and confirmed recently by several people from the community that we no longer understand what some of the registration data in the RIPE Database means, why it is there and why we have these rules about it. This is despite the actual, current wording of these rules having been written into a version of the policy published in October 2003 that was authored by some people who are still leading members of this community, and at the time were RIPE NCC staff. The infamous line being removed by this proposal was a re-wording of earlier rules introduced in address policy with a long list of early authors, again including some people who are still leading members of this community. I asked if any one of these community leaders would offer some background information to the community on this, now poorly understood, registration data and the rules governing it. That may have helped with our current understanding. If we actually understood the data and rules that we are about to change, we might have more confidence in doing so. But nothing was said on this background. Europol has expressed serious concerns about these changes. They have stated that it takes time for them to consult with national LEAs, the EU commision and other partners. If someone had informed them earlier of the changes being considered that may affect them, they may have had sufficient time to do these consultations. Or perhaps they would have been able to express their deep concerns at an early stage, before the minds of the vocal few were made up. I did suggest early on in the discussion that the RIPE NCC contacts stakeholders of the RIPE Database and invite them to join the discussion. I was quickly told by other community members on the mailing list that this was not part of the policy development process. [Maybe it should be...] It is extraordinary that we have now reached a position where the convenience of a handful of vocal operators in this community is considered so important that we must proceed with all haste to introduce this optional, minor, inconsequential feature that changes nothing, without delay. That is without even a delay to allow Europol to complete it's consultations and report back to the working group. I saw references recently on the ripe.net website and LinkedIn about some productive meeting between the RIPE NCC and some internet governance groups. I hope the attitude of the technical community over this proposal won't undermine those meeting achievements. A technical community that clearly has not watched John Curran's keynote speech at NANOG that covers this very situation involving internet governance, the technical community and civil society. I would advise you all to watch it: https://www.youtube.com/watch?v=U1Ip39Qv-Zk You may question my comments about the vocal few. But the details of the who and how many are there for everyone to see in the public archive of these mailing lists. Only 22 people commented during the months of discussion over 2023-04. Of those, 6 people only made one comment and another 6 only two comments. Some of those 22 also opposed this proposal. So the number of people who actually expressed support is quite small. When you analyse these details for proposals across multiple WGs in recent years, and cross reference the who and how many, you see that there is a very small number of vocal people who tend to dominate these discussions. It is basically this small group of people whose voices dictate RIPE policy. The problem there is that we may find policy, accidentally or intentionally, following an agenda that suits the needs of these people, rather than the wider, silent community. Unfortunately, we don't have any other way to do this at the moment. However, when a change is controversial, has many serious objections and offers so few benefits, to push it through with so few supporters is very questionable. Especially as it has been well established during the long discussions that we (collectively) do not even understand the registration data and governing rules that we are about to substantially change. Nor do we have any firm evidence that even the minor benefits claimed by the proposers are likely to occur. I could go on and dispute the co-chairs' reasoning for declaring a rough consensus. But I have said it all before and it has been disregarded. Although I don't believe I have yet asked them for the evidence or statistical reasoning why they assert that this change will encourage those who don't declare any End User data now, will suddenly decide to provide it after this change. It is of course total nonsense to suggest that this change will end up offering more accurate data on assignments to End Users. It is quite possible that those resource holders that currently don't declare End User assignment data now, will simply create two appropriately sized, anonymous, aggregated objects below each of their allocations. That is 'job done' as far as operations is concerned. Those objects will never need to be updated again. No one has any clue how much, if any, of that address space is in use, by how many End Users with how many addresses each, or who the End Users are, or even if the same block of address space has been assigned to more than one End User by mistake. All that information will be lost. Including one of the basic functions of the registry, to ensure uniqueness of address usage. Quoting statistics on the number of allocations with no assignments is of course simply playing with numbers. It adds nothing to this discussion, but is intended to look like a supporting argument. A perceived problem that needs to be solved, but may not even exist on the implied scale. We don't know how many of those allocations are the /22 and /24 allocations made during the final stages of runout. These were 'intended' to be for new entrants into the industry who planned to provide LIR services. They would not be expected to have assignments if they were used for their infrastructure. (Or maybe they were not allocated as intended?) Many allocations are also made to organisations who do not provide LIR services and have no End Users. The address space is simply used by their organisation. Leo's final comment is a good one to end on. "Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy." This basically sums up everything. ['want' 'like'] The RIPE NCC stopped enforcing address policy after runout because they did not believe they had any power to do so. Here Leo is suggesting that complying with policy is a choice. Some LIRs will choose to comply, others will choose not to comply with RIPE policy. Neither this community nor the RIPE NCC has any power to enforce any policy on operators. We can agree or disagree on any policy we like, but it cannot be enforced. RIPE policy has no teeth. The proposers have assured us that their focus is on providing this aggregation feature. So we must be able to assume that they, and the co-chairs, have deeply considered the implications of this change to the "status:'' attribute. So there shouldn't be any unintended consequences... Hopefully common sense will prevail and we will pause this process to assess where we have been, where we are and where we are going. (I think that is unlikely to happen...) cheers denis ======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ======================================================== On Mon, 11 Mar 2024 at 09:30, Leo Vegoda <leo@vegoda.org> wrote:
Dear Address Policy WG,
There was a consensus on this proposal and we are moving it forward to Last Call. The RIPE NCC will publish an announcement with dates.
There was a request, in Rome, for clarity over whether aggregated assignments needed to have a fixed size or could vary. The proposers suggested that a fixed size should be optional.
We extended the list discussion by a month and the two issues raised have been addressed.
One was End User sites not having the End User's own admin-c instead of the LIR's. There has been extensive discussion of this. One key reason given is that it is common and acceptable to outsource a part of an organisation's operations to another, more skilled, operator. The RIPE NCC's impact analysis noted that the proposal "simply leaves the status quo unchanged." It would not need to update its operational processes.
Concerns were also raised that aggregating assignments would impact criminal investigations. But this proposal is intended to improve the quality of data registered by offering LIRs a less arduous way to share registration data. At the end of 2023 there were over 19,000 PA allocations without any assignments. Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy.
Kind regards,
Leo Vegoda, for the Address Policy WG co-chairs
--
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
Greetings, After reading your message, i had to go search if i expressed an opinion on 2023-04 or not. It seems i did (back in September), but perhaps i wasn't 100% clear about my opposition to this proposal. So in order to make it clear for the co-chairs, i do oppose this proposal, on the grounds that the quality of publicly available registration data is likely to decrease if this proposal is approved. Best Regards, Carlos On Fri, 5 Apr 2024, denis walker wrote:
Colleagues
I am not surprised this policy proposal (2023-04) has gone to last call. I expected this from the start, no matter what anyone said. And I won't be surprised when it is approved. I used to wonder why no one would even talk about bringing the RIPE Database into the modern world. Why continue to use an ancient, broken tool that is barely fit for purpose? It is quite obvious now. Playing on the complexity and difficulties with using the database allows people to justify changing the purpose and the rules, to make it more convenient. That is simpler and cheaper than fixing the tool. It is easy for a small vocal group to sell 'simple and cheap' to a silent majority. Convenience is easier to do than right. But it may have consequences.
The proposers have assured us all that this proposal is about nothing more than introducing this optional, minor, inconsequential feature that changes nothing. They have argued that the RIPE NCC has "repeatedly" verified their claim that this proposal changes nothing 'of significance'. This is based on the RIPE NCC legal team's confusing impact analysis and the comments made once and referred to once by the RIPE NCC Registration Services through messages passed on by the policy officer. The legal team declined to clarify the confusing wording of their impact analysis. No one from Registration Services was willing to discuss the claims that they have been wrongly applying the policy for a number of years, or the reason why and when they stopped correctly applying the policy. I thought RIPE NCC staff were being encouraged to be more involved in community discussions?
It has been said and confirmed recently by several people from the community that we no longer understand what some of the registration data in the RIPE Database means, why it is there and why we have these rules about it. This is despite the actual, current wording of these rules having been written into a version of the policy published in October 2003 that was authored by some people who are still leading members of this community, and at the time were RIPE NCC staff. The infamous line being removed by this proposal was a re-wording of earlier rules introduced in address policy with a long list of early authors, again including some people who are still leading members of this community. I asked if any one of these community leaders would offer some background information to the community on this, now poorly understood, registration data and the rules governing it. That may have helped with our current understanding. If we actually understood the data and rules that we are about to change, we might have more confidence in doing so. But nothing was said on this background.
Europol has expressed serious concerns about these changes. They have stated that it takes time for them to consult with national LEAs, the EU commision and other partners. If someone had informed them earlier of the changes being considered that may affect them, they may have had sufficient time to do these consultations. Or perhaps they would have been able to express their deep concerns at an early stage, before the minds of the vocal few were made up. I did suggest early on in the discussion that the RIPE NCC contacts stakeholders of the RIPE Database and invite them to join the discussion. I was quickly told by other community members on the mailing list that this was not part of the policy development process. [Maybe it should be...]
It is extraordinary that we have now reached a position where the convenience of a handful of vocal operators in this community is considered so important that we must proceed with all haste to introduce this optional, minor, inconsequential feature that changes nothing, without delay. That is without even a delay to allow Europol to complete it's consultations and report back to the working group. I saw references recently on the ripe.net website and LinkedIn about some productive meeting between the RIPE NCC and some internet governance groups. I hope the attitude of the technical community over this proposal won't undermine those meeting achievements. A technical community that clearly has not watched John Curran's keynote speech at NANOG that covers this very situation involving internet governance, the technical community and civil society. I would advise you all to watch it: https://www.youtube.com/watch?v=U1Ip39Qv-Zk
You may question my comments about the vocal few. But the details of the who and how many are there for everyone to see in the public archive of these mailing lists. Only 22 people commented during the months of discussion over 2023-04. Of those, 6 people only made one comment and another 6 only two comments. Some of those 22 also opposed this proposal. So the number of people who actually expressed support is quite small. When you analyse these details for proposals across multiple WGs in recent years, and cross reference the who and how many, you see that there is a very small number of vocal people who tend to dominate these discussions. It is basically this small group of people whose voices dictate RIPE policy. The problem there is that we may find policy, accidentally or intentionally, following an agenda that suits the needs of these people, rather than the wider, silent community. Unfortunately, we don't have any other way to do this at the moment. However, when a change is controversial, has many serious objections and offers so few benefits, to push it through with so few supporters is very questionable. Especially as it has been well established during the long discussions that we (collectively) do not even understand the registration data and governing rules that we are about to substantially change. Nor do we have any firm evidence that even the minor benefits claimed by the proposers are likely to occur.
I could go on and dispute the co-chairs' reasoning for declaring a rough consensus. But I have said it all before and it has been disregarded. Although I don't believe I have yet asked them for the evidence or statistical reasoning why they assert that this change will encourage those who don't declare any End User data now, will suddenly decide to provide it after this change.
It is of course total nonsense to suggest that this change will end up offering more accurate data on assignments to End Users. It is quite possible that those resource holders that currently don't declare End User assignment data now, will simply create two appropriately sized, anonymous, aggregated objects below each of their allocations. That is 'job done' as far as operations is concerned. Those objects will never need to be updated again. No one has any clue how much, if any, of that address space is in use, by how many End Users with how many addresses each, or who the End Users are, or even if the same block of address space has been assigned to more than one End User by mistake. All that information will be lost. Including one of the basic functions of the registry, to ensure uniqueness of address usage.
Quoting statistics on the number of allocations with no assignments is of course simply playing with numbers. It adds nothing to this discussion, but is intended to look like a supporting argument. A perceived problem that needs to be solved, but may not even exist on the implied scale. We don't know how many of those allocations are the /22 and /24 allocations made during the final stages of runout. These were 'intended' to be for new entrants into the industry who planned to provide LIR services. They would not be expected to have assignments if they were used for their infrastructure. (Or maybe they were not allocated as intended?) Many allocations are also made to organisations who do not provide LIR services and have no End Users. The address space is simply used by their organisation.
Leo's final comment is a good one to end on. "Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy." This basically sums up everything. ['want' 'like'] The RIPE NCC stopped enforcing address policy after runout because they did not believe they had any power to do so. Here Leo is suggesting that complying with policy is a choice. Some LIRs will choose to comply, others will choose not to comply with RIPE policy. Neither this community nor the RIPE NCC has any power to enforce any policy on operators. We can agree or disagree on any policy we like, but it cannot be enforced. RIPE policy has no teeth.
The proposers have assured us that their focus is on providing this aggregation feature. So we must be able to assume that they, and the co-chairs, have deeply considered the implications of this change to the "status:'' attribute. So there shouldn't be any unintended consequences...
Hopefully common sense will prevail and we will pause this process to assess where we have been, where we are and where we are going. (I think that is unlikely to happen...)
cheers denis
======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================
On Mon, 11 Mar 2024 at 09:30, Leo Vegoda <leo@vegoda.org> wrote:
Dear Address Policy WG,
There was a consensus on this proposal and we are moving it forward to Last Call. The RIPE NCC will publish an announcement with dates.
There was a request, in Rome, for clarity over whether aggregated assignments needed to have a fixed size or could vary. The proposers suggested that a fixed size should be optional.
We extended the list discussion by a month and the two issues raised have been addressed.
One was End User sites not having the End User's own admin-c instead of the LIR's. There has been extensive discussion of this. One key reason given is that it is common and acceptable to outsource a part of an organisation's operations to another, more skilled, operator. The RIPE NCC's impact analysis noted that the proposal "simply leaves the status quo unchanged." It would not need to update its operational processes.
Concerns were also raised that aggregating assignments would impact criminal investigations. But this proposal is intended to improve the quality of data registered by offering LIRs a less arduous way to share registration data. At the end of 2023 there were over 19,000 PA allocations without any assignments. Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy.
Kind regards,
Leo Vegoda, for the Address Policy WG co-chairs
--
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
--
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
* Carlos Friaças via address-policy-wg:
So in order to make it clear for the co-chairs, i do oppose this proposal, on the grounds that the quality of publicly available registration data is likely to decrease if this proposal is approved.
Hi Carlos, This concern has been addressed at length in the previous phases of the policy development process, so for the full answer we will refer you back to those discussions. We will however summarise our position briefly below: We do not believe the registration data will degrade as a result of this proposal. It does in no way encourage or compel LIRs to remove any End User registration data currently found in the database, nor does it stop them from adding more End User registration data in the future. In other words, any LIR that today chooses to publish detailed information about their individual End User assignments is free to continue to do so after this proposal is implemented. Furthermore, there is no reason to expect that the acceptance of this proposal will entice LIRs to replace detailed individual assignments with aggregated assignments en masse. This has not happened with IPv6, where there are currently over twelve times as many ASSIGNED inet6num objects as there are AGGREGATED-BY-LIR objects. Many of those are rife with optional End User details shared voluntarily by the issuing LIRs. We see no reason to believe that LIRs will use AGGREGATED-BY-LIR for IPv4 inetnum objects in a materially different way. Finally, we would like to point out that the proposal explicitly restricts the scope of AGGREGATED-BY-LIR, by stating that «the purpose and the contact details must be consistent throughout the whole assignment». That means that the End User registration data that can be aggregated must be redundant in the first place. Best regards, Jeroen & Tore
Hi Jeroen & Tore, There is a subtly here which I don't think is fully appreciated. I previously highlighted my surprise to the RIPE NNCs interpretation of the existing policy; as have others. Why is that? I think it's very important to recognise that LIRs act and publish certain End User data because it was deemed that this was a requirement and that not doing so could see a breach of policy, therefore leading to Allocated PAs being reclaimed - not good with scarce resources! They did this because they understood they HAD to not because they WANTED to. If this school of thought no longer applies, then it is reasonable to expect that some will reevaluate how much effort they continue to put in and the consequences of that. The two questions I previously posed here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013... were:- "For me it comes down to this. As a community & considering the permitted exceptions (individuals & P2P assignments):- 1) Is the publication of End User entities for an assignment important? 2) Is the publication of a prefix assignment boundary between end users important?" A response agreeing with these questions and reflecting surprise at the policy interpretation is also here (apologies Nick, I missed it at the time):- https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013... Now, I've not commented since (for various reasons), however I have followed the discussion of this closely. Internally, I've been highlighting that a Business Risk item based on previous interpretation could evolve and how we manage our exposure changes if this proposal become policy. What this means in reality is that we can choose how much effort we continue to place on updating our Assignments as the end user customer base churns. There are end customers who like their association to a PA Assignment to be published and there are those who don't. It may well be easier for me only publish by exception. I'm still thinking it through pending what happens next with a few other indirect considerations. I don't believe I'll be the only one doing this. Many thanks, Brian Brian Storey IP Network Capacity Planning Manager Tel: 0333 240 3481 Mobile: 07436 101 378 Email: Brian.Storey@gamma.co.uk This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster@gamma.co.uk Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at The Scalpel, 18th Floor, 52 Lime Street, London EC3M 7AF and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY. -----Original Message----- From: address-policy-wg <address-policy-wg-bounces@ripe.net> On Behalf Of Tore Anderson Sent: Monday, April 8, 2024 11:42 AM To: Carlos Friaças <cfriacas@fccn.pt> Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status * Carlos Friaças via address-policy-wg:
So in order to make it clear for the co-chairs, i do oppose this proposal, on the grounds that the quality of publicly available registration data is likely to decrease if this proposal is approved.
Hi Carlos, This concern has been addressed at length in the previous phases of the policy development process, so for the full answer we will refer you back to those discussions. We will however summarise our position briefly below: We do not believe the registration data will degrade as a result of this proposal. It does in no way encourage or compel LIRs to remove any End User registration data currently found in the database, nor does it stop them from adding more End User registration data in the future. In other words, any LIR that today chooses to publish detailed information about their individual End User assignments is free to continue to do so after this proposal is implemented. Furthermore, there is no reason to expect that the acceptance of this proposal will entice LIRs to replace detailed individual assignments with aggregated assignments en masse. This has not happened with IPv6, where there are currently over twelve times as many ASSIGNED inet6num objects as there are AGGREGATED-BY-LIR objects. Many of those are rife with optional End User details shared voluntarily by the issuing LIRs. We see no reason to believe that LIRs will use AGGREGATED-BY-LIR for IPv4 inetnum objects in a materially different way. Finally, we would like to point out that the proposal explicitly restricts the scope of AGGREGATED-BY-LIR, by stating that «the purpose and the contact details must be consistent throughout the whole assignment». That means that the End User registration data that can be aggregated must be redundant in the first place. Best regards, Jeroen & 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
* Brian Storey:
There is a subtly here which I don't think is fully appreciated.
I previously highlighted my surprise to the RIPE NNCs interpretation of the existing policy; as have others. Why is that? I think it's very important to recognise that LIRs act and publish certain End User data because it was deemed that this was a requirement and that not doing so could see a breach of policy, therefore leading to Allocated PAs being reclaimed - not good with scarce resources! They did this because they understood they HAD to not because they WANTED to.
If this school of thought no longer applies, then it is reasonable to expect that some will reevaluate how much effort they continue to put in and the consequences of that.
Hi Brian, We have certainly no difficulty understanding that you and others might have not been aware of this before. But now you are, and so is anyone else that are following the RIPE policy development process. The cat is out of the bag, so to speak. Withdrawing 2023-04 would not undo this, because this is not a property of the proposal itself, but knowledge of the of the RIPE NCC's interpretation of the *current* address policy. Or as the working group chairs put it: «It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time.» Furthermore, it is clear that this comes as no surprise at all to many LIRs, who have done this for a long time. Again quoting the working group chairs: «…changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects» https://www.ripe.net/ripe/mail/archives/address-policy-wg/2024-January/01398...
The two questions I previously posed here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013... were:-
"For me it comes down to this. As a community & considering the permitted exceptions (individuals & P2P assignments):-
1) Is the publication of End User entities for an assignment important?
Perhaps, perhaps not. That is for the working group to decide. It is however outside the scope of 2023-04. Again quoting the working group chairs from the previously linked-to message: «…we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one».
2) Is the publication of a prefix assignment boundary between end users important?"
We address this question in the proposal itself, see https://www.ripe.net/membership/policies/proposals/2023-04/#12-differences-f.... The gist of it is that since IPv4 assignments tend to be right-sized (rather than gigantic "one size fits all" prefixes like in IPv6), and that there is no HD-Ratio that needs calculating, we found it more appropriate to leave the assignment-size attribute optional.
Now, I've not commented since (for various reasons), however I have followed the discussion of this closely. Internally, I've been highlighting that a Business Risk item based on previous interpretation could evolve and how we manage our exposure changes if this proposal become policy. What this means in reality is that we can choose how much effort we continue to place on updating our Assignments as the end user customer base churns. There are end customers who like their association to a PA Assignment to be published and there are those who don't. It may well be easier for me only publish by exception. I'm still thinking it through pending what happens next with a few other indirect considerations.
I don't believe I'll be the only one doing this.
You and everyone else can do this right now. You do not need to wait for the possible acceptance of 2023-04. As mentioned above, you have in fact been free to do this «since at leas [sic] the late 1990s». Best regards, Jeroen & Tore
Hi Tore, Thanks for the response. I only have a short window to reply, however I would clarify that I fall in to the " Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time.»" category. I am therefore looking at this through the lens of this approach. In which-ever form the end user is illustrated, it's the total permitted absence of that which is the surprise; Unless I have misunderstood the recently shared RIPE NNC interpretation. Many thanks, Brian -----Original Message----- From: Tore Anderson <tore@fud.no> Sent: Monday, April 8, 2024 1:38 PM To: Brian Storey <Brian.Storey@gamma.co.uk>; Carlos Friaças <cfriacas@fccn.pt> Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status * Brian Storey:
There is a subtly here which I don't think is fully appreciated.
I previously highlighted my surprise to the RIPE NNCs interpretation of the existing policy; as have others. Why is that? I think it's very important to recognise that LIRs act and publish certain End User data because it was deemed that this was a requirement and that not doing so could see a breach of policy, therefore leading to Allocated PAs being reclaimed - not good with scarce resources! They did this because they understood they HAD to not because they WANTED to.
If this school of thought no longer applies, then it is reasonable to expect that some will reevaluate how much effort they continue to put in and the consequences of that.
Hi Brian, We have certainly no difficulty understanding that you and others might have not been aware of this before. But now you are, and so is anyone else that are following the RIPE policy development process. The cat is out of the bag, so to speak. Withdrawing 2023-04 would not undo this, because this is not a property of the proposal itself, but knowledge of the of the RIPE NCC's interpretation of the *current* address policy. Or as the working group chairs put it: «It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time.» Furthermore, it is clear that this comes as no surprise at all to many LIRs, who have done this for a long time. Again quoting the working group chairs: « changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects» https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.n et%2Fripe%2Fmail%2Farchives%2Faddress-policy-wg%2F2024-January%2F013980.html &data=05%7C02%7CBrian.Storey%40gamma.co.uk%7C5f1a1c8dfdc044cfcc9f08dc57c8bc2 3%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638481766859115331%7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3D%7C0%7C%7C%7C&sdata=bWifsFJ9cfucTWDCBWz4WueyMwcy6Ehr6ti5Lgi1Byg%3D&reser ved=0
The two questions I previously posed here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. ripe.net%2Fripe%2Fmail%2Farchives%2Faddress-policy-wg%2F2023-September %2F013863.html&data=05%7C02%7CBrian.Storey%40gamma.co.uk%7C5f1a1c8dfdc 044cfcc9f08dc57c8bc23%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638 481766859125299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2 luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=JiSFtHNbG6Lz6I jzIBE2nf6%2B4JwIJ8Ug3GAs97nIqtw%3D&reserved=0 were:-
"For me it comes down to this. As a community & considering the permitted exceptions (individuals & P2P assignments):-
1) Is the publication of End User entities for an assignment important?
Perhaps, perhaps not. That is for the working group to decide. It is however outside the scope of 2023-04. Again quoting the working group chairs from the previously linked-to message: « we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one».
2) Is the publication of a prefix assignment boundary between end users important?"
We address this question in the proposal itself, see https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.n et%2Fmembership%2Fpolicies%2Fproposals%2F2023-04%2F%2312-differences-from-ip v6-aggregated-by-lir-status&data=05%7C02%7CBrian.Storey%40gamma.co.uk%7C5f1a 1c8dfdc044cfcc9f08dc57c8bc23%7C743a5d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C63 8481766859132088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=oyHBpPOS0YdV7jw7hXJOhO762 1F%2FY%2BAwBTmtp2f%2F%2F%2BM%3D&reserved=0. The gist of it is that since IPv4 assignments tend to be right-sized (rather than gigantic "one size fits all" prefixes like in IPv6), and that there is no HD-Ratio that needs calculating, we found it more appropriate to leave the assignment-size attribute optional.
Now, I've not commented since (for various reasons), however I have followed the discussion of this closely. Internally, I've been highlighting that a Business Risk item based on previous interpretation could evolve and how we manage our exposure changes if this proposal become policy. What this means in reality is that we can choose how much effort we continue to place on updating our Assignments as the end user customer base churns. There are end customers who like their association to a PA Assignment to be published and there are those who don't. It may well be easier for me only publish by exception. I'm still thinking it through pending what happens next with a few other indirect considerations.
I don't believe I'll be the only one doing this.
You and everyone else can do this right now. You do not need to wait for the possible acceptance of 2023-04. As mentioned above, you have in fact been free to do this «since at leas [sic] the late 1990s». Best regards, Jeroen & Tore
* Brian Storey
I only have a short window to reply, however I would clarify that I fall in to the " Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time.»" category. I am therefore looking at this through the lens of this approach.
In which-ever form the end user is illustrated, it's the total permitted absence of that which is the surprise; Unless I have misunderstood the recently shared RIPE NNC interpretation. Hi again Brian,
To be clear, "CUSTOMER-1234" above was not meant to be substituted with the actual name of the customer, but rather taken as verbatim netname attribute value. While one may infer from that string that it is indeed a customer assignment (as opposed a self-assignment to the LIR's own infrastructure), as well as revealing a possible customer account number, even those bits of information are optional to include. Below you will find an example of a complete inetnum object representing an assignment to the End User «CarFactory GmbH» by the LIR «SuperLIR GmbH», which RIPE NCC explicitly confirmed to be compliant with current address policy (see https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013...): inetnum: 192.0.2.0 - 192.0.2.128 netname: ABCDEFGHIJKLMNOPQRSTUVWXYZ country: DE admin-c: SUPERLIR-NOC-RIPE tech-c: SUPERLIR-NOC-RIPE status: ASSIGNED PA mnt-by: SUPERLIR-MNT source: RIPE If you, or anyone else, want to "minimise" your assignments as shown in the above example, you can do so already today. It is already considered accepted practice and has been for decades. 2023-04's fate is totally irrelevant as to whether or not you or any other LIR can adopt this practice, assuming you want to. Best regards, Jeroen & Tore
Colleagues I wasn't going to say anything else on this issue for now. BUT there has been so much false and mis-information put out today I cannot leave that unanswered, as the last word on this topic. Also people need to understand what this discussion over the last 6 months has done. On Mon, 8 Apr 2024 at 14:38, Tore Anderson <tore@fud.no> wrote:
* Brian Storey:
There is a subtly here which I don't think is fully appreciated.
I previously highlighted my surprise to the RIPE NNCs interpretation of the existing policy; as have others. Why is that? I think it's very important to recognise that LIRs act and publish certain End User data because it was deemed that this was a requirement and that not doing so could see a breach of policy, therefore leading to Allocated PAs being reclaimed - not good with scarce resources! They did this because they understood they HAD to not because they WANTED to.
You are right Brian. It IS still a requirement, but as we have learned, it has not been enforced by the RIPE NCC for about 10 years. The ONLY way the RIPE NCC could enforce this is the nuclear option...reclaim address space and close an LIR. Could you imagine the RIPE NCC doing that to a large and powerful LIR? There would be an immediate legal challenge and ensuing court case. I have often commented on the state of RIPE documents. Many of them are poorly written, have contradictions within them and conflicts between documents in a linked set. So many things are not defined ANYWHERE. Many of these documents are open to interpretation. That leads to a litigation nightmare and is great news for lawyers and barristers who can spend days in court arguing over the precise meaning of a document. I would not want to go to court building a defence on this document set. Obviously, neither does the RIPE NCC, as they have failed to enforce policy, as mandated, for 10 years. If the RIPE NCC was to lose the first legal challenge that would set a legal precedent. At that point you can tear up all RIPE policies. (But maybe you can do that anyway...read on.)
If this school of thought no longer applies, then it is reasonable to expect that some will reevaluate how much effort they continue to put in and the consequences of that.
Hi Brian,
We have certainly no difficulty understanding that you and others might have not been aware of this before. But now you are, and so is anyone else that are following the RIPE policy development process. The cat is out of the bag, so to speak. Withdrawing 2023-04 would not undo this, because this is not a property of the proposal itself, but knowledge of the of the RIPE NCC's interpretation of the *current* address policy.
Tore you are absolutely right, the cat is out of the bag...but which cat? You seem fine about how the RIPE NCC has been mis-interpreting policy for 10 years and how they have no power to enforce it other than the nuclear option, which we all know they will not use. The revelations from this discussion have completely changed the landscape for RIPE policy. It has been totally undermined. I agree that wirdrawing 2023-04 now makes no difference. The damage is already done and there is no way back. The final decision on 2023-04 is now irrelevant. When the reality of what has been said really sinks in, it may be devastating for RIPE policy and the RIPE Database as a public registry. More on that later...
Or as the working group chairs put it:
«It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time.»
This is just unbelievable nonsense. One of the chairs, Leo, knows this for sure as he was responsible for this. Let's consider the real facts here. Consider that infamous policy statement: "When an End User has a network using public address space this must be registered separately with the contact details of the End User." This exact statement was written into the address policy published in October 2003. The authors were 4 RIPE NCC staff members. These included Leo, at the time he was the operations manager of Registration Services (RS), and Paul Rendek, the senior manager responsible for RS. This statement was a re-write of rules that had been in place for many years. Now anyone who has written specs or regulations knows that, if you change the wording of a rule, you need to understand what it means so you get the new wording correct. So in 2003 we have the RS manager and senior manager writing the address policy and really understanding what these rules actually mean. There was no misunderstanding or misinterpretation then. I will not believe anyone who tries to tell me now that the manager and senior manager responsible for RS, having just written the address policy containing this rule, did not enforce it in 2003. In fact I know from talking to ex RS staff that it was enforced until runout. So it is about 10 years since the RIPE NCC decided it no longer had any power to enforce policy. To say the RIPE NCC interpreted the policy wrongly since the late 1990s is simply NOT TRUE. This gives a very different view on when the policy was enforced and when and why it stopped being enforced.
Furthermore, it is clear that this comes as no surprise at all to many LIRs, who have done this for a long time. Again quoting the working group chairs:
Many LIRs who have been in violation of policy for a long time, who know they are in violation. Who will all suddenly become policy compliant again if this proposal is accepted, and they know that.
«…changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects»
This practice has never been 'accepted'. It has never even been discussed in detail until now. The RIPE NCC never came to the community and said they can no longer enforce the current policy, what should we do?
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2024-January/01398...
The two questions I previously posed here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013... were:-
"For me it comes down to this. As a community & considering the permitted exceptions (individuals & P2P assignments):-
1) Is the publication of End User entities for an assignment important?
Perhaps, perhaps not. That is for the working group to decide. It is however outside the scope of 2023-04. Again quoting the working group chairs from the previously linked-to message:
«…we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one».
To approve a policy now that allows End User details to be deleted, then consider a proposal that requires End User details to be published, makes no sense. But then none of this makes any sense.
Now, I've not commented since (for various reasons), however I have followed the discussion of this closely. Internally, I've been highlighting that a Business Risk item based on previous interpretation could evolve and how we manage our exposure changes if this proposal become policy. What this means in reality is that we can choose how much effort we continue to place on updating our Assignments as the end user customer base churns. There are end customers who like their association to a PA Assignment to be published and there are those who don't. It may well be easier for me only publish by exception. I'm still thinking it through pending what happens next with a few other indirect considerations.
I don't believe I'll be the only one doing this.
You and everyone else can do this right now. You do not need to wait for the possible acceptance of 2023-04. As mentioned above, you have in fact been free to do this «since at leas [sic] the late 1990s».
You are not free to do this now and haven't been for a very long time. But that hasn't stopped many people from doing it in violation of policy. On Mon, 8 Apr 2024 at 15:53, Tore Anderson <tore@fud.no> wrote:
Below you will find an example of a complete inetnum object representing an assignment to the End User «CarFactory GmbH» by the LIR «SuperLIR GmbH», which RIPE NCC explicitly confirmed to be compliant with current address policy (see
Which we all now know is a misinterpretation of current policy and is wrong.
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013...):
inetnum: 192.0.2.0 - 192.0.2.128 netname: ABCDEFGHIJKLMNOPQRSTUVWXYZ country: DE admin-c: SUPERLIR-NOC-RIPE tech-c: SUPERLIR-NOC-RIPE status: ASSIGNED PA mnt-by: SUPERLIR-MNT source: RIPE
If you, or anyone else, want to "minimise" your assignments as shown in the above example, you can do so already today. It is already considered accepted practice and has been for decades. 2023-04's fate is totally irrelevant as to whether or not you or any other LIR can adopt this practice, assuming you want to.
Very few people actually consider this to be 'accepted' practice. On Mon, 8 Apr 2024 at 10:10, Jeroen Lauwers <jlauwers@a2b-internet.com> wrote:
Hi Emmanuel,
The matter is the loss of opportunities of identification that will vanish for investigators...
This is a subject that has been covered extensively during the previous two phases of the policy development process and is as such is already addressed, but we will summarise the main points below for your convenience.
addressed by dismissal
During the previous discussion of 2023-04 it has been made adamantly clear by the RIPE NCC that any information inserted into the RIPE database that identifies the End User is inserted voluntarily by the LIR. There exists no policy requirement that compels LIRs to publish the identities of their End Users, this is simply an option that some LIRs avail themselves of.
Totally untrue. Totally false. Most LIRs actually do understand the current policy. They are aware that the policy requires an assignment to include contact details of the End User organisation. In many cases that is taken to mean the email address referenced via the "admin-c:" attribute. Where the LIR handles the tech issues for the End User it has become common practice to replace both the tech-c and admin-c with the LIR's contact details. When this is done, many LIRs then add the End User name and address into the optional "descr:" attributes. Just because this is an optional attribute does not mean the data it contains is optional. Name and address is one format for contact details. If the LIR has replaced the tech-c and admin-c in the assignment with their own details, they remain policy compliant by adding the required End User contact details (name and address) in the optional descr attributes. I am sure most LIRs do not do this extra administration because they enjoy the extra workload of voluntarily providing additional information that is not required by policy.
It is important to realize that the policy proposed by 2023-04 does not in any way whatsoever restrict or prohibit LIRs from voluntarily publishing the identities of their End Users in the RIPE database. LIRs that have a policy to do so today, will be able to continue to do so in the future in the exact same way after 2023-04 is implemented. Indeed, these LIRs are free to ignore 2023-04 completely – 2023-04 does not deprecate or remove the ASSIGNED PA inetnum status, it may still be used as before.
It DOES remove the policy requirement to provide a contact with the End User in ALL cases. So even a small LIR has no fear of being in violation of address policy and the NCC using the nuclear option on them. NO ONE will be required to provide ANY contact with the End User within the RIPE Database.
It follows logically that 2023-04 does not cause any loss of End User identification. Investigators may continue to look up IP addresses in the RIPE database, but whether or not it will yield the End User's identity (as opposed to «a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR», as the working group chairs put it) will depend entirely on the issuing LIR's policies and procedures, just as it does under today.
NO NO NO 2023-04 allows for the complete removal of any End User contact details whether there is an assignment object or not. You are specifically removing the infamous line that requires a way to contact the End User. This is a policy violation today, which some LIRs ignore with impunity.
For a demonstration of this taking place in practice, take a look at the IPv6 part of the RIPE database. The AGGREGATED-BY-LIR status has been available for inet6num objects since forever, but this has not prevented LIRs from to registering their End User assignments using the ASSIGNED status instead, often including the End User's identity, contact information, and other optional details. There is no reason to expect that this will be any different in IPv4 following the implementation of 2023-04, as we see it.
Conclusion Now let's conclude with the more serious aspects of what has happened in the last 6 months. The co-chairs of the Address Policy Working Group have declared that address policy is optional. LIRs can choose if they want to comply with it or they don't want to comply with it. The chairs said: "Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy." This basically sums up everything regarding policy. ['want' 'like']. If you don't want, don't like, just don't do. The chairs seem to be fine with this. The RIPE NCC has shown by it's actions over the last 10 years that it will not use the nuclear option for a policy violation and they have no other power. So we have shown to LIRs that they can now do whatever they like with impunity. The proposers have made lots of references to IPv6 "allocated-by-lir:" and "assigned:". They talk about how well things work in the IPv6 world. Maybe that is all about to change. If the NCC has no power to enforce policy then, according to the chairs it is optional. Why is IPv6 policy any different? If you have a /29 IPv6 block, maybe you won't need any more for a few years, if ever. Or you can always rent a block from one of the brokers who have huge stockpiles. So the NCC still has no power over you. Why bother to register those /48s as required by policy. Policy is optional, the chairs said. Those LIRs that enter optional details about the End User in an IPv6 assignment may simply follow the same process as they do for IPv4. Maybe using the same script to generate the object. If they change this for IPv4 they may make the same change for IPv6 as well. As many people say, they want to handle IPv4 and IPv6 the same way. LIRs may now be looking at all that has been said during this discussion and thinking how they can use this information to reduce their workload and costs. Many LIRs also say they don't want to publish any details of their customers in a public database. They have only done so in the past because they correctly believed it was a policy requirement. Now they know it is either no longer a requirement or not enforceable, why would they do it? Things will probably not change overnight. But gradually these objects, this data will disappear. It makes no difference now if 2023-04 is approved or not. ALL LIRs now know this policy requirement is not enforceable. No action will be taken against them if they stop entering End User details or even start removing it. This is the cat you have let out of the bag. This is the change to the policy landscape you have made and you cannot go back. Another aspect is how to change policy. If LIRs decide to ignore some other aspect of policy, they again know there is no action that can be taken against them. Over time people will say this is now accepted behaviour. Then it will be normalised by changing the policy to match the behaviour. So who is in control now? The 'community' can make any policy it likes. The LIRs can choose to ignore it because the chairs say it is optional. The RIPE NCC has no power to do anything. Certainly not against the bigger LIRs. The operator community that has driven this proposal through, for their convenience, has shown an indifferent and uncompromising attitude to anyone outside of their group. I am sure this has not gone unnoticed. Civil society (ie voters) and law enforcement have far more influence over politicians than this operator community has. EU politicians are not averse to making regulations in this area. Don't be surprised if they write regulations specifying what a public registry of Internet number resources should look like (Nis3?). After all, we don't have our own specification. An industry that has an impact on the lives of just about everyone on the planet, is critical to government, industry, commerce and society, can only expect to be self regulating if it is willing to cooperate and compromise with other groups in society. If you want to live in your own little bubble, do everything your way as you have for the last 20 years, don't be surprised when change comes and is enforced on you. cheers denis ======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================
Hi, On Tue, Apr 09, 2024 at 04:31:06AM +0200, denis walker wrote:
Tore you are absolutely right, the cat is out of the bag...but which cat? You seem fine about how the RIPE NCC has been mis-interpreting policy for 10 years and how they have no power to enforce it other than the nuclear option, which we all know they will not use. The revelations from this discussion have completely changed the landscape for RIPE policy. It has been totally undermined.
There is no "change of landscape" or "undermining of policy" here - to anyone following address policy it was always clear that there is some leeway in registering end user assignments (INFRA-AW), and that the NCC cannot enforce correctness of all data. They can and do audits, and back when there was still new space to be had, such an audit could have very unpleasant consequences - namely, reducing the AW to 0, and refusing allocation of new blocks, until documentation was fixed. Since there is no more v4 space at the NCC, all these levers are gone (through no fault of policy or the NCC). Also it was discussed a number of times here on the list and in the meetings what LIRs should put into the admin-c: and tech-c:, given that natural persons being involved might not agree to be listed in a public database with their personal information. So "register the NOC here", and for single user end customers "register the LIR contacts" has been established practice for a long time. So while I totally agree that we all (as "the LIRs in the RIPE region") might not have been following policy to *the letter*, overall most of us followed it to the *spirit* - "put someone in there that will take responsibility and can take action if needed" (which the letter "put someone in who is on-site" will not achieve). Should we work on improving the documents? By all means, yes. Has this anything to do with 2023-04, or the last call for it? Hardly. Gert Doering -- speaking as LIR contact, and with some policy experience -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler 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, In my opinion, if we are having this discussion for so long, perhaps it is because the original objective of the proposal, which is "Add AGGREGATED-BY-LIR status for IPv4 PA assignments", is being overstepped. Constructively, I think that adding the AGGREGATED-BY-LIR option for IPv4 PA assignments is a good idea and should be confined to Section 7.0 (Types of Address Space), as is the case with the other types. Section 6.2 does not currently refer to any type. In my opinion, it is compatible to include the new type AGGREGATED-BY-LIR while keeping the information in the current section 6.2 to facilitate consensus. It may be important to analyze situations of non-recording of information in the database, anonymization of information, etc., but this is not related to the proposal to include the new type and should be analyzed separately. Best Regards, kix -- Rodolfo García (kix) http://www.kix.es/ "I asked him once how to change the key bindings and Dave said 'You use the Change Configuration command. On Unix it is abbreviated as cc.' Dave Conroy and Lawrence Stewart. Disclaimer: This email expresses my personal views only and does not necessarily reflect the views or policies of any company, organization or institution. On Tuesday, April 9th, 2024 at 16:50, Gert Doering <gert@space.net> wrote:
Hi,
On Tue, Apr 09, 2024 at 04:31:06AM +0200, denis walker wrote:
Tore you are absolutely right, the cat is out of the bag...but which cat? You seem fine about how the RIPE NCC has been mis-interpreting policy for 10 years and how they have no power to enforce it other than the nuclear option, which we all know they will not use. The revelations from this discussion have completely changed the landscape for RIPE policy. It has been totally undermined.
There is no "change of landscape" or "undermining of policy" here - to anyone following address policy it was always clear that there is some leeway in registering end user assignments (INFRA-AW), and that the NCC cannot enforce correctness of all data.
They can and do audits, and back when there was still new space to be had, such an audit could have very unpleasant consequences - namely, reducing the AW to 0, and refusing allocation of new blocks, until documentation was fixed. Since there is no more v4 space at the NCC, all these levers are gone (through no fault of policy or the NCC).
Also it was discussed a number of times here on the list and in the meetings what LIRs should put into the admin-c: and tech-c:, given that natural persons being involved might not agree to be listed in a public database with their personal information. So "register the NOC here", and for single user end customers "register the LIR contacts" has been established practice for a long time.
So while I totally agree that we all (as "the LIRs in the RIPE region") might not have been following policy to the letter, overall most of us followed it to the spirit - "put someone in there that will take responsibility and can take action if needed" (which the letter "put someone in who is on-site" will not achieve).
Should we work on improving the documents? By all means, yes.
Has this anything to do with 2023-04, or the last call for it? Hardly.
Gert Doering -- speaking as LIR contact, and with some policy experience -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler 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
Moin, am 05.04.24 um 16:51 schrieb denis walker:
I used to wonder why no one would even talk about bringing the RIPE Database into the modern world.
Because this is address-policy (»The Address Policy Working Group develops policies relating to the management and registration of Internet number resources.«), not database (»The Database Working Group deals […]«).
Europol has expressed serious concerns about these changes.
Europol has the means to challenge the maintainer of the address space for more information on individual usage; there is no real thread to Europol's operation by the change, it might just become less convenient to get the wanted information.
If someone had informed them earlier of the changes being considered that may affect them,
Well, this is happening all in the open. IF Europol is depending so greatly on the RIPE DB, they SHOULD be following the PDP already for years and years and voiced their concerns more timely.
proceed with all haste to
No haste visible at all; this is about 2023-04 — we already are in 2024-04. Regards, -kai
Hi Denis, We have read through your message several times, but do not see any new arguments against proposal 2023-04 that have not already been discussed at length in the previous phases of the policy development process. The main purpose of the Concluding phase is to provide an opportunity for people who have missed the previous two phases to oppose the proposal (see ripe-781), not to rehash discussions from the previous phases. Therefore, rather than repeat our answers in this thread, we chose to simply refer you back to our previous discussions in the previous two phases. Best regards, Jeroen & Tore
Op 5 apr 2024, om 16:51 heeft denis walker <ripedenis@gmail.com> het volgende geschreven:
Colleagues
I am not surprised this policy proposal (2023-04) has gone to last call. I expected this from the start, no matter what anyone said. And I won't be surprised when it is approved. I used to wonder why no one would even talk about bringing the RIPE Database into the modern world. Why continue to use an ancient, broken tool that is barely fit for purpose? It is quite obvious now. Playing on the complexity and difficulties with using the database allows people to justify changing the purpose and the rules, to make it more convenient. That is simpler and cheaper than fixing the tool. It is easy for a small vocal group to sell 'simple and cheap' to a silent majority. Convenience is easier to do than right. But it may have consequences.
The proposers have assured us all that this proposal is about nothing more than introducing this optional, minor, inconsequential feature that changes nothing. They have argued that the RIPE NCC has "repeatedly" verified their claim that this proposal changes nothing 'of significance'. This is based on the RIPE NCC legal team's confusing impact analysis and the comments made once and referred to once by the RIPE NCC Registration Services through messages passed on by the policy officer. The legal team declined to clarify the confusing wording of their impact analysis. No one from Registration Services was willing to discuss the claims that they have been wrongly applying the policy for a number of years, or the reason why and when they stopped correctly applying the policy. I thought RIPE NCC staff were being encouraged to be more involved in community discussions?
It has been said and confirmed recently by several people from the community that we no longer understand what some of the registration data in the RIPE Database means, why it is there and why we have these rules about it. This is despite the actual, current wording of these rules having been written into a version of the policy published in October 2003 that was authored by some people who are still leading members of this community, and at the time were RIPE NCC staff. The infamous line being removed by this proposal was a re-wording of earlier rules introduced in address policy with a long list of early authors, again including some people who are still leading members of this community. I asked if any one of these community leaders would offer some background information to the community on this, now poorly understood, registration data and the rules governing it. That may have helped with our current understanding. If we actually understood the data and rules that we are about to change, we might have more confidence in doing so. But nothing was said on this background.
Europol has expressed serious concerns about these changes. They have stated that it takes time for them to consult with national LEAs, the EU commision and other partners. If someone had informed them earlier of the changes being considered that may affect them, they may have had sufficient time to do these consultations. Or perhaps they would have been able to express their deep concerns at an early stage, before the minds of the vocal few were made up. I did suggest early on in the discussion that the RIPE NCC contacts stakeholders of the RIPE Database and invite them to join the discussion. I was quickly told by other community members on the mailing list that this was not part of the policy development process. [Maybe it should be...]
It is extraordinary that we have now reached a position where the convenience of a handful of vocal operators in this community is considered so important that we must proceed with all haste to introduce this optional, minor, inconsequential feature that changes nothing, without delay. That is without even a delay to allow Europol to complete it's consultations and report back to the working group. I saw references recently on the ripe.net website and LinkedIn about some productive meeting between the RIPE NCC and some internet governance groups. I hope the attitude of the technical community over this proposal won't undermine those meeting achievements. A technical community that clearly has not watched John Curran's keynote speech at NANOG that covers this very situation involving internet governance, the technical community and civil society. I would advise you all to watch it: https://www.youtube.com/watch?v=U1Ip39Qv-Zk
You may question my comments about the vocal few. But the details of the who and how many are there for everyone to see in the public archive of these mailing lists. Only 22 people commented during the months of discussion over 2023-04. Of those, 6 people only made one comment and another 6 only two comments. Some of those 22 also opposed this proposal. So the number of people who actually expressed support is quite small. When you analyse these details for proposals across multiple WGs in recent years, and cross reference the who and how many, you see that there is a very small number of vocal people who tend to dominate these discussions. It is basically this small group of people whose voices dictate RIPE policy. The problem there is that we may find policy, accidentally or intentionally, following an agenda that suits the needs of these people, rather than the wider, silent community. Unfortunately, we don't have any other way to do this at the moment. However, when a change is controversial, has many serious objections and offers so few benefits, to push it through with so few supporters is very questionable. Especially as it has been well established during the long discussions that we (collectively) do not even understand the registration data and governing rules that we are about to substantially change. Nor do we have any firm evidence that even the minor benefits claimed by the proposers are likely to occur.
I could go on and dispute the co-chairs' reasoning for declaring a rough consensus. But I have said it all before and it has been disregarded. Although I don't believe I have yet asked them for the evidence or statistical reasoning why they assert that this change will encourage those who don't declare any End User data now, will suddenly decide to provide it after this change.
It is of course total nonsense to suggest that this change will end up offering more accurate data on assignments to End Users. It is quite possible that those resource holders that currently don't declare End User assignment data now, will simply create two appropriately sized, anonymous, aggregated objects below each of their allocations. That is 'job done' as far as operations is concerned. Those objects will never need to be updated again. No one has any clue how much, if any, of that address space is in use, by how many End Users with how many addresses each, or who the End Users are, or even if the same block of address space has been assigned to more than one End User by mistake. All that information will be lost. Including one of the basic functions of the registry, to ensure uniqueness of address usage.
Quoting statistics on the number of allocations with no assignments is of course simply playing with numbers. It adds nothing to this discussion, but is intended to look like a supporting argument. A perceived problem that needs to be solved, but may not even exist on the implied scale. We don't know how many of those allocations are the /22 and /24 allocations made during the final stages of runout. These were 'intended' to be for new entrants into the industry who planned to provide LIR services. They would not be expected to have assignments if they were used for their infrastructure. (Or maybe they were not allocated as intended?) Many allocations are also made to organisations who do not provide LIR services and have no End Users. The address space is simply used by their organisation.
Leo's final comment is a good one to end on. "Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy." This basically sums up everything. ['want' 'like'] The RIPE NCC stopped enforcing address policy after runout because they did not believe they had any power to do so. Here Leo is suggesting that complying with policy is a choice. Some LIRs will choose to comply, others will choose not to comply with RIPE policy. Neither this community nor the RIPE NCC has any power to enforce any policy on operators. We can agree or disagree on any policy we like, but it cannot be enforced. RIPE policy has no teeth.
The proposers have assured us that their focus is on providing this aggregation feature. So we must be able to assume that they, and the co-chairs, have deeply considered the implications of this change to the "status:'' attribute. So there shouldn't be any unintended consequences...
Hopefully common sense will prevail and we will pause this process to assess where we have been, where we are and where we are going. (I think that is unlikely to happen...)
cheers denis
======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================
On Mon, 11 Mar 2024 at 09:30, Leo Vegoda <leo@vegoda.org> wrote:
Dear Address Policy WG,
There was a consensus on this proposal and we are moving it forward to Last Call. The RIPE NCC will publish an announcement with dates.
There was a request, in Rome, for clarity over whether aggregated assignments needed to have a fixed size or could vary. The proposers suggested that a fixed size should be optional.
We extended the list discussion by a month and the two issues raised have been addressed.
One was End User sites not having the End User's own admin-c instead of the LIR's. There has been extensive discussion of this. One key reason given is that it is common and acceptable to outsource a part of an organisation's operations to another, more skilled, operator. The RIPE NCC's impact analysis noted that the proposal "simply leaves the status quo unchanged." It would not need to update its operational processes.
Concerns were also raised that aggregating assignments would impact criminal investigations. But this proposal is intended to improve the quality of data registered by offering LIRs a less arduous way to share registration data. At the end of 2023 there were over 19,000 PA allocations without any assignments. Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy.
Kind regards,
Leo Vegoda, for the Address Policy WG co-chairs
--
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
--
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
Hello, First, let me note that this is not a comment on the policy discussion, which has now concluded, but a separate response regarding how we ensure compliance with RIPE Policy. We would like to clarify some aspects that may be unclear to the community. The RIPE NCC has always emphasised the importance of documenting networks through assignments, and we are consistent in what we consider valid contact information for End User/customer assignments. This stance has not changed because of IPv4 runout. We do consider the member’s contact details to be valid contact information for the customer if this is what the member and their customer have agreed suits their business needs. There are a number of policies we follow for ensuring correct contact information. The policy on IPv4 allocation, RIPE-804, requires that contact information in the database must be correct [1]. The same policy also mentions that an LIR can be closed if it “consistently violates the RIPE community’s policies” [2]. We build on this in our public closure procedure, where we state that incorrect registration in the RIPE Database can lead to termination of a membership [3]. Together, this means the RIPE NCC is empowered to close down a member for incorrect contact information in the database, and this includes incorrect data about a member’s customers. When we discover incorrect information, our practice is to follow a collaborative approach in which we help our members correct the errors. This is in line with our overall mission to support the broader Internet community, not through punitive measures, but through educating members in our processes for requests, ARCs and training courses so that we can collectively work to create an accurate registry. See also our impact analysis for policy proposal 2017-02 (“Regular abuse-c Validation”) for a detailed description of how we work with resource holders to correct information before considering closure, in this case regarding “abuse-c:” contacts [4]. We do not consider it beneficial to the Internet community or our members to immediately terminate memberships. However, if a member submits repeated and intentionally incorrect contact information, this will result in stronger actions on our end. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region: https://www.ripe.net/publications/docs/ripe-804/#4 [2] Idem: https://www.ripe.net/publications/docs/ripe-804/#9 [3] Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources: https://www.ripe.net/publications/docs/ripe-808/#a1211c [4] Regular abuse-c Validation: https://www.ripe.net/membership/policies/proposals/2017-02/#relevant-ripe-po... On 05/04/2024 16:51, denis walker wrote:
Colleagues
I am not surprised this policy proposal (2023-04) has gone to last call. I expected this from the start, no matter what anyone said. And I won't be surprised when it is approved. I used to wonder why no one would even talk about bringing the RIPE Database into the modern world. Why continue to use an ancient, broken tool that is barely fit for purpose? It is quite obvious now. Playing on the complexity and difficulties with using the database allows people to justify changing the purpose and the rules, to make it more convenient. That is simpler and cheaper than fixing the tool. It is easy for a small vocal group to sell 'simple and cheap' to a silent majority. Convenience is easier to do than right. But it may have consequences.
The proposers have assured us all that this proposal is about nothing more than introducing this optional, minor, inconsequential feature that changes nothing. They have argued that the RIPE NCC has "repeatedly" verified their claim that this proposal changes nothing 'of significance'. This is based on the RIPE NCC legal team's confusing impact analysis and the comments made once and referred to once by the RIPE NCC Registration Services through messages passed on by the policy officer. The legal team declined to clarify the confusing wording of their impact analysis. No one from Registration Services was willing to discuss the claims that they have been wrongly applying the policy for a number of years, or the reason why and when they stopped correctly applying the policy. I thought RIPE NCC staff were being encouraged to be more involved in community discussions?
It has been said and confirmed recently by several people from the community that we no longer understand what some of the registration data in the RIPE Database means, why it is there and why we have these rules about it. This is despite the actual, current wording of these rules having been written into a version of the policy published in October 2003 that was authored by some people who are still leading members of this community, and at the time were RIPE NCC staff. The infamous line being removed by this proposal was a re-wording of earlier rules introduced in address policy with a long list of early authors, again including some people who are still leading members of this community. I asked if any one of these community leaders would offer some background information to the community on this, now poorly understood, registration data and the rules governing it. That may have helped with our current understanding. If we actually understood the data and rules that we are about to change, we might have more confidence in doing so. But nothing was said on this background.
Europol has expressed serious concerns about these changes. They have stated that it takes time for them to consult with national LEAs, the EU commision and other partners. If someone had informed them earlier of the changes being considered that may affect them, they may have had sufficient time to do these consultations. Or perhaps they would have been able to express their deep concerns at an early stage, before the minds of the vocal few were made up. I did suggest early on in the discussion that the RIPE NCC contacts stakeholders of the RIPE Database and invite them to join the discussion. I was quickly told by other community members on the mailing list that this was not part of the policy development process. [Maybe it should be...]
It is extraordinary that we have now reached a position where the convenience of a handful of vocal operators in this community is considered so important that we must proceed with all haste to introduce this optional, minor, inconsequential feature that changes nothing, without delay. That is without even a delay to allow Europol to complete it's consultations and report back to the working group. I saw references recently on the ripe.net website and LinkedIn about some productive meeting between the RIPE NCC and some internet governance groups. I hope the attitude of the technical community over this proposal won't undermine those meeting achievements. A technical community that clearly has not watched John Curran's keynote speech at NANOG that covers this very situation involving internet governance, the technical community and civil society. I would advise you all to watch it: https://www.youtube.com/watch?v=U1Ip39Qv-Zk
You may question my comments about the vocal few. But the details of the who and how many are there for everyone to see in the public archive of these mailing lists. Only 22 people commented during the months of discussion over 2023-04. Of those, 6 people only made one comment and another 6 only two comments. Some of those 22 also opposed this proposal. So the number of people who actually expressed support is quite small. When you analyse these details for proposals across multiple WGs in recent years, and cross reference the who and how many, you see that there is a very small number of vocal people who tend to dominate these discussions. It is basically this small group of people whose voices dictate RIPE policy. The problem there is that we may find policy, accidentally or intentionally, following an agenda that suits the needs of these people, rather than the wider, silent community. Unfortunately, we don't have any other way to do this at the moment. However, when a change is controversial, has many serious objections and offers so few benefits, to push it through with so few supporters is very questionable. Especially as it has been well established during the long discussions that we (collectively) do not even understand the registration data and governing rules that we are about to substantially change. Nor do we have any firm evidence that even the minor benefits claimed by the proposers are likely to occur.
I could go on and dispute the co-chairs' reasoning for declaring a rough consensus. But I have said it all before and it has been disregarded. Although I don't believe I have yet asked them for the evidence or statistical reasoning why they assert that this change will encourage those who don't declare any End User data now, will suddenly decide to provide it after this change.
It is of course total nonsense to suggest that this change will end up offering more accurate data on assignments to End Users. It is quite possible that those resource holders that currently don't declare End User assignment data now, will simply create two appropriately sized, anonymous, aggregated objects below each of their allocations. That is 'job done' as far as operations is concerned. Those objects will never need to be updated again. No one has any clue how much, if any, of that address space is in use, by how many End Users with how many addresses each, or who the End Users are, or even if the same block of address space has been assigned to more than one End User by mistake. All that information will be lost. Including one of the basic functions of the registry, to ensure uniqueness of address usage.
Quoting statistics on the number of allocations with no assignments is of course simply playing with numbers. It adds nothing to this discussion, but is intended to look like a supporting argument. A perceived problem that needs to be solved, but may not even exist on the implied scale. We don't know how many of those allocations are the /22 and /24 allocations made during the final stages of runout. These were 'intended' to be for new entrants into the industry who planned to provide LIR services. They would not be expected to have assignments if they were used for their infrastructure. (Or maybe they were not allocated as intended?) Many allocations are also made to organisations who do not provide LIR services and have no End Users. The address space is simply used by their organisation.
Leo's final comment is a good one to end on. "Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy." This basically sums up everything. ['want' 'like'] The RIPE NCC stopped enforcing address policy after runout because they did not believe they had any power to do so. Here Leo is suggesting that complying with policy is a choice. Some LIRs will choose to comply, others will choose not to comply with RIPE policy. Neither this community nor the RIPE NCC has any power to enforce any policy on operators. We can agree or disagree on any policy we like, but it cannot be enforced. RIPE policy has no teeth.
The proposers have assured us that their focus is on providing this aggregation feature. So we must be able to assume that they, and the co-chairs, have deeply considered the implications of this change to the "status:'' attribute. So there shouldn't be any unintended consequences...
Hopefully common sense will prevail and we will pause this process to assess where we have been, where we are and where we are going. (I think that is unlikely to happen...)
cheers denis
======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================
On Mon, 11 Mar 2024 at 09:30, Leo Vegoda <leo@vegoda.org> wrote:
Dear Address Policy WG,
There was a consensus on this proposal and we are moving it forward to Last Call. The RIPE NCC will publish an announcement with dates.
There was a request, in Rome, for clarity over whether aggregated assignments needed to have a fixed size or could vary. The proposers suggested that a fixed size should be optional.
We extended the list discussion by a month and the two issues raised have been addressed.
One was End User sites not having the End User's own admin-c instead of the LIR's. There has been extensive discussion of this. One key reason given is that it is common and acceptable to outsource a part of an organisation's operations to another, more skilled, operator. The RIPE NCC's impact analysis noted that the proposal "simply leaves the status quo unchanged." It would not need to update its operational processes.
Concerns were also raised that aggregating assignments would impact criminal investigations. But this proposal is intended to improve the quality of data registered by offering LIRs a less arduous way to share registration data. At the end of 2023 there were over 19,000 PA allocations without any assignments. Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy.
Kind regards,
Leo Vegoda, for the Address Policy WG co-chairs
--
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 (10)
-
Brian Storey -
Carlos Friaças -
denis walker -
Gert Doering -
Jeroen Lauwers -
Kai 'wusel' Siering -
Leo Vegoda -
Marco Schmidt -
Rodolfo García Peñas (kix) -
Tore Anderson