Search results for "2023-04" - address-policy-wg

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

by Tore Anderson

Hi Denis, On Fri, 2023-12-15 at 11:45 +0100, denis walker wrote: > On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore(a)fud.no> wrote: > > > > Did this consultation take the information in the Impact Analysis into > > account – in particular the clarification made by the RIPE NCC that > > 2023-04 does *not* change the current policies and procedures when it > > comes to the registration requirements for End User contact > > information? > > This is NOT clarified at all in the Impact Analysis. Why are you still > saying this when I know, you know and by now probably every one knows, > it is simply NOT true. (…) > > As clarified by the RIPE NCC in the Impact Analysis, the current > > policies and procedures are already allowing assignments to be > > “somewhat anonymised”. This is not a change that 2023-04 will bring > > about. > > Again this is simply not true. That line you propose to remove does > not currently permit anonymised assignments as they MUST include > contact details of the End User. So this IS a change that 2023-04 WILL > bring about. > > Will you please finally acknowledge that 2023-04 will allow totally > anonymised, individual assignment objects that the current policy does > not allow? (This is without even using the aggregated feature you are > proposing to introduce.) As we mentioned in our message on Wednesday, Jeroen and I simply defer to the RIPE NCC’s interpretation of what current policy allows and does not allow. We will be happy to acknowledge that 2023-04 changes something the moment the RIPE NCC acknowledges the same. Let me remind you of the example assignment made by «SuperLIR GmbH» to «CarFactory GmbH», registered in the RIPE database as follows: inetnum: 192.0.2.0 - 192.0.2.128 netname: ABCDEFGHIJKLMNOPQRSTUVWXYZ country: DE admin-c: SUPERLIR-NOC-RIPE tech-c: SUPERLIR-NOC-RIPE status: ASSIGNED PA mnt-by: SUPERLIR-MNT source: RIPE We assume that you agree that the above is a «totally anonymised, individual assignment object»? We asked the RIPE NCC whether or not the above object was compliant with *current* IPv4 address policy or not. The RIPE NCC Policy Officer answered as follows: «The above registration compliant with current IPv4 address policy. …» (For the full answer, see https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01… ). This sentiment is echoed in the 2023-04 Impact Analysis (section A, paragraph 3). In light of this, we remain convinced that we accurately and truthfully represent the RIPE NCC’s interpretation of the current policy in our messages to the working group, and also that we accurately and truthfully represent the RIPE NCC’s view that 2023-04 will not change the contact registration requirements. (While admin-c and tech-c will remain mandatory, they can be delegated as in the example object above.) We are well aware that you strongly disagree with the RIPE NCC – and by extension, Jeroen and I – in this interpretation. That is of course totally fine. However, if you would like to see the actual implementation of the policy brought in line with your interpretation of it, you would need to persuade the RIPE NCC to change their mind – not Jeroen or I. Jeroen or I cannot change the RIPE NCC’s procedures. To that end, you might want to submit a policy proposal that would clarify for the RIPE NCC what the correct implementation should be, so that their procedures are brought in line with your expectations. If you do that, we can put 2023-04 on hold pending the outcome of your proposal. Best regards, Tore and Jeroen

1 year, 3 months

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

by denis walker

Hi Tore Before I dig deeper into what you said let me first focus on two points that you just made. On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore(a)fud.no> wrote: > > Hello Emmanuel, and thank you for your message! > > Please find our comments and questions inline below: > > Did this consultation take the information in the Impact Analysis into > account – in particular the clarification made by the RIPE NCC that > 2023-04 does *not* change the current policies and procedures when it > comes to the registration requirements for End User contact > information? This is NOT clarified at all in the Impact Analysis. Why are you still saying this when I know, you know and by now probably every one knows, it is simply NOT true. You acknowledged again in your reply to me yesterday that this proposal removes that famous line from the current policy: "When an End User has a network using public address space this must be registered separately with the contact details of the End User." Removing this line *does* change current policies and would change procedures if the RIPE NCC was enforcing the current policy. We have been through this so many times. This is a very clear statement that says ALL assignments MUST contain the End User contact details. Removing this line means that assignments no longer need to contain any End User contact details. That is a significant change to the details that may or may not be entered into future assignment objects. > > As clarified by the RIPE NCC in the Impact Analysis, the current > policies and procedures are already allowing assignments to be > “somewhat anonymised”. This is not a change that 2023-04 will bring > about. Again this is simply not true. That line you propose to remove does not currently permit anonymised assignments as they MUST include contact details of the End User. So this IS a change that 2023-04 WILL bring about. Will you please finally acknowledge that 2023-04 will allow totally anonymised, individual assignment objects that the current policy does not allow? (This is without even using the aggregated feature you are proposing to introduce.) cheers denis > > Best regards, > Tore and Jeroen

1 year, 3 months

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by denis walker

On Mon, 11 Sept 2023 at 18:33, Peter Hessler <phessler(a)theapt.org> wrote: > > On 2023 Sep 11 (Mon) at 16:09:58 +0000 (+0000), Brian Storey wrote: > :Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something? > : > > This behaves the same as the IPv6 version, which has not had this > problem yet. Maybe because IPv4 is still dominant for networks... > > > > -- > MESSAGE ACKNOWLEDGED -- The Pershing II missiles have been launched. > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

1 year, 6 months

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Peter Hessler

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!

1 year, 4 months

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Rinse Kloek

On 4-9-2023 11:54, Angela Dall'Ara wrote: > Dear colleagues, > > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for > IPv4 PA assignments" > is now available for discussion. > > +1 I do support this proposal. Did like the AGGREGATED-BY-LIR for IPv6 and introducing this to IPv4 will make it easier to administrate large group of assignments. Also feature parity between IPv4 and IPv6 in the RIPE database is a good thing.

1 year, 6 months

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Gert Doering

Hi, On Mon, Sep 11, 2023 at 04:09:58PM +0000, Brian Storey wrote: > Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something? Actually it gives the LIR *more* options to properly document their address usage. Anyone unwilling to register proper data is able to do so already today (especially given that the old incentive "if you do not properly document your address blocks, there will not be more IPv4 space from the NCC" is long gone). 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

1 year, 6 months

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Sebastian Wiesinger

* Angela Dall'Ara <adallara(a)ripe.net> [2023-11-21 11:15]: > > Dear colleagues, > > Policy proposal 2023-04, “Add AGGREGATED-BY-LIR status for IPv4 PA > assignments”, is now in the Review Phase. Still supporting this. Best Regards and Happy Holidays Sebastian -- 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 year, 3 months

2023-04 Last Call for Comments (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

by Karen Hung

Dear colleagues, Proposal 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 PA assignments " is now in Concluding Phase. The goal of this proposal was to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. The WG co-chairs have declared that rough consensus has been reached and the proposal will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of this four-week Concluding Phase is to give an opportunity to present well-justified objections for those who missed the previous two phases and wish to oppose the proposal. Any objection must be made before 9 April 2024 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the WG co-chairs for final consensus. You can find the full proposal at: https://www.ripe.net/membership/policies/proposals/2023-04/ Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net> before 9 April 2024. Kind regards, Karen Hung On behalf of Policy Officer RIPE NCC

1 year

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

by Tore Anderson

Hello again Denis, On 16/12/23 19:53, Tore Anderson wrote: > On Fri, 2023-12-15 at 14:20 +0100, denis walker wrote: >> On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore(a)fud.no> wrote: >>> «As of August 2023, there were 19,221 PA allocations without any child >>> PA assignments held by 10,052 LIRs (…) Since the RIPE Database >>> Requirements Task Force published their report in May 2021, the PA >>> allocations without any child assignment have grown by 18.4 percent.» >> 18.4% of 19,221 is 3536. How many /24 allocations were made in that >> time period that quite likely don't have assignments? > We will ask the RIPE NCC to provide the working group with the updated > statistics you request here. We just received the following response from the RIPE NCC: «6843 inetnum PA allocations were created since 01-MAY-2021, and 4551 of those (67%) do not have any PA assignments. Please note that this number may include new inetnum objects created from transfers.» Best regards, Tore and Jeroen

1 year, 3 months

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

by denis walker

Hi Peter On Fri, 15 Dec 2023 at 14:33, Peter Hessler <phessler(a)theapt.org> wrote: > > On 2023 Dec 15 (Fri) at 14:28:13 +0100 (+0100), Tore Anderson wrote: > :To that end, you might want to submit a policy proposal that would > :clarify for the RIPE NCC what the correct implementation should be, so > :that their procedures are brought in line with your expectations. If > :you do that, we can put 2023-04 on hold pending the outcome of your > :proposal. > : The idea of writing a policy to change the way the RIPE NCC interprets other policies makes no sense. The RIPE community simply needs to request that the RIPE NCC reviews its interpretation of the current address policy and explains it on the list for further community discussion. > > Please don't do that. Denis wishing to change policy should not block > this proposal. I don't want to change policy but keep this part under discussion, as it is right now. > > Additionally, I believe that Denis' proposal on this topic is unlikely to > reach concensous, as you can guess from reading the acrimonious > discussion across several lists. It's a pity many people choose to discuss policy on several (private) lists rather than contribute to the open, transparent, archived discussion on the official address policy list. Maybe someone can sumarise these acrimonious discussions... cheers denis > > > :Best regards, > :Tore and Jeroen > > -peter > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

1 year, 3 months

address-policy-wg search results for query "2023-04"