From ripedenis at gmail.com Tue Nov 7 12:59:53 2023 From: ripedenis at gmail.com (denis walker) Date: Tue, 7 Nov 2023 12:59:53 +0100 Subject: [address-policy-wg] 2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: Hi Leo, Colleagues I am both saddened and yet not surprised by this announcement to move this proposal to the review phase. It doesn't seem to matter what anyone says, I suspect this proposal will be approved. You included a link to the Policy Development Process (ripe-781). Pity you have not followed it. Now suggesting we follow a process, Jim Reid will argue I am trying to turn RIPE into some "process heavy organisation". But the PDP is a policy. So do we get to pick and choose which bits of which policies we apply or ignore? If that is the case why not just dump all policy and work to a general understanding. It might be more honest. Let's walk through the PDP as defined in ripe-781. Starting with '2. The Process'. "These phases are detailed below with proposed timelines for the various stages. These may differ for individual proposals, but the actual timelines must be documented." In the opening email Angela stated that the four week Discussion Phase will run until 3 October 2023. "At the end of each phase of the process, one of the chairs of the relevant WG will summarise the state of discussion on the WG mailing list." This has not been done. "In all phases of the RIPE PDP, suggestions for changes to the proposal and objections regarding the proposal must be justified with supporting arguments and then addressed adequately by the proposer or by any supporter of the proposal." I have objected to this proposal on several grounds. I have justified my objections with significant supporting arguments. A number of people have supported the principle of my objections. Some people who initially gave the proposal a "+1" response have since withdrawn that support based on my objections. Neither the proposers, nor their supporters (the +1 brigade), have addressed my objections. Even worse than that, the proposers still deny that this proposal changes anything substantially with regard to address policy. They still claim it does not allow anything to be done that cannot already be done. I have adequately shown this argument to be false. Neither the proposers nor their supporters have even acknowledged this fact. A number of people have agreed that such a fundamental change to address policy should not be introduced as a (hidden) side effect of another, apparently inconsequential, change. If such a change is to be introduced, which may or may not have merits of its own, it should be openly discussed as a separate topic. Given that these objections are highly significant, and that they have been completely ignored by the proposers and supporters and not "addressed adequately", the chairs of the AP-WG cannot declare an initial consensus and move this proposal to the review phase. In '2.2 Discussion Phase' it says: "If the proposer decides to take the proposal to the next phase, they need to produce a draft RIPE Document which should be published within four weeks after the end of the Discussion Phase, before the proposal can be moved to the Review Phase." This has not been done. "The RIPE NCC will need to publish an impact analysis for the proposal 'before' it can be moved to the Review Phase." This has not been done. I am raising these issues today as it is the last day of the discussion phase according to the diagram in Appendix A of ripe-781. Even though the diagram does not agree with the text in ripe-781. I have allowed the 5 weeks after the discussion phase shown in the diagram, rather than the 4 weeks stated in the text. This proposal cannot be moved to the review phase under the current circumstances, if we are actually following the PDP policy. Let me summarise my objections. The proposer claims this is an inconsequential change to address policy that does not permit anything to be done that cannot already be done. That has been proven to be a false claim. This is a major change to address policy that will undermine the whole concept of the public registry that we have understood for the last 30 years. Regardless of the merits of such a major change, we cannot allow such a change based on a few "+1" comments from a handful of the small group of people who dominate and control all policy decisions in this region. AFAIK neither the proposer, nor the RIPE NCC, nor the proposal supporters have made any attempt to reach out to other stakeholder groups who use the RIPE Database to inform them of this discussion, advise them of the potential consequences and invite them to join this discussion. Stakeholder groups like LEAs, government regulators, private investigators, abuse management organisations, security community, researchers, and others (who the Database Task Force never identified). cheers denis On Fri, 27 Oct 2023 at 03:51, Leo Vegoda wrote: > > Dear WG, > > The Discussion Phase of policy proposal 2023-04 "Add AGGREGATED-BY-LIR > status for IPv4 PA assignments" has now ended. Many thanks to all for > your comments. > > The proposal will now move forward to the Review Phase. > > The RIPE NCC will prepare an impact analysis and a draft RIPE Document. > > More details about the phases of the Policy Development Process are > published here: https://www.ripe.net/publications/docs/ripe-781 > > You'll also see an announcement from the RIPE NCC soon. > > Kind regards, > > Leo Vegoda for the co-chairs > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From gert at space.net Tue Nov 7 13:13:49 2023 From: gert at space.net (Gert Doering) Date: Tue, 7 Nov 2023 13:13:49 +0100 Subject: [address-policy-wg] 2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: Hi, On Tue, Nov 07, 2023 at 12:59:53PM +0100, denis walker wrote: > I am both saddened and yet not surprised by this announcement to move > this proposal to the review phase. As per the PDP, the proposer decides whether to move onward after discussion phase. If the proposer sees value in having a NCC impact analysis, they might do so even if there was some opposition in discussion phase - because it might bring clarity on the merits of arguments either way. > It doesn't seem to matter what > anyone says, I suspect this proposal will be approved. You included a > link to the Policy Development Process (ripe-781). Pity you have not > followed it. The text could be a bit more clear here, but "If the suggested comments and changes are not so significant as to require a new Discussion Phase, the proposer and WG chairs can decide to move the proposal to the next phase (Review Phase) with a new version of the proposal incorporating the necessary edits." is what gives them the option to move forward - you didn't suggest massive edits, but to kill the proposal, which is still open. [..] > In '2.2 Discussion Phase' it says: > > "If the proposer decides to take the proposal to the next phase, they > need to produce a draft RIPE Document which should be published within > four weeks after the end of the Discussion Phase, before the proposal > can be moved to the Review Phase." There is a draft document. It does not say "a new draft document" here. (This text is relevant if there was no formal draft document at the beginning of the Discussion phase, which can be done "to test the waters" before writing up something) > This has not been done. It has. > "The RIPE NCC will need to publish an impact analysis for the proposal > 'before' it can be moved to the Review Phase." > > This has not been done. The proposal is not in Review Phase *yet*, and Leo did not suggest otherwise. https://www.ripe.net/participate/policies/proposals/2023-04 does not say "in Review Phase". So indeed, the IA has not been published, but since it's not stating anywhere "in Review Phase", this is not a contradiction. IAs can take time, so this is not an instant over-night thing in the best case, and there is no urgency. [..] > This proposal cannot be moved to the review phase under the current > circumstances, if we are actually following the PDP policy. It can. > Let me summarise my objections. The proposer claims this is an > inconsequential change to address policy that does not permit anything > to be done that cannot already be done. That has been proven to be a > false claim. This is a major change to address policy that will > undermine the whole concept of the public registry that we have > understood for the last 30 years. This, in particular, is *your* claim, which I'd like see either backed or dismissed by the impact analysis - I see this as on way "proven". So it's very useful to move forward to "Review Phase with a full IA". > Regardless of the merits of such a > major change, we cannot allow such a change based on a few "+1" > comments from a handful of the small group of people who dominate and > control all policy decisions in this region. AFAIK neither the > proposer, nor the RIPE NCC, nor the proposal supporters have made any > attempt to reach out to other stakeholder groups who use the RIPE > Database to inform them of this discussion, advise them of the > potential consequences and invite them to join this discussion. This is not a requirement of the PDP. Proposals are announced to the PDP-announce-Mailing list, and people interested in policy change are expected to read this. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From leo at vegoda.org Tue Nov 7 22:04:28 2023 From: leo at vegoda.org (Leo Vegoda) Date: Tue, 7 Nov 2023 13:04:28 -0800 Subject: [address-policy-wg] 2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: Dear Denis, Our processes don't move super fast. This is partly deliberate. We don't want to railroad the community. It is also practical. There are actions to be carried out between the end of one phase and the start of another. The proposers have taken account of the "significant comments or changes [...] suggested during the Discussion Phase." They have been preparing a draft RIPE Document with help from the RIPE NCC. The RIPE NCC has been developing an impact analysis. They understandably don't start that work until there's a decision on whether the proposal will move forward. All of these things take some time to accomplish. That is why there is a small gap between the formal end of the Discussion phase and the start of the Review phase. Your objections have not been ignored. We will schedule time in Rome to discuss the objections you have raised. Kind regards, Leo Vegoda for the co-chairs On Tue, 7 Nov 2023 at 04:00, denis walker wrote: > > Hi Leo, Colleagues > > I am both saddened and yet not surprised by this announcement to move > this proposal to the review phase. It doesn't seem to matter what > anyone says, I suspect this proposal will be approved. You included a > link to the Policy Development Process (ripe-781). Pity you have not > followed it. Now suggesting we follow a process, Jim Reid will argue I > am trying to turn RIPE into some "process heavy organisation". But the > PDP is a policy. So do we get to pick and choose which bits of which > policies we apply or ignore? If that is the case why not just dump all > policy and work to a general understanding. It might be more honest. > > Let's walk through the PDP as defined in ripe-781. Starting with '2. > The Process'. > > "These phases are detailed below with proposed timelines for the > various stages. These may differ for individual proposals, but the > actual timelines must be documented." > > In the opening email Angela stated that the four week Discussion Phase > will run until 3 October 2023. > > "At the end of each phase of the process, one of the chairs of the > relevant WG will summarise the state of discussion on the WG mailing > list." > > This has not been done. > > "In all phases of the RIPE PDP, suggestions for changes to the > proposal and objections regarding the proposal must be justified with > supporting arguments and then addressed adequately by the proposer or > by any supporter of the proposal." > > I have objected to this proposal on several grounds. I have justified > my objections with significant supporting arguments. A number of > people have supported the principle of my objections. Some people who > initially gave the proposal a "+1" response have since withdrawn that > support based on my objections. Neither the proposers, nor their > supporters (the +1 brigade), have addressed my objections. Even worse > than that, the proposers still deny that this proposal changes > anything substantially with regard to address policy. They still claim > it does not allow anything to be done that cannot already be done. I > have adequately shown this argument to be false. Neither the proposers > nor their supporters have even acknowledged this fact. A number of > people have agreed that such a fundamental change to address policy > should not be introduced as a (hidden) side effect of another, > apparently inconsequential, change. If such a change is to be > introduced, which may or may not have merits of its own, it should be > openly discussed as a separate topic. Given that these objections are > highly significant, and that they have been completely ignored by the > proposers and supporters and not "addressed adequately", the chairs of > the AP-WG cannot declare an initial consensus and move this proposal > to the review phase. > > In '2.2 Discussion Phase' it says: > > "If the proposer decides to take the proposal to the next phase, they > need to produce a draft RIPE Document which should be published within > four weeks after the end of the Discussion Phase, before the proposal > can be moved to the Review Phase." > > This has not been done. > > "The RIPE NCC will need to publish an impact analysis for the proposal > 'before' it can be moved to the Review Phase." > > This has not been done. > > I am raising these issues today as it is the last day of the > discussion phase according to the diagram in Appendix A of ripe-781. > Even though the diagram does not agree with the text in ripe-781. I > have allowed the 5 weeks after the discussion phase shown in the > diagram, rather than the 4 weeks stated in the text. > > This proposal cannot be moved to the review phase under the current > circumstances, if we are actually following the PDP policy. > > Let me summarise my objections. The proposer claims this is an > inconsequential change to address policy that does not permit anything > to be done that cannot already be done. That has been proven to be a > false claim. This is a major change to address policy that will > undermine the whole concept of the public registry that we have > understood for the last 30 years. Regardless of the merits of such a > major change, we cannot allow such a change based on a few "+1" > comments from a handful of the small group of people who dominate and > control all policy decisions in this region. AFAIK neither the > proposer, nor the RIPE NCC, nor the proposal supporters have made any > attempt to reach out to other stakeholder groups who use the RIPE > Database to inform them of this discussion, advise them of the > potential consequences and invite them to join this discussion. > Stakeholder groups like LEAs, government regulators, private > investigators, abuse management organisations, security community, > researchers, and others (who the Database Task Force never > identified). > > cheers > denis > > On Fri, 27 Oct 2023 at 03:51, Leo Vegoda wrote: > > > > Dear WG, > > > > The Discussion Phase of policy proposal 2023-04 "Add AGGREGATED-BY-LIR > > status for IPv4 PA assignments" has now ended. Many thanks to all for > > your comments. > > > > The proposal will now move forward to the Review Phase. > > > > The RIPE NCC will prepare an impact analysis and a draft RIPE Document. > > > > More details about the phases of the Policy Development Process are > > published here: https://www.ripe.net/publications/docs/ripe-781 > > > > You'll also see an announcement from the RIPE NCC soon. > > > > Kind regards, > > > > Leo Vegoda for the co-chairs > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From ripedenis at gmail.com Tue Nov 7 22:26:41 2023 From: ripedenis at gmail.com (denis walker) Date: Tue, 7 Nov 2023 22:26:41 +0100 Subject: [address-policy-wg] 2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: Hi Gert Thanks for your comments. But I think you have missed a couple of important points. It says in the PDP: "In all phases of the RIPE PDP, suggestions for changes to the proposal and objections regarding the proposal must be justified with supporting arguments and then addressed adequately by the proposer or by any supporter of the proposal." Let me edit that down a bit: In all phases of the RIPE PDP...objections...addressed adequately... So in the discussion phase my objections must be addressed adequately. The proposers have not even acknowledged my objections and still maintain the false view that this proposal is inconsequential. Also you said I haven't suggested any significant change to the proposal. My objections could be addressed by not removing the line: "When an End User has a network using public address space this must be registered separately with the contact details of the End User." That would be a significant change. cheers denis On Tue, 7 Nov 2023 at 13:13, Gert Doering wrote: > > Hi, > > On Tue, Nov 07, 2023 at 12:59:53PM +0100, denis walker wrote: > > I am both saddened and yet not surprised by this announcement to move > > this proposal to the review phase. > > As per the PDP, the proposer decides whether to move onward after > discussion phase. If the proposer sees value in having a NCC impact > analysis, they might do so even if there was some opposition in > discussion phase - because it might bring clarity on the merits of > arguments either way. > > > It doesn't seem to matter what > > anyone says, I suspect this proposal will be approved. You included a > > link to the Policy Development Process (ripe-781). Pity you have not > > followed it. > > The text could be a bit more clear here, but > > "If the suggested comments and changes are not so significant as > to require a new Discussion Phase, the proposer and WG chairs can > decide to move the proposal to the next phase (Review Phase) with > a new version of the proposal incorporating the necessary edits." > > is what gives them the option to move forward - you didn't suggest > massive edits, but to kill the proposal, which is still open. > > [..] > > In '2.2 Discussion Phase' it says: > > > > "If the proposer decides to take the proposal to the next phase, they > > need to produce a draft RIPE Document which should be published within > > four weeks after the end of the Discussion Phase, before the proposal > > can be moved to the Review Phase." > > There is a draft document. It does not say "a new draft document" here. > > (This text is relevant if there was no formal draft document at the > beginning of the Discussion phase, which can be done "to test the waters" > before writing up something) > > > This has not been done. > > It has. > > > "The RIPE NCC will need to publish an impact analysis for the proposal > > 'before' it can be moved to the Review Phase." > > > > This has not been done. > > The proposal is not in Review Phase *yet*, and Leo did not suggest > otherwise. > > https://www.ripe.net/participate/policies/proposals/2023-04 > > does not say "in Review Phase". > > So indeed, the IA has not been published, but since it's not stating > anywhere "in Review Phase", this is not a contradiction. IAs can take > time, so this is not an instant over-night thing in the best case, and > there is no urgency. > > [..] > > This proposal cannot be moved to the review phase under the current > > circumstances, if we are actually following the PDP policy. > > It can. > > > Let me summarise my objections. The proposer claims this is an > > inconsequential change to address policy that does not permit anything > > to be done that cannot already be done. That has been proven to be a > > false claim. This is a major change to address policy that will > > undermine the whole concept of the public registry that we have > > understood for the last 30 years. > > This, in particular, is *your* claim, which I'd like see either backed > or dismissed by the impact analysis - I see this as on way "proven". > > So it's very useful to move forward to "Review Phase with a full IA". > > > > Regardless of the merits of such a > > major change, we cannot allow such a change based on a few "+1" > > comments from a handful of the small group of people who dominate and > > control all policy decisions in this region. AFAIK neither the > > proposer, nor the RIPE NCC, nor the proposal supporters have made any > > attempt to reach out to other stakeholder groups who use the RIPE > > Database to inform them of this discussion, advise them of the > > potential consequences and invite them to join this discussion. > > This is not a requirement of the PDP. Proposals are announced to > the PDP-announce-Mailing list, and people interested in policy change > are expected to read this. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From ripedenis at gmail.com Tue Nov 7 23:08:09 2023 From: ripedenis at gmail.com (denis walker) Date: Tue, 7 Nov 2023 23:08:09 +0100 Subject: [address-policy-wg] 2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: Hi Leo On Tue, 7 Nov 2023 at 22:04, Leo Vegoda wrote: > > Dear Denis, > > Our processes don't move super fast. This is partly deliberate. We > don't want to railroad the community. It is also practical. There are > actions to be carried out between the end of one phase and the start > of another. > > The proposers have taken account of the "significant comments or > changes [...] suggested during the Discussion Phase." They have been > preparing a draft RIPE Document with help from the RIPE NCC. > > The RIPE NCC has been developing an impact analysis. They > understandably don't start that work until there's a decision on > whether the proposal will move forward. > > All of these things take some time to accomplish. That is why there is > a small gap between the formal end of the Discussion phase and the > start of the Review phase. > The delays are understandable. Maybe that should be clearly reflected in the PDP process. > Your objections have not been ignored. We will schedule time in Rome > to discuss the objections you have raised. I look forward to that (remotely). cheers denis > > Kind regards, > > Leo Vegoda for the co-chairs > > On Tue, 7 Nov 2023 at 04:00, denis walker wrote: > > > > Hi Leo, Colleagues > > > > I am both saddened and yet not surprised by this announcement to move > > this proposal to the review phase. It doesn't seem to matter what > > anyone says, I suspect this proposal will be approved. You included a > > link to the Policy Development Process (ripe-781). Pity you have not > > followed it. Now suggesting we follow a process, Jim Reid will argue I > > am trying to turn RIPE into some "process heavy organisation". But the > > PDP is a policy. So do we get to pick and choose which bits of which > > policies we apply or ignore? If that is the case why not just dump all > > policy and work to a general understanding. It might be more honest. > > > > Let's walk through the PDP as defined in ripe-781. Starting with '2. > > The Process'. > > > > "These phases are detailed below with proposed timelines for the > > various stages. These may differ for individual proposals, but the > > actual timelines must be documented." > > > > In the opening email Angela stated that the four week Discussion Phase > > will run until 3 October 2023. > > > > "At the end of each phase of the process, one of the chairs of the > > relevant WG will summarise the state of discussion on the WG mailing > > list." > > > > This has not been done. > > > > "In all phases of the RIPE PDP, suggestions for changes to the > > proposal and objections regarding the proposal must be justified with > > supporting arguments and then addressed adequately by the proposer or > > by any supporter of the proposal." > > > > I have objected to this proposal on several grounds. I have justified > > my objections with significant supporting arguments. A number of > > people have supported the principle of my objections. Some people who > > initially gave the proposal a "+1" response have since withdrawn that > > support based on my objections. Neither the proposers, nor their > > supporters (the +1 brigade), have addressed my objections. Even worse > > than that, the proposers still deny that this proposal changes > > anything substantially with regard to address policy. They still claim > > it does not allow anything to be done that cannot already be done. I > > have adequately shown this argument to be false. Neither the proposers > > nor their supporters have even acknowledged this fact. A number of > > people have agreed that such a fundamental change to address policy > > should not be introduced as a (hidden) side effect of another, > > apparently inconsequential, change. If such a change is to be > > introduced, which may or may not have merits of its own, it should be > > openly discussed as a separate topic. Given that these objections are > > highly significant, and that they have been completely ignored by the > > proposers and supporters and not "addressed adequately", the chairs of > > the AP-WG cannot declare an initial consensus and move this proposal > > to the review phase. > > > > In '2.2 Discussion Phase' it says: > > > > "If the proposer decides to take the proposal to the next phase, they > > need to produce a draft RIPE Document which should be published within > > four weeks after the end of the Discussion Phase, before the proposal > > can be moved to the Review Phase." > > > > This has not been done. > > > > "The RIPE NCC will need to publish an impact analysis for the proposal > > 'before' it can be moved to the Review Phase." > > > > This has not been done. > > > > I am raising these issues today as it is the last day of the > > discussion phase according to the diagram in Appendix A of ripe-781. > > Even though the diagram does not agree with the text in ripe-781. I > > have allowed the 5 weeks after the discussion phase shown in the > > diagram, rather than the 4 weeks stated in the text. > > > > This proposal cannot be moved to the review phase under the current > > circumstances, if we are actually following the PDP policy. > > > > Let me summarise my objections. The proposer claims this is an > > inconsequential change to address policy that does not permit anything > > to be done that cannot already be done. That has been proven to be a > > false claim. This is a major change to address policy that will > > undermine the whole concept of the public registry that we have > > understood for the last 30 years. Regardless of the merits of such a > > major change, we cannot allow such a change based on a few "+1" > > comments from a handful of the small group of people who dominate and > > control all policy decisions in this region. AFAIK neither the > > proposer, nor the RIPE NCC, nor the proposal supporters have made any > > attempt to reach out to other stakeholder groups who use the RIPE > > Database to inform them of this discussion, advise them of the > > potential consequences and invite them to join this discussion. > > Stakeholder groups like LEAs, government regulators, private > > investigators, abuse management organisations, security community, > > researchers, and others (who the Database Task Force never > > identified). > > > > cheers > > denis > > > > On Fri, 27 Oct 2023 at 03:51, Leo Vegoda wrote: > > > > > > Dear WG, > > > > > > The Discussion Phase of policy proposal 2023-04 "Add AGGREGATED-BY-LIR > > > status for IPv4 PA assignments" has now ended. Many thanks to all for > > > your comments. > > > > > > The proposal will now move forward to the Review Phase. > > > > > > The RIPE NCC will prepare an impact analysis and a draft RIPE Document. > > > > > > More details about the phases of the Policy Development Process are > > > published here: https://www.ripe.net/publications/docs/ripe-781 > > > > > > You'll also see an announcement from the RIPE NCC soon. > > > > > > Kind regards, > > > > > > Leo Vegoda for the co-chairs > > > > > > -- > > > > > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From leo at vegoda.org Thu Nov 9 20:57:26 2023 From: leo at vegoda.org (Leo Vegoda) Date: Thu, 9 Nov 2023 11:57:26 -0800 Subject: [address-policy-wg] Draft Address Policy WG Agenda for RIPE 87, Rome Message-ID: Hi, Here is our draft agenda for Rome. We can make refinements if needed, so please contact the chairs if you would like us to add or change something. Kind regards, Leo Session 1 starts: 09:00 A. Introduction [5 min] B. Chair Selection [10 min] C. NRO NC / ICANN ASO AC Update [10 min] Herv? Clement and/or Sander Steffann D. Registry Services Update Followed by Q&A [15 min] Marco Schmidt, RIPE NCC E. Policy Update Followed by Q&A [15 min] Angela Dall'Ara, RIPE NCC F. Discussion: What is the purpose of IPv4 assignment registration in 2024? [30 mins] [co-chairs to show 1 discussion slide] Session 1 ends: 11:00 ? Session 2 starts: 11:30 G. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins] Jeroen Lauwers, A2B Internet Tore Anderson, Redpill Linpro H. Improving IPv6 PI Policy [25 mins] Tobias Fiebig I. AOB [10 mins] Session 2 ends: 12:30 From leo at vegoda.org Mon Nov 20 16:04:32 2023 From: leo at vegoda.org (Leo Vegoda) Date: Mon, 20 Nov 2023 07:04:32 -0800 Subject: [address-policy-wg] Draft Address Policy WG Agenda for RIPE 87, Rome In-Reply-To: References: Message-ID: Hi, Here's an updated agenda. Item H has changed to a broader discussion. Kind regards, Leo Session 1 starts: 09:00 A. Introduction [5 min] B. Chair Selection [10 min] C. NRO NC / ICANN ASO AC Update [10 min] Herv? Clement and/or Sander Steffann D. Registry Services Update Followed by Q&A [15 min] Marco Schmidt, RIPE NCC E. Policy Update Followed by Q&A [15 min] Angela Dall'Ara, RIPE NCC F. Discussion: What is the purpose of IPv4 assignment registration in 2024? [30 mins] [co-chairs to show 1 discussion slide] Session 1 ends: 11:00 ? Session 2 starts: 11:30 G. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins] Jeroen Lauwers, A2B Internet Tore Anderson, Redpill Linpro H. The Future of IPv6 Policy [25 mins] Introdicuing ideas for change and setting priorities (Discussion) I. AOB [10 mins] Session 2 ends: 12:30 On Thu, 9 Nov 2023 at 11:57, Leo Vegoda wrote: > > Hi, > > Here is our draft agenda for Rome. > > We can make refinements if needed, so please contact the chairs if you > would like us to add or change something. > > Kind regards, > > Leo > > Session 1 starts: 09:00 > > A. Introduction [5 min] > > B. Chair Selection [10 min] > > C. NRO NC / ICANN ASO AC Update [10 min] > Herv? Clement and/or Sander Steffann > > D. Registry Services Update Followed by Q&A [15 min] > Marco Schmidt, RIPE NCC > > E. Policy Update Followed by Q&A [15 min] > Angela Dall'Ara, RIPE NCC > > F. Discussion: What is the purpose of IPv4 assignment registration in > 2024? [30 mins] > [co-chairs to show 1 discussion slide] > > Session 1 ends: 11:00 > > ? > > Session 2 starts: 11:30 > > G. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins] > Jeroen Lauwers, A2B Internet > Tore Anderson, Redpill Linpro > > H. Improving IPv6 PI Policy [25 mins] > Tobias Fiebig > > I. AOB [10 mins] > > Session 2 ends: 12:30 From adallara at ripe.net Tue Nov 21 11:13:57 2023 From: adallara at ripe.net (Angela Dall'Ara) Date: Tue, 21 Nov 2023 11:13:57 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Message-ID: Dear colleagues, Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA assignments?, is now in the Review Phase. The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. This proposal has been updated and it is now at version 2.0. The proposed policy text did not change, the only difference is that the section "Arguments opposing the proposal" includes a reference to the last round of discussion. The RIPE NCC has prepared an impact analysis on this proposal to support the community?s discussion. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2023-04 https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis And the draft document at: https://www.ripe.net/participate/policies/proposals/2023-04/draft As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue the discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg at ripe.net before 20 December 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC From bogus@does.not.exist.com Thu Nov 23 03:04:18 2023 From: bogus@does.not.exist.com () Date: Thu, 23 Nov 2023 02:04:18 +0000 Subject: [address-policy-wg] [Moderated] Message-ID: [This message was removed from the archive because it was considered to be spam] From ripedenis at gmail.com Thu Nov 23 07:17:39 2023 From: ripedenis at gmail.com (denis walker) Date: Thu, 23 Nov 2023 07:17:39 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: Colleagues I am so disappointed by this second version of the proposal and the impact analysis. Let's start with the changes to the proposal. The addition of 'Arguments opposing the proposal'. This is completely false and misleading information. This summary of the arguments during the discussion phase is just unbelievably wrong. No one even made the argument that you cannot currently create an object with the mandatory contacts delegated to another party. In regard to these mandatory contacts I proved that the admin-c must be a contact from the End User's enterprise. This is based on the definition of admin-c and the clearly expressed, current version of the address policy. In particular that well quoted line "When an End User has a network using public address space this must be registered separately with the contact details of the End User." Very clear, not subject to interpretation and non negotiable under the current policy and all versions of the policy going back over the last 20 years. In the PDP policy it says "At the end of each phase of the process, one of the chairs of the relevant WG will summarise the state of discussion on the WG mailing list." This still has not been done. Then we have this crazy 'counter argument'. Let's break it down. "It is already possible to create such assignments under the current address policy." No one has disputed that. "The RIPE NCC confirmed that they consider these assignments to be policy compliant and do not require them to be modified during audits." During my detailed arguments I proved that this interpretation by the RIPE NCC of the current IPv4 address policy, and all the versions over the last 20 years, is incorrect. According to the now famous line "When an End User has a network using public address space this must be registered separately with the contact details of the End User." and the historic, but still valid, definition of the admin-c, it is clear that the admin-c must be someone from the End User enterprise. Therefore delegating this to another party is a violation of the policy. Many LIRs who create assignment objects in the RIPE Database have understood the current and previous address policy. Even though they sometimes delegate the admin-c they compensate by adding the name and address of the End User in the optional descr attributes. This is not strictly compliant but does adhere to the principle of the policy. This proposal drops this principle. Despite the RIPE Chairs and RIPE NCC CEO's recent policy about RIPE NCC staff being more involved in RIPE community affairs, no one from the RIPE NCC has joined this discussion to explain the NCC's interpretation of the current and previous address policy. "Therefore, the proposed policy change simply leaves the status quo unchanged." This is straight out of the Donald Trump fake news instruction manual. When you say something that is not true, keep repeating it, over and over and over again. Never acknowledge anyone who questions it, never discuss any arguments raised against it, just keep repeating it. Over time some people will start to believe it. I have argued in GREAT detail exactly what this proposal does. By dropping that famous line "When an End User has a network using public address space this must be registered separately with the contact details of the End User." the proposers fundamentally change address policy and the nature of the public registry. I have presented 'walls of text' to explain this, which most people probably have not read. This change allows ALL End Users to be totally anonymised. Even those who technically manage their own network and handle their own abuse complaints, they can still be anonymised and have public contact details available. For LIRs who do not want to put any details of their customers into the public registry, this change allows for this complete anonymity. And there are many LIRs who already follow this philosophy, despite current policy. This change will reduce the RIPE Database public number registry to the same useless level as a domain name registry. ALL details of End Users can be hidden behind a court order firewall. Following the Trump instruction manual, the proposers still refuse to acknowledge that this proposal changes anything. They still refuse to engage with the community in a real discussion on this point. They still keep repeating the fake news. It also says in the PDP policy "In all phases of the RIPE PDP, suggestions for changes to the proposal and objections regarding the proposal must be justified with supporting arguments and then addressed adequately by the proposer or by any supporter of the proposal." The proposers will not even acknowledge my objections, will not discuss them and therefore have not adequately addressed them. Then we move on to the impact analysis (IA). This reads as an 'Impact on the RIPE NCC Analysis'. There is no mention at all of the impact on stakeholders who use the data contained within the RIPE Database. In the PDP policy it does say the IA will contain 'Impact on the registry'. This is interpretable. I would suggest this covers the public registry as well as the RIPE NCC's internal registry databases. But this IA does not even mention the fundamental change to address policy and the potential consequences to the data contained within the public registry or the impact that may have on various stakeholder groups using the RIPE Database. It follows the same line as the proposers by failing to even acknowledge the severity of the change this proposal has on the public registry. >From the Legal Impact section, "the RIPE NCC would like to note that it is solely the responsibility of the member to choose which contact details to insert in the INETNUM object." Also from the 'RIPE NCC's Understanding' it says "Acceptance of this proposal will not change the fact that the RIPE NCC cannot enforce which contact details members add to their IPv4 PA assignments in the RIPE Database; this will remain their decision." This is also not true. The policy is very clear. "When an End User has a network using public address space this must be registered separately with the contact details of the End User." So the current policy dictates to the LIR the type of the contact details they must enter. Even though the individual contact within that type is their choice. So with the arguments from the discussion phase having not been summarised and the objections not having even been acknowledged by the proposers, and certainly not addressed by them, I still don't see how this proposal can move to the review phase. cheers denis On Tue, 21 Nov 2023 at 11:13, Angela Dall'Ara wrote: > > > Dear colleagues, > > Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA > assignments?, is now in the Review Phase. > > The goal of this proposal is to introduce the AGGREGATED-BY-LIR status > for IPv4 PA assignments to reduce LIR efforts in registration and > maintenance. > > This proposal has been updated and it is now at version 2.0. The > proposed policy text did not change, the only difference is that the > section "Arguments opposing the proposal" includes a reference to the > last round of discussion. > > The RIPE NCC has prepared an impact analysis on this proposal to support > the community?s discussion. > > You can find the proposal and impact analysis at: > https://www.ripe.net/participate/policies/proposals/2023-04 > https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > And the draft document at: > https://www.ripe.net/participate/policies/proposals/2023-04/draft > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Review Phase is to continue the discussion of the proposal > taking the impact analysis into consideration, and to review the full > draft RIPE Policy Document. > > At the end of the Review Phase, the Working Group (WG) Chairs will > determine whether the WG has reached rough consensus. > It is therefore important to provide your opinion, even if it is simply > a restatement of your input from the previous phase. > > We encourage you to read the proposal, impact analysis and draft > document and to send any comments to address-policy-wg at ripe.net before > 20 December 2023. > > Kind regards, > Angela Dall'Ara > Policy Officer > RIPE NCC > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From adallara at ripe.net Thu Nov 23 18:06:51 2023 From: adallara at ripe.net (Angela Dall'Ara) Date: Thu, 23 Nov 2023 18:06:51 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: <3796b1cc-6992-4d2a-85cf-620b5cbefb8a@ripe.net> Dear Denis, If the proposal 2023-04 is accepted, this would not cause any change in the way we conduct our audits and evaluate the registration of PA assignments. In IPv4, the mandatory contact information for PA assignments is provided by the ?admin-c:? and ?tech-c:? attributes; these must allow the RIPE NCC and other RIPE Database users to contact the End User regarding technical or administrative issues. The contacts are registered by the LIR as agreed with the End User. As LIRs are free to choose how to provide services and to who, this includes their freedom to take over the responsibility as the point of contact for their End User as well as having their maintainer in the IPv4 PA assignments they register. This is in line with the Database Term and Conditions statement in ?Article 6 - Responsibilities?: ?The Maintainer is responsible for keeping all data maintained by them accurate and up-to-date, including correct Contact Details. The data must be good enough to allow the RIPE NCC to contact the Maintainer or Registrant within a reasonable time without having to get information from another source.? Following the discussion in the Database WG the ?descr:? attribute became optional for all object types in 2016. Since then, the RIPE NCC stopped enforcing the registration of the End User?s organisation name. LIRs still have the option to add this information in the ?descr: attribute, by adding it to the ?remarks:? attribute or in the ?org:? attribute (provided they created an organisation object). This is reflected in the tutorial and training currently provided by the RIPE NCC: https://www.youtube.com/watch?v=w6oUf7j4SME. PA assignments are not maintained by the RIPE NCC. They are very dynamic elements of the resource registration in the RIPE Database, and we do not receive any notification about their creation, updates and deletions. Additionally, the RIPE NCC is not in the position to confirm that the "admin-c:" contact is registered following the guidelines of the RIPE Database documentation (which is not a RIPE policy) where it is written that the ?admin-c:? ?must be physically located at the site of the network? or ?must be the contact details of an on-site administrative contact?. I see that this topic is in the agenda of the APWG session at RIPE 87 and I?m looking forward to follow this interesting discussion. Kind regards, Angela Angela Dall'Ara Policy Officer RIPE NCC On 23/11/2023 07:17, denis walker wrote: > Colleagues > > I am so disappointed by this second version of the proposal and the > impact analysis. > > Let's start with the changes to the proposal. The addition of > 'Arguments opposing the proposal'. This is completely false and > misleading information. This summary of the arguments during the > discussion phase is just unbelievably wrong. No one even made the > argument that you cannot currently create an object with the mandatory > contacts delegated to another party. In regard to these mandatory > contacts I proved that the admin-c must be a contact from the End > User's enterprise. This is based on the definition of admin-c and the > clearly expressed, current version of the address policy. In > particular that well quoted line "When an End User has a network using > public address space this must be registered separately with the > contact details of the End User." Very clear, not subject to > interpretation and non negotiable under the current policy and all > versions of the policy going back over the last 20 years. > > In the PDP policy it says "At the end of each phase of the process, > one of the chairs of the relevant WG will summarise the state of > discussion on the WG mailing list." This still has not been done. > > Then we have this crazy 'counter argument'. Let's break it down. > > "It is already possible to create such assignments under the current > address policy." > No one has disputed that. > > "The RIPE NCC confirmed that they consider these assignments to be > policy compliant and do not require them to be modified during > audits." > During my detailed arguments I proved that this interpretation by the > RIPE NCC of the current IPv4 address policy, and all the versions over > the last 20 years, is incorrect. According to the now famous line > "When an End User has a network using public address space this must > be registered separately with the contact details of the End User." > and the historic, but still valid, definition of the admin-c, it is > clear that the admin-c must be someone from the End User enterprise. > Therefore delegating this to another party is a violation of the > policy. Many LIRs who create assignment objects in the RIPE Database > have understood the current and previous address policy. Even though > they sometimes delegate the admin-c they compensate by adding the name > and address of the End User in the optional descr attributes. This is > not strictly compliant but does adhere to the principle of the policy. > This proposal drops this principle. > > Despite the RIPE Chairs and RIPE NCC CEO's recent policy about RIPE > NCC staff being more involved in RIPE community affairs, no one from > the RIPE NCC has joined this discussion to explain the NCC's > interpretation of the current and previous address policy. > > "Therefore, the proposed policy change simply leaves the status quo unchanged." > This is straight out of the Donald Trump fake news instruction manual. > When you say something that is not true, keep repeating it, over and > over and over again. Never acknowledge anyone who questions it, never > discuss any arguments raised against it, just keep repeating it. Over > time some people will start to believe it. > > I have argued in GREAT detail exactly what this proposal does. By > dropping that famous line "When an End User has a network using public > address space this must be registered separately with the contact > details of the End User." the proposers fundamentally change address > policy and the nature of the public registry. I have presented 'walls > of text' to explain this, which most people probably have not read. > This change allows ALL End Users to be totally anonymised. Even those > who technically manage their own network and handle their own abuse > complaints, they can still be anonymised and have public contact > details available. For LIRs who do not want to put any details of > their customers into the public registry, this change allows for this > complete anonymity. And there are many LIRs who already follow this > philosophy, despite current policy. This change will reduce the RIPE > Database public number registry to the same useless level as a domain > name registry. ALL details of End Users can be hidden behind a court > order firewall. > > Following the Trump instruction manual, the proposers still refuse to > acknowledge that this proposal changes anything. They still refuse to > engage with the community in a real discussion on this point. They > still keep repeating the fake news. > > It also says in the PDP policy "In all phases of the RIPE PDP, > suggestions for changes to the proposal and objections regarding the > proposal must be justified with supporting arguments and then > addressed adequately by the proposer or by any supporter of the > proposal." The proposers will not even acknowledge my objections, will > not discuss them and therefore have not adequately addressed them. > > Then we move on to the impact analysis (IA). This reads as an 'Impact > on the RIPE NCC Analysis'. There is no mention at all of the impact on > stakeholders who use the data contained within the RIPE Database. In > the PDP policy it does say the IA will contain 'Impact on the > registry'. This is interpretable. I would suggest this covers the > public registry as well as the RIPE NCC's internal registry databases. > But this IA does not even mention the fundamental change to address > policy and the potential consequences to the data contained within the > public registry or the impact that may have on various stakeholder > groups using the RIPE Database. It follows the same line as the > proposers by failing to even acknowledge the severity of the change > this proposal has on the public registry. > > From the Legal Impact section, "the RIPE NCC would like to note that > it is solely the responsibility of the member to choose which contact > details to insert in the INETNUM object." Also from the 'RIPE NCC's > Understanding' it says "Acceptance of this proposal will not change > the fact that the RIPE NCC cannot enforce which contact details > members add to their IPv4 PA assignments in the RIPE Database; this > will remain their decision." This is also not true. The policy is very > clear. "When an End User has a network using public address space this > must be registered separately with the contact details of the End > User." So the current policy dictates to the LIR the type of the > contact details they must enter. Even though the individual contact > within that type is their choice. > > So with the arguments from the discussion phase having not been > summarised and the objections not having even been acknowledged by the > proposers, and certainly not addressed by them, I still don't see how > this proposal can move to the review phase. > > cheers > denis > > On Tue, 21 Nov 2023 at 11:13, Angela Dall'Ara wrote: >> >> Dear colleagues, >> >> Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA >> assignments?, is now in the Review Phase. >> >> The goal of this proposal is to introduce the AGGREGATED-BY-LIR status >> for IPv4 PA assignments to reduce LIR efforts in registration and >> maintenance. >> >> This proposal has been updated and it is now at version 2.0. The >> proposed policy text did not change, the only difference is that the >> section "Arguments opposing the proposal" includes a reference to the >> last round of discussion. >> >> The RIPE NCC has prepared an impact analysis on this proposal to support >> the community?s discussion. >> >> You can find the proposal and impact analysis at: >> https://www.ripe.net/participate/policies/proposals/2023-04 >> https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis >> And the draft document at: >> https://www.ripe.net/participate/policies/proposals/2023-04/draft >> >> As per the RIPE Policy Development Process (PDP), the purpose of this >> four-week Review Phase is to continue the discussion of the proposal >> taking the impact analysis into consideration, and to review the full >> draft RIPE Policy Document. >> >> At the end of the Review Phase, the Working Group (WG) Chairs will >> determine whether the WG has reached rough consensus. >> It is therefore important to provide your opinion, even if it is simply >> a restatement of your input from the previous phase. >> >> We encourage you to read the proposal, impact analysis and draft >> document and to send any comments to address-policy-wg at ripe.net before >> 20 December 2023. >> >> Kind regards, >> Angela Dall'Ara >> Policy Officer >> RIPE NCC >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From salenamartine360 at gmail.com Fri Nov 24 13:27:54 2023 From: salenamartine360 at gmail.com (Salena) Date: Fri, 24 Nov 2023 17:57:54 +0530 Subject: [address-policy-wg] TESTING360 In-Reply-To: References: Message-ID: TESTING360 On Fri, Nov 24, 2023 at 5:48?PM Salena wrote: > TESTING360 > TESTING360TESTING360TESTING360TESTING360TESTING360TESTING360TESTING360TESTING360TESTING360TESTING360 > TESTING360 > https://mail.google.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From salenamartine360 at gmail.com Fri Nov 24 13:29:17 2023 From: salenamartine360 at gmail.com (Salena) Date: Fri, 24 Nov 2023 17:59:17 +0530 Subject: [address-policy-wg] pinkpanther360 Message-ID: pinkpanther360 pinkpanther360 https://mail.google.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From agollan at ripe.net Fri Nov 24 14:28:34 2023 From: agollan at ripe.net (Antony Gollan) Date: Fri, 24 Nov 2023 14:28:34 +0100 Subject: [address-policy-wg] =?utf-8?q?New_on_RIPE_Labs=3A_Who=E2=80=99s_?= =?utf-8?q?Waiting_on_the_IPv4_Waiting_List=3F?= Message-ID: <0349e653-893e-4ced-bbb5-4be2ea64776e@ripe.net> Dear colleagues, Four years after our IPv4 waiting list became active, and with more than a thousand LIRs in the queue for an allocation, how successful has the list been at providing at least a minimal amount of IPv4 space to newcomers? We take a closer look at some of the numbers in this article on RIPE Labs: https://labs.ripe.net/author/antony_gollan/whos-waiting-on-the-ipv4-waiting-list/ Regards Antony Gollan Communications Team Manager RIPE NCC From ripedenis at gmail.com Mon Nov 27 08:31:10 2023 From: ripedenis at gmail.com (denis walker) Date: Mon, 27 Nov 2023 08:31:10 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: <3796b1cc-6992-4d2a-85cf-620b5cbefb8a@ripe.net> References: <3796b1cc-6992-4d2a-85cf-620b5cbefb8a@ripe.net> Message-ID: Hi Angela Thanks for your response. Some of your comments are valid as individual points, some less so. But putting these comments together does not create a complete story to support this proposal. As always I will go through them below one point at a time. On Thu, 23 Nov 2023 at 18:06, Angela Dall'Ara wrote: > > Dear Denis, > > If the proposal 2023-04 is accepted, this would not cause any change in > the way we conduct our audits and evaluate the registration of PA > assignments. If the RIPE NCC has misinterpreted current address policy and the way assignment information is currently evaluated is not correct, then not changing anything is not an improvement. > > In IPv4, the mandatory contact information for PA assignments is > provided by the ?admin-c:? and ?tech-c:? attributes; these must allow > the RIPE NCC and other RIPE Database users to contact the End User > regarding technical or administrative issues. And the "admin-c:" was defined in the early days of the registry to be someone from the End Users enterprise. As far as I can see there has never been any discussion or consensus on changing that definition. > The contacts are > registered by the LIR as agreed with the End User. ...and must be in accordance with RIPE policy which says the assignment must contain the End User's contact details. > > As LIRs are free to choose how to provide services and to who, this > includes their freedom to take over the responsibility as the point of > contact for their End User The LIR does have the freedom to offer themselves as a point of contact for their End User. BUT the policy is still clear, the assignment MUST contain the contact details of the End User. > as well as having their maintainer in the > IPv4 PA assignments they register. It is normal practice for ALL pa assignment objects to have only the LIR's mntner on them. This is a matter of managing the data set in the database rather than related to responsibilities implied by that data. > This is in line with the Database Term and Conditions statement in > ?Article 6 - Responsibilities?: > ?The Maintainer is responsible for keeping all data maintained by them > accurate and up-to-date, including correct Contact Details. The data > must be good enough to allow the RIPE NCC to contact the Maintainer or > Registrant within a reasonable time without having to get information > from another source.? I wrote the T&C so I know exactly what I had in mind when I wrote each article. I also know what I did not take into account because, at the time, I wasn't aware of it. There are mistakes in the T&C, which I accept responsibility for. But I have stopped criticising documents as I get personally attacked for doing so. Probably also for documents that I wrote. I am not allowed to even criticise my own mistakes. This is one of those paragraphs that is completely wrong, for several reasons. But that is for another day...a day that will never come as no one cares about mistakes in documents...even though there are so many of them. But as for this issue it is irrelevant. Even as written, it is concerned about maintaining the data set in the database, not what that data means. > > Following the discussion in the Database WG the ?descr:? attribute > became optional for all object types in 2016. Since then, the RIPE NCC > stopped enforcing the registration of the End User?s organisation name. > LIRs still have the option to add this information in the ?descr: > attribute, by adding it to the ?remarks:? attribute or in the ?org:? > attribute (provided they created an organisation object). > This is reflected in the tutorial and training currently provided by the > RIPE NCC: https://www.youtube.com/watch?v=w6oUf7j4SME. OK this is a bit confused. First of all the RIPE NCC never enforced the End User?s organisation name in the mandatory "descr:" attributes. This was only for allocations and PI assignments. LIRs still have the option to add this data for End Users in the now optional descr attributes, and many still do so in order to comply with current policy. (btw the video is wrong. It implies that an assignment object is created by webupdates, which only a very small LIR is likely to do...but that is another story) > > PA assignments are not maintained by the RIPE NCC. They are very dynamic > elements of the resource registration in the RIPE Database, and we do > not receive any notification about their creation, updates and deletions. A lot of assignments have not changed in the last 10 or 20 years. Some of the assignment data is very static. There are some more recent network arrangements, like cloud systems, where they have become very dynamic. > Additionally, the RIPE NCC is not in the position to confirm that the > "admin-c:" contact is registered following the guidelines of the RIPE > Database documentation (which is not a RIPE policy) where it is written > that the ?admin-c:? ?must be physically located at the site of the > network? or ?must be the contact details of an on-site administrative > contact?. The database documentation is based on other documents. The current address policy clearly states that assignments MUST be registered with the End User's contact details. Also many documents refer to the "admin-c:" attribute. The first definition that seems to exist of the 'admin-c' is in ripe-136 that defines it as someone who "must be physically located at the site of the network". Then ripe-140 clarified it in the context of an aut-num as someone who "should be physically located at the enterprise requesting the AS number.". Then ripe-159 added to the definition of admin-c that "The person does not have to have technical knowledge of the network." This definition of admin-c has never been discussed since or changed by any community consensus. > > I see that this topic is in the agenda of the APWG session at RIPE 87 > and I?m looking forward to follow this interesting discussion. So am I :) cheers denis > > Kind regards, > Angela > > Angela Dall'Ara > Policy Officer > RIPE NCC > > > On 23/11/2023 07:17, denis walker wrote: > > Colleagues > > > > I am so disappointed by this second version of the proposal and the > > impact analysis. > > > > Let's start with the changes to the proposal. The addition of > > 'Arguments opposing the proposal'. This is completely false and > > misleading information. This summary of the arguments during the > > discussion phase is just unbelievably wrong. No one even made the > > argument that you cannot currently create an object with the mandatory > > contacts delegated to another party. In regard to these mandatory > > contacts I proved that the admin-c must be a contact from the End > > User's enterprise. This is based on the definition of admin-c and the > > clearly expressed, current version of the address policy. In > > particular that well quoted line "When an End User has a network using > > public address space this must be registered separately with the > > contact details of the End User." Very clear, not subject to > > interpretation and non negotiable under the current policy and all > > versions of the policy going back over the last 20 years. > > > > In the PDP policy it says "At the end of each phase of the process, > > one of the chairs of the relevant WG will summarise the state of > > discussion on the WG mailing list." This still has not been done. > > > > Then we have this crazy 'counter argument'. Let's break it down. > > > > "It is already possible to create such assignments under the current > > address policy." > > No one has disputed that. > > > > "The RIPE NCC confirmed that they consider these assignments to be > > policy compliant and do not require them to be modified during > > audits." > > During my detailed arguments I proved that this interpretation by the > > RIPE NCC of the current IPv4 address policy, and all the versions over > > the last 20 years, is incorrect. According to the now famous line > > "When an End User has a network using public address space this must > > be registered separately with the contact details of the End User." > > and the historic, but still valid, definition of the admin-c, it is > > clear that the admin-c must be someone from the End User enterprise. > > Therefore delegating this to another party is a violation of the > > policy. Many LIRs who create assignment objects in the RIPE Database > > have understood the current and previous address policy. Even though > > they sometimes delegate the admin-c they compensate by adding the name > > and address of the End User in the optional descr attributes. This is > > not strictly compliant but does adhere to the principle of the policy. > > This proposal drops this principle. > > > > Despite the RIPE Chairs and RIPE NCC CEO's recent policy about RIPE > > NCC staff being more involved in RIPE community affairs, no one from > > the RIPE NCC has joined this discussion to explain the NCC's > > interpretation of the current and previous address policy. > > > > "Therefore, the proposed policy change simply leaves the status quo unchanged." > > This is straight out of the Donald Trump fake news instruction manual. > > When you say something that is not true, keep repeating it, over and > > over and over again. Never acknowledge anyone who questions it, never > > discuss any arguments raised against it, just keep repeating it. Over > > time some people will start to believe it. > > > > I have argued in GREAT detail exactly what this proposal does. By > > dropping that famous line "When an End User has a network using public > > address space this must be registered separately with the contact > > details of the End User." the proposers fundamentally change address > > policy and the nature of the public registry. I have presented 'walls > > of text' to explain this, which most people probably have not read. > > This change allows ALL End Users to be totally anonymised. Even those > > who technically manage their own network and handle their own abuse > > complaints, they can still be anonymised and have public contact > > details available. For LIRs who do not want to put any details of > > their customers into the public registry, this change allows for this > > complete anonymity. And there are many LIRs who already follow this > > philosophy, despite current policy. This change will reduce the RIPE > > Database public number registry to the same useless level as a domain > > name registry. ALL details of End Users can be hidden behind a court > > order firewall. > > > > Following the Trump instruction manual, the proposers still refuse to > > acknowledge that this proposal changes anything. They still refuse to > > engage with the community in a real discussion on this point. They > > still keep repeating the fake news. > > > > It also says in the PDP policy "In all phases of the RIPE PDP, > > suggestions for changes to the proposal and objections regarding the > > proposal must be justified with supporting arguments and then > > addressed adequately by the proposer or by any supporter of the > > proposal." The proposers will not even acknowledge my objections, will > > not discuss them and therefore have not adequately addressed them. > > > > Then we move on to the impact analysis (IA). This reads as an 'Impact > > on the RIPE NCC Analysis'. There is no mention at all of the impact on > > stakeholders who use the data contained within the RIPE Database. In > > the PDP policy it does say the IA will contain 'Impact on the > > registry'. This is interpretable. I would suggest this covers the > > public registry as well as the RIPE NCC's internal registry databases. > > But this IA does not even mention the fundamental change to address > > policy and the potential consequences to the data contained within the > > public registry or the impact that may have on various stakeholder > > groups using the RIPE Database. It follows the same line as the > > proposers by failing to even acknowledge the severity of the change > > this proposal has on the public registry. > > > > From the Legal Impact section, "the RIPE NCC would like to note that > > it is solely the responsibility of the member to choose which contact > > details to insert in the INETNUM object." Also from the 'RIPE NCC's > > Understanding' it says "Acceptance of this proposal will not change > > the fact that the RIPE NCC cannot enforce which contact details > > members add to their IPv4 PA assignments in the RIPE Database; this > > will remain their decision." This is also not true. The policy is very > > clear. "When an End User has a network using public address space this > > must be registered separately with the contact details of the End > > User." So the current policy dictates to the LIR the type of the > > contact details they must enter. Even though the individual contact > > within that type is their choice. > > > > So with the arguments from the discussion phase having not been > > summarised and the objections not having even been acknowledged by the > > proposers, and certainly not addressed by them, I still don't see how > > this proposal can move to the review phase. > > > > cheers > > denis > > > > On Tue, 21 Nov 2023 at 11:13, Angela Dall'Ara wrote: > >> > >> Dear colleagues, > >> > >> Policy proposal 2023-04, ?Add AGGREGATED-BY-LIR status for IPv4 PA > >> assignments?, is now in the Review Phase. > >> > >> The goal of this proposal is to introduce the AGGREGATED-BY-LIR status > >> for IPv4 PA assignments to reduce LIR efforts in registration and > >> maintenance. > >> > >> This proposal has been updated and it is now at version 2.0. The > >> proposed policy text did not change, the only difference is that the > >> section "Arguments opposing the proposal" includes a reference to the > >> last round of discussion. > >> > >> The RIPE NCC has prepared an impact analysis on this proposal to support > >> the community?s discussion. > >> > >> You can find the proposal and impact analysis at: > >> https://www.ripe.net/participate/policies/proposals/2023-04 > >> https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis > >> And the draft document at: > >> https://www.ripe.net/participate/policies/proposals/2023-04/draft > >> > >> As per the RIPE Policy Development Process (PDP), the purpose of this > >> four-week Review Phase is to continue the discussion of the proposal > >> taking the impact analysis into consideration, and to review the full > >> draft RIPE Policy Document. > >> > >> At the end of the Review Phase, the Working Group (WG) Chairs will > >> determine whether the WG has reached rough consensus. > >> It is therefore important to provide your opinion, even if it is simply > >> a restatement of your input from the previous phase. > >> > >> We encourage you to read the proposal, impact analysis and draft > >> document and to send any comments to address-policy-wg at ripe.net before > >> 20 December 2023. > >> > >> Kind regards, > >> Angela Dall'Ara > >> Policy Officer > >> RIPE NCC > >> > >> -- > >> > >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ > From erik at bais.name Tue Nov 28 15:23:30 2023 From: erik at bais.name (Erik Bais) Date: Tue, 28 Nov 2023 14:23:30 +0000 Subject: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down In-Reply-To: References: Message-ID: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> Dear WG, We have informed you in September about the fact that James Kennedy is moving into a new role at the RIPE NCC We have found a willing participant from the community to help us fill the gap and join the AP-WG Chair collective. We like to introduce Alex le Heux as a new Co-Chair introduce for the following period, so he can see what is involved in the role as a Co-chair. This would mean that he will be joining Leo and myself on the AP-WG-Chair mail address and we can do the actual appointment / selection on the next RIPE meeting. I write to you on the ML, to ask you for your support and feedback on the approach. Also if you are considering joining, do have a chat with either Leo or myself during the meeting. Kind regards, Erik Bais On behalf of the AP-WG-Chairs ?On 18/09/2023, 15:25, "address-policy-wg on behalf of Leo Vegoda" on behalf of leo at vegoda.org > wrote: Dear WG, You will have seen the recent announcement that James Kennedy has joined the RIPE NCC as Chief Registry Officer. He's stepping down from his community leadership roles, including as co-chair of the Address Policy WG. Because we still have two co-chairs there is no immediate need to recruit a replacement. Instead, we'd like to encourage anyone considering joining the team to contact us to discuss what is involved. You can write to us and we can schedule a call. You can also approach us at RIPE 87 in Rome. Kind regards, Leo & Erik Address Policy WG Co-Chairs -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From nick at foobar.org Tue Nov 28 16:04:59 2023 From: nick at foobar.org (Nick Hilliard) Date: Tue, 28 Nov 2023 16:04:59 +0100 Subject: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down In-Reply-To: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> References: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> Message-ID: <00007d0a-ae75-92c4-4d49-c5a0d1af4b84@foobar.org> Erik Bais wrote on 28/11/2023 15:23: > I write to you on the ML, to ask you for your support and feedback on the approach. sounds like a good candidate - thanks to Alex for volunteering! Nick From leo at vegoda.org Tue Nov 28 16:11:12 2023 From: leo at vegoda.org (Leo Vegoda) Date: Tue, 28 Nov 2023 16:11:12 +0100 Subject: [address-policy-wg] Draft Address Policy WG Agenda for RIPE 87, Rome In-Reply-To: References: Message-ID: Hi, We have updated the agenda again. We have a new item G: Our Policy Development Process ? the implementation Kind regards, Leo Session 1 starts: 09:00 A. Introduction [5 min] B. Chair Selection [10 min] C. NRO NC / ICANN ASO AC Update [10 min] Herv? Clement and/or Sander Steffann D. Registry Services Update Followed by Q&A [15 min] Marco Schmidt, RIPE NCC E. Policy Update Followed by Q&A [15 min] Angela Dall'Ara, RIPE NCC F. Discussion: What is the purpose of IPv4 assignment registration in 2024? [30 mins] [co-chairs to show 1 discussion slide] Session 1 ends: 11:00 ? Session 2 starts: 11:30 G. Our Policy Development Process ? the implementation H. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins] Jeroen Lauwers, A2B Internet Tore Anderson, Redpill Linpro I. The Future of IPv6 Policy [25 mins] Introdicuing ideas for change and setting priorities (Discussion) On Mon, 20 Nov 2023 at 16:04, Leo Vegoda wrote: > > Hi, > > Here's an updated agenda. Item H has changed to a broader discussion. > > Kind regards, > > Leo > > Session 1 starts: 09:00 > > A. Introduction [5 min] > > B. Chair Selection [10 min] > > C. NRO NC / ICANN ASO AC Update [10 min] > Herv? Clement and/or Sander Steffann > > D. Registry Services Update Followed by Q&A [15 min] > Marco Schmidt, RIPE NCC > > E. Policy Update Followed by Q&A [15 min] > Angela Dall'Ara, RIPE NCC > > F. Discussion: What is the purpose of IPv4 assignment registration in > 2024? [30 mins] > [co-chairs to show 1 discussion slide] > > Session 1 ends: 11:00 > > ? > > Session 2 starts: 11:30 > > G. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins] > Jeroen Lauwers, A2B Internet > Tore Anderson, Redpill Linpro > > H. The Future of IPv6 Policy [25 mins] > Introdicuing ideas for change and setting priorities > (Discussion) > > I. AOB [10 mins] > > Session 2 ends: 12:30 > > On Thu, 9 Nov 2023 at 11:57, Leo Vegoda wrote: > > > > Hi, > > > > Here is our draft agenda for Rome. > > > > We can make refinements if needed, so please contact the chairs if you > > would like us to add or change something. > > > > Kind regards, > > > > Leo > > > > Session 1 starts: 09:00 > > > > A. Introduction [5 min] > > > > B. Chair Selection [10 min] > > > > C. NRO NC / ICANN ASO AC Update [10 min] > > Herv? Clement and/or Sander Steffann > > > > D. Registry Services Update Followed by Q&A [15 min] > > Marco Schmidt, RIPE NCC > > > > E. Policy Update Followed by Q&A [15 min] > > Angela Dall'Ara, RIPE NCC > > > > F. Discussion: What is the purpose of IPv4 assignment registration in > > 2024? [30 mins] > > [co-chairs to show 1 discussion slide] > > > > Session 1 ends: 11:00 > > > > ? > > > > Session 2 starts: 11:30 > > > > G. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins] > > Jeroen Lauwers, A2B Internet > > Tore Anderson, Redpill Linpro > > > > H. Improving IPv6 PI Policy [25 mins] > > Tobias Fiebig > > > > I. AOB [10 mins] > > > > Session 2 ends: 12:30 From gert at space.net Tue Nov 28 16:23:32 2023 From: gert at space.net (Gert Doering) Date: Tue, 28 Nov 2023 16:23:32 +0100 Subject: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down In-Reply-To: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> References: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> Message-ID: Hi, On Tue, Nov 28, 2023 at 02:23:30PM +0000, Erik Bais wrote: > We like to introduce Alex le Heux as a new Co-Chair introduce for > the following period, so he can see what is involved in the role > as a Co-chair. Support! (Wrote longer paragraph on "lots of experience, good understanding of the working of the NCC/PDO side of things, well-known in the community, ..." and decided a single word is sufficient :-) ) Gert Doering -- speaking as myself -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From sander at steffann.nl Tue Nov 28 16:41:52 2023 From: sander at steffann.nl (Sander Steffann) Date: Tue, 28 Nov 2023 16:41:52 +0100 Subject: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down In-Reply-To: References: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> Message-ID: <46EEF133-0515-4942-B876-8572ACA5475D@steffann.nl> Hi! > On Tue, Nov 28, 2023 at 02:23:30PM +0000, Erik Bais wrote: >> We like to introduce Alex le Heux as a new Co-Chair introduce for >> the following period, so he can see what is involved in the role >> as a Co-chair. > > Support! > > (Wrote longer paragraph on "lots of experience, good understanding of > the working of the NCC/PDO side of things, well-known in the community, > ..." and decided a single word is sufficient :-) ) What Gert said :) Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Nov 28 16:44:27 2023 From: randy at psg.com (Randy Bush) Date: Tue, 28 Nov 2023 16:44:27 +0100 Subject: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down In-Reply-To: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> References: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> Message-ID: > We have informed you in September about the fact that James Kennedy is > moving into a new role at the RIPE NCC > > We have found a willing participant from the community to help us fill > the gap and join the AP-WG Chair collective. between those two, was there a call for volunteers? > Because we still have two co-chairs there is no immediate need to > recruit a replacement. Instead, we'd like to encourage anyone > considering joining the team to contact us to discuss what is > involved. that looks more like "we do not seek volunteers," and a strong singal discouraging new blood. fwiw, i an a long term alex fan. but i have enough german ancestry to be over fond of process. we really need to be careful of unintentional gatekeeping. randy From herve.clement at orange.com Tue Nov 28 16:45:02 2023 From: herve.clement at orange.com (herve.clement at orange.com) Date: Tue, 28 Nov 2023 15:45:02 +0000 Subject: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down In-Reply-To: <46EEF133-0515-4942-B876-8572ACA5475D@steffann.nl> References: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> <46EEF133-0515-4942-B876-8572ACA5475D@steffann.nl> Message-ID: +1 Herv? De : address-policy-wg De la part de Sander Steffann Envoy? : mardi 28 novembre 2023 16:42 ? : RIPE Address Policy Working Group Cc : Gert D?ring Objet : Re: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down Hi! On Tue, Nov 28, 2023 at 02:23:30PM +0000, Erik Bais wrote: We like to introduce Alex le Heux as a new Co-Chair introduce for the following period, so he can see what is involved in the role as a Co-chair. Support! (Wrote longer paragraph on "lots of experience, good understanding of the working of the NCC/PDO side of things, well-known in the community, ..." and decided a single word is sufficient :-) ) What Gert said :) Sander ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at vegoda.org Tue Nov 28 17:15:13 2023 From: leo at vegoda.org (Leo Vegoda) Date: Tue, 28 Nov 2023 17:15:13 +0100 Subject: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down In-Reply-To: References: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> Message-ID: Hi Randy, On Tue, 28 Nov 2023 at 16:44, Randy Bush wrote: [...] > that looks more like "we do not seek volunteers," and a strong singal > discouraging new blood. > > fwiw, i an a long term alex fan. but i have enough german ancestry to > be over fond of process. we really need to be careful of unintentional > gatekeeping. We called for volunteers in September. So far we have had one, Alex. He will present himself tomorrow. The WG will decide at RIPE 88. Kind regards, Leo From elvis at v4escrow.net Tue Nov 28 17:34:20 2023 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Tue, 28 Nov 2023 08:34:20 -0800 Subject: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down In-Reply-To: References: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> Message-ID: Hi Leo, the [?] you conveniently cut out from Randy?s e-mail does not look like a proper call for volunteers and I bet that?s what Randy was pointing to. Alex is very suited for the job (*) and he has my +1, but maybe you could do the right thing as Randy suggested and do a proper call for volunteers so we can all vote Alex in following the right process. Elvis * while I was his colleague at the NCC, Alex ran the PICG (Policy Implementation and Coordination Group) within the NCC and implemented the Impact Analysis into every policy proposal. Naming just two things (out of hundreds) that make him more than just qualified to be an AP-WG Co-Chair This message was sent from a mobile device. Some typos may be possible. On Tue, Nov 28, 2023 at 8:15?AM Leo Vegoda wrote: > Hi Randy, > > On Tue, 28 Nov 2023 at 16:44, Randy Bush wrote: > > [...] > > > that looks more like "we do not seek volunteers," and a strong singal > > discouraging new blood. > > > > fwiw, i an a long term alex fan. but i have enough german ancestry to > > be over fond of process. we really need to be careful of unintentional > > gatekeeping. > > We called for volunteers in September. So far we have had one, Alex. > He will present himself tomorrow. The WG will decide at RIPE 88. > > Kind regards, > > Leo > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://mailman.ripe.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zsako at nic.hu Tue Nov 28 18:07:23 2023 From: zsako at nic.hu (Janos Zsako) Date: Tue, 28 Nov 2023 18:07:23 +0100 Subject: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down In-Reply-To: References: <27D5B85D-A10B-4744-9DDE-4C130F4B932A@bais.name> Message-ID: <81a57769-0a13-4a8e-a156-12c40ba79e7a@nic.hu> Dear all, > the [?] you conveniently cut out from Randy?s e-mail does not look like > a proper call for volunteers and I bet that?s what Randy was pointing to. I agree with Elvis here. The omitted part was: "We have informed you in September about the fact that James Kennedy is moving into a new role at the RIPE NCC We have found a willing participant from the community to help us fill the gap and join the AP-WG Chair collective." This kind of suggests that no proper process was followed. HOWEVER on 18 September 2023 Leo & Erik sent a mail to the list with the subject "Address Policy WG Co-Chair - James Kennedy Steps Down" which contained the following paragraphs: "You will have seen the recent announcement that James Kennedy has joined the RIPE NCC as Chief Registry Officer. He's stepping down from his community leadership roles, including as co-chair of the Address Policy WG. Because we still have two co-chairs there is no immediate need to recruit a replacement. Instead, we'd like to encourage anyone considering joining the team to contact us to discuss what is involved. You can write to us and we can schedule a call. You can also approach us at RIPE 87 in Rome." The selection process: https://www.ripe.net/participate/ripe/wg/active-wg/ap/address-policy-wg-chair-selection-process states that: "Once a year one of the chairs will step down, allowing new candidates the opportunity to become chair. The chairs take turns stepping down, and this is announced to the working group mailing list at least one month before the start of a RIPE meeting." Based on the above, to me, the second and third paragraph of the September mail looks like a proper call for volunteers. Therefore, I see no obstacle for Alex to be selected as WG co-chair at this meeting. At the same time, I want to state my support for Alex. Best regards, Janos From phessler at theapt.org Wed Nov 29 12:28:04 2023 From: phessler at theapt.org (Peter Hessler) Date: Wed, 29 Nov 2023 12:28:04 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: Hi everyone, I mentioned this during the WG session but want to bring it up on the mailing list, what is the definition of assignment-size. In the IPv6 implementation of AGGREGATED-BY-LIR there is an assignment-size attribute, which is proposed to be optional for the IPv4 version. >From the inet6num documentation: "assignment-size:" - This specifies the common size of all individual assignments aggregated into one block with the status 'AGGREGATED-BY-LIR'. This attribute is required to be present if the inet6num object has this status. The individual assignments do not need to be represented in the RIPE Database. But one or more assignments may be included if the member wishes to specify them for any reason. While there is no definition of what "size" means, my understanding is that the technical implementation follows the implemention requirements of inet6num objects, which is the CIDR size. However, in IPv4 it is allowed to do CIDR _or_ an arbitrary range of addresses. So if one were to create this inetnum object: inetnum: 192.0.2.0 - 192.0.2.255 netname: customers of example status: AGGREGATED-BY-LIR assignment-size: 32 ... Here the assignment size is ambiguous. Is it 32 addresses aka a /27, or is it a /32 aka 1 address. I propose that we define this to be a CIDR assignment and they put in the number of bits of the netmask, so the above example would be assignment-size of /32. -peter From tore at fud.no Wed Nov 29 13:33:54 2023 From: tore at fud.no (Tore Anderson) Date: Wed, 29 Nov 2023 13:33:54 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: On Wed, 2023-11-29 at 12:28 +0100, Peter Hessler wrote: > I mentioned this during the WG session but want to bring it up on the > mailing list, what is the definition of assignment-size. > > In the IPv6 implementation of AGGREGATED-BY-LIR there is an > assignment-size attribute, which is proposed to be optional for the IPv4 > version. > > From the inet6num documentation: > ?"assignment-size:" - This specifies the common size of all > ?individual assignments aggregated into one block with the status > ?'AGGREGATED-BY-LIR'. This attribute is required to be present if the > ?inet6num object has this status. The individual assignments do not need > ?to be represented in the RIPE Database. But one or more assignments may > ?be included if the member wishes to specify them for any reason. > > While there is no definition of what "size" means, my understanding is > that the technical implementation follows the implemention requirements > of inet6num objects, which is the CIDR size. > > However, in IPv4 it is allowed to do CIDR _or_ an arbitrary range of > addresses.? So if one were to create this inetnum object: > > ? inetnum: 192.0.2.0 - 192.0.2.255 > ? netname: customers of example > ? status: AGGREGATED-BY-LIR > ? assignment-size: 32 > ? ... > > Here the assignment size is ambiguous.? Is it 32 addresses aka a /27, or > is it a /32 aka 1 address. > > I propose that we define this to be a CIDR assignment and they put in > the number of bits of the netmask, so the above example would be > assignment-size of /32. Hi Peter, Agreed 100%, that is the intuitive understanding, especially considering that it is already in use like that for inet6num. I propose that we simply ask the RIPE NCC (hello Angela!) to confirm that their intended implementation of assignment-size for IPv4 inetnum is a CIDR prefix length. If it is, and there are no opposing voices against defining it in that way, I believe there should be no need to do a v3 of the proposal just to state this explicitly. (I also suggest that while the NCC is at it, they should document assignment-size as being a CIDR prefix length for inet6num as well. As you point the formal definition is not crystal clear there either, which was a bit of a surprise to me, honestly. But all current inet6num objects have an assignment-size within the range 31-128, so I guess LIRs simply get it - unless the database software enforces it by rejecting updates with values above 128.) Tore From gert at space.net Wed Nov 29 16:41:14 2023 From: gert at space.net (Gert Doering) Date: Wed, 29 Nov 2023 16:41:14 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: Hi, On Wed, Nov 29, 2023 at 12:28:04PM +0100, Peter Hessler wrote: > I propose that we define this to be a CIDR assignment and they put in > the number of bits of the netmask, so the above example would be > assignment-size of /32. Seconded. Well spotted. Maybe even make the syntax require the "/", at all times, so it's visually clear right away. "This is a /32, not a 32 which might be either" gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From phessler at theapt.org Wed Nov 29 16:59:45 2023 From: phessler at theapt.org (Peter Hessler) Date: Wed, 29 Nov 2023 16:59:45 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: On 2023 Nov 29 (Wed) at 16:41:14 +0100 (+0100), Gert Doering wrote: :Hi, : :On Wed, Nov 29, 2023 at 12:28:04PM +0100, Peter Hessler wrote: :> I propose that we define this to be a CIDR assignment and they put in :> the number of bits of the netmask, so the above example would be :> assignment-size of /32. : :Seconded. Well spotted. : :Maybe even make the syntax require the "/", at all times, so it's visually :clear right away. "This is a /32, not a 32 which might be either" : :gert I don't mind requiring a "/", but I very much want it to stay in sync with the IPv6 syntax. If we add this to the IPv4 implementation for parity, we shouldn't change it to take it out of parity. :) -peter -- Overdrawn? But I still have checks left! From eshryane at ripe.net Wed Nov 29 17:35:39 2023 From: eshryane at ripe.net (Edward Shryane) Date: Wed, 29 Nov 2023 17:35:39 +0100 Subject: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) In-Reply-To: References: Message-ID: <79D8A263-7311-41A4-9254-5B6F5AB63DD2@ripe.net> Hi Tore, > On 29 Nov 2023, at 13:33, Tore Anderson wrote: > ... > > (I also suggest that while the NCC is at it, they should document > assignment-size as being a CIDR prefix length for inet6num as well. As > you point the formal definition is not crystal clear there either, > which was a bit of a surprise to me, honestly. But all current inet6num > objects have an assignment-size within the range 31-128, so I guess > LIRs simply get it - unless the database software enforces it by > rejecting updates with values above 128.) > > Tore > I confirm that the verbose help text for "assignment-size:" currently states: assignment-size Specifies the size of blocks assigned to end users from this aggregated inet6num assignment. Specifies a numeric value. We will update the text to include CIDR prefix length for inet6num. Regards Ed Shryane RIPE NCC From mschmidt at ripe.net Thu Nov 30 16:40:15 2023 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 30 Nov 2023 16:40:15 +0100 Subject: [address-policy-wg] Update on AS Number Assignments - Transitioning to Policy Compliance Message-ID: Dear colleagues, During the RIPE 87 Address Policy working group session yesterday, I presented the topic of AS Number assignments, specifically addressing a policy in place since 2010. According to this policy, assignments should be made from an undifferentiated 32-bit AS Number allocation pool. https://www.ripe.net/publications/docs/ripe-679#ASnumbers Before this policy became active in 2010, the Address Policy WG recognized that many providers were not ready to exclusively work with 32-bit ASNs, mostly due to technical constraints. A verbal consensus in 2009 suggested that the RIPE NCC would temporarily continue using two pools of 16-bit and 32-bit AS Numbers. The plan was to attempt to extend the global policy by 12 months, but this effort was never undertaken. To date, the RIPE NCC remains the only Regional Internet Registry (RIR) employing this temporary approach. Observing that other RIRs have successfully issued AS Numbers from an undifferentiated pool for many years without technical challenges for operators, the RIPE NCC plans to phase out the current temporary approach. The intention is to align with the policy and issue AS Numbers accordingly. No objections were raised during the working group session. However, for transparency, we want to inform working group members who couldn't attend the RIPE meeting. The presentation can be viewed here: https://youtu.be/Zoq4PpqlaK4?t=1797 Kind regards, Marco Schmidt Manager Registration Services RIPE NCC