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

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

by Maximilian Wilhelm

Hi folks, Anno domini 2023 Peter Hessler scripsit: > I still support the proposal as-is. The proposed change does not > weaken any data that is in the database, and in fact may allow it to be > more obvious that these address ranges are used by end users rather than > be unclear what their status is. > > Furthermore, I will state that Denis' objections are not relevant to the > proposal. The proposers, various people on the lists (including myself), > and the RIPE NCC themselves all state the opposite of what Denis is > saying. In addition the proposers have, in my opinion, addressed the > concerns stated. +1 to what Peter said. Cheers, Max

2 years, 1 month

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

by APEX NCC ORG

Good day! Can you provide an example of using and registering an AGGREGATED-BY-LIR object for IPV4? Who is this for and when? Is its use mandatory? Initially, the assignment policy was discussed as an assignment for cloud providers. What should a provider do, for example, if it has a status ASSIGNED PA object (for example /20), splits it into /24 objects also like ASSIGNED PA with additional routes obj. for its end clients (without NAT / with NAT)? Is it here an AGGREGATED-BY-LIR status objects? Or NOT? Thank you! On 4/15/24 17:50, Angela Dall'ara wrote: > Dear colleagues,  > > Consensus has been reached on 2023-04 "Add AGGREGATED-BY-LIR status > for IPv4 PA assignments". > > This proposal aimed at introducing the AGGREGATED-BY-LIR status for > IPv4 PA assignments to reduce LIR efforts in registration and maintenance. > > You can find the full proposal > at:   https://www.ripe.net/membership/policies/proposals/2023-04/ > > The new RIPE Document is called ripe-822 and is available at:  > https://www.ripe.net/publications/docs/ripe-822/ > > > We estimate that this proposal will take around two months to fully > implement. > > We will send another announcement once the implementation is complete > and the new procedures are in place. >   > Thanks to everyone who provided input. >   > > Kind regards, > > Angela Dall'Ara > Policy Officer > RIPE NCC > -- Best wishes, APEX NCC ORG -------------------------------- +38(056)-731-99-11, +38(067)-731-99-11, +38(050)-731-99-11, www.trifle.net

1 year, 9 months

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

by denis walker

Hi Tore On Wed, 20 Dec 2023 at 16:59, Tore Anderson <tore(a)fud.no> wrote: > > 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. Most of these allocations are /24. So if 4551 of these /24 allocations have no assignments, and the increase in allocations without assignments is only 3536, then we actually have more allocations with assignments than we had before, putting aside the /24 allocation issue. So the trend is downwards. The overall number of allocations without assignments is decreasing. cheers denis > > Please note that this number may include new inetnum objects created > from transfers.» > > Best regards, > > Tore and Jeroen >

2 years, 1 month

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

by denis walker

Hi Nick I feel your pain on this one. I can understand that no LIR wants to invest time or money in developing this as a one off, in-house solution. Something like this needs to be done at a higher level. That's why you pay fees to the RIPE NCC. They should be talking to the developers of the commercial IPAM systems about syncing with the RIPE Database. Whether or not it could be done with the current data model and software I don't know. But it is time to consider these things. cheers denis co-chair DB-WG On Wed, 27 Sept 2023 at 22:57, Nick Hilliard <nick(a)foobar.org> wrote: > > denis walker wrote on 24/09/2023 17:12: > > So are you saying > > that in 2023 we can't manage a distributed database without > > overwhelming repetitive tasks? > > yes, correct. People are stuck using the tools that they have. Most > off-the-shelf tools don't implement server-client or 2way database > synchronisation between the local ipam system and the ripe db, and > there's ~zero financial inventive to build this sort of functionality > in-house. The outcome is that the ripedb ends up with manual updates, or > else with low quality / 1-way synchronisation with little or no cleanup. > > The result of this is that the ASSIGNED-PA objects in the ripedb are > generally of low average accuracy. > > Nick

2 years, 4 months

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

by RODOLFO GARCIA PEÑAS

Great proposal. I agree with it. Best Regards, Rodolfo Rodolfo García Peñas (kix) Diseño y Planificación Conectividad IP | Telefónica España -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces(a)ripe.net> En nombre de Angela Dall'Ara Enviado el: lunes, 4 de septiembre de 2023 11:54 Para: RIPE Address Policy Working Group <address-policy-wg(a)ripe.net> Asunto: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) Dear colleagues, A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 PA assignments" is now available for discussion. This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-04 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 We encourage you to review this proposal and send your comments to address-policy-wg(a)ripe.net before 3 October 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://lists.ripe.net/mailman/listinfo/address-policy-wg ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

2 years, 4 months

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

by Tore Anderson

Hi Jan, On 09/01/24 10:51, Jan Ingvoldstad wrote: > On Sat, Dec 16, 2023 at 7:55 PM Tore Anderson <tore(a)fud.no> wrote: > > The second – alleged – change is the one that has been discussed the > most on the mailing list. The argument here is that your two ASSIGNED > PA objects above are actually in violation of *current* policy, > because > they delegate all the contact information to you (the ISP/LIR). The > claim is that current policy requires non-delegated contact > information > for the End User to be published in the object (not necessarily in > admin-c/tech-c, but “somewhere”). > > If 2023-04 passes, your two ASSIGNED PA assignments above will > definitely be policy compliant (even before they are possibly replaced > with an AGGREGATED-BY-LIR object). There is no disagreement about > this, > as far as we know. > > So the question is whether or not your two ASSIGNED PA objects are > permitted under *current* policy. If they are, then 2023-04 does not > change anything in this regard; the “legal status” of your objects > will > remain the same – i.e., they are not violating policy – after 2023-04 > passes (or fails) as it is under current policy. > > We believe your two objects are not in violation of today’s policy, > which means 2023-04 will exact no change to their “legal status”. We > have elaborated on why in this message, under the heading «Does > 2023-04 > change the contact registration requirements for assignments?»: > > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013… > > We hope this provides the clarification you requested. > > > Regrettably it does not, and it also raises the question of whether > you have forgotten the definition of "end user" and confused it with > "private person". > > 4. > An obligation to publish the End User’s contact information in the > RIPE database will constitute a violation of Article 6(3) of the > RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the > GDPR[6], if the End User’s contact person has not given explicit > consent to such publication. We believe that the RIPE policy > cannot reasonably be interpreted to require LIRs to break EU law > (and even if it explicitly did require that, EU law would still > take precedence). > > > This is misleading, as posting the contact details of an end user > **does not necessarily require that you post PII** (person identifying > information). You can use a company role and a company role's email > address. This is also quite common in the RIPE database today, as far > as I can tell. It is important to also consider the cases where the End Users are organisations that do not have non-PII role addresses. Consider for example a small one-person business, let's say a farm owned by «Farmer Fred». This End User would be a company, not an individual, yet the company is often given the same name as the person owning it (at least here in Norway). The e-mail address might well be farmer.fred@gmail and the phone number might be the Farmer Fred's personal mobile. This would mean that both the name and the contact information for this End User *is* PII and is in scope of the GDPR. Therefore, if Farmer Fred exercises his rights under the GDPR to object against / not give consent to the publishing of his PII in the RIPE DB, you (the LIR) have a problem. Proceeding to publish this contact information over Farmer Fred's objections opens you up to legal risk (not to mention souring the relationship with your customer). > Additionally, this is what we in the registrar business consider a > solved problem. In the event that the end user is a private person, > you instead by default post anonymized information and e-mail > addresses. In the case of e-mail addresses, the typical solution is to > post a randomized e-mail address that acts as a forwarding address, > and that this address is rotated according to the registrar's internal > criteria. In the case of RIPE, it would be the LIR's responsibility, I > guess. Precisely. The LIR, like a domain name registrar, can simply serve as a proxy between the wider Internet community and its End Users. This voids any policy requirement to (possibly illegally) publish Farmer Fred's PII in the RIPE DB. As stated in the Impact Analysis, the RIPE NCC is of the opinion that this (already widespread) practice is permitted by current policy, and will continue to be permitted after 2023-04 is implemented. In other words, just like in the registrar business, this is an already solved problem, which will continue to be solved after 2023-04 is implemented. It is in this respect that we say that 2023-04 will not bring about any change – it ain't broken, and we're not fixing it. The claim that has been made is that *current* policy does not allow LIRs to serve as proxies in this manner, and that the RIPE NCC has not been implementing current policy correctly by allowing it. It is further claimed that 2023-04 will bring about an (undesired) change in that it will allow LIRs to serve as proxies. However, for the reasons already discussed we are of the opinion the premise this argument rests on is incorrect, hence we do not believe 2023-04 will effect any change. We hope this clarifies the clarification. :-) Tore & Jeroen

2 years

Re: [address-policy-wg] 2023-04 Discussion scope

by Gert Doering

Hi, On Fri, Jan 12, 2024 at 08:56:48AM +0100, Alex Le Heux wrote: > However, is has been argued that this interpretation is wrong and > that PA Assignments in the RIPE DB must include the actual end-user > details. And even though this is out of scope for the 2023-04 > discussion, it is still something that is worth resolving. As > changing this interpretation would be a major departure of many > years of accepted practice and potentially involve updating thousands > of RIPE DB objects, we feel this discussion would be best served > by an independent policy proposal that clarifies the issue and would > like to invite the working group to enter one. This. I personally feel that the way this is currently handled "by all parties involved" is reasonable middle ground - documentation is available, and the level of end-user detail depends on local agreements and also requirements. I am aware that Dennis found text in the policy documents that require doing something different, namely having admin-c "on site", whatever that may mean in a context where the "ASSIGNED PA" inetnum is in a datacenter somewhere (so, nobody "on site", in particularily not "working for the customer"). So formally there is a conflict. But this is all outside of 2023-04, so if we think that the current way of "getting things done" is in conflict to (very very old) policy text, it sounds as if we need to adjust that old text, because "overtaken by history". I'm not actively volunteering, just supporting Alex' point :-) Gert Doering -- LIR contact since 1995 or so... -- 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

2 years

2023-04 Discussion scope

by Alex Le Heux

Dear Working Group, During the discussion about AGGREGATED-BY-LIR status for IPv4 PA assignments the argument has been raised that this proposal would substantially change the registration requirements for end-user assignments in the RIPE DB and the discussion has been going around in circles ever since. We would like to point out the following: From the RIPE NCC Impact Analysis: [...] 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. [...] As well as: It is fact that the RIPE NCC has interpreted the current policy to not require a PA Assignment in the RIPE DB to include the actual name and email address of the end-user since at leas the late 1990s. Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time. In its impact analysis the RIPE NCC has indicated that this proposal does not change this interpretation. It should therefore be clear that 2023-04 does not in fact change anything regarding how end-user details will actually be registered in PA Assignments. However, is has been argued that this interpretation is wrong and that PA Assignments in the RIPE DB must include the actual end-user details. And even though this is out of scope for the 2023-04 discussion, it is still something that is worth resolving. As changing this interpretation would be a major departure of many years of accepted practice and potentially involve updating thousands of RIPE DB objects, we feel this discussion would be best served by an independent policy proposal that clarifies the issue and would like to invite the working group to enter one. Kind regards, Alex Le Heux, for the Address Policy WG co-chairs

2 years

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

by Sander Steffann

Hi, > On 15 Dec 2023, at 15:32, Maximilian Wilhelm <max(a)rfc2324.org> wrote: > > Hi folks, > > Anno domini 2023 Peter Hessler scripsit: > >> I still support the proposal as-is. The proposed change does not >> weaken any data that is in the database, and in fact may allow it to be >> more obvious that these address ranges are used by end users rather than >> be unclear what their status is. >> >> Furthermore, I will state that Denis' objections are not relevant to the >> proposal. The proposers, various people on the lists (including myself), >> and the RIPE NCC themselves all state the opposite of what Denis is >> saying. In addition the proposers have, in my opinion, addressed the >> concerns stated. > > +1 to what Peter said. > > Cheers, > Max I’ll add my +1 as well. I think this discussion has brought the issue to the attention of this community extensively. After reading the history on this mailing list and looking at the impact analysis, I think we have reached the point in rough consensus where Denis’ concerns have been addressed, but not accommodated. This is a valid outcome: "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated” Cheers, Sander

2 years, 1 month

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

by Jeroen Lauwers

Dear colleagues, Though we recognise that most of you are probably busy preparing for the upcoming holidays, we would like to ask you to share your opinion on proposal 2023-04. Remember that Policy Development Process requires any comments made during the Discussion phase must be repeated during the Review phase in order to count towards or against rough consensus, as your views can now take the RIPE NCC’s Impact Analysis into account. Here are some questions for the WG to get the discussion started: Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way? Does 2023-04 address this use case well in its current form, or could you think of any potential improvements? We hope you will find the time to let your voice be heard! The Policy Development Process requires the proposers to adequately address any suggestions for changes or objections to the proposal in each phase, which we will do below. 1. Does 2023-04 change the contact registration requirements for assignments? The argument made is that the statement «When an End User has a network using public address space this must be registered separately with the contact details of the End User» found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy), implicitly requires LIRs to register non-delegated/outsourced contact information for the End User in the RIPE database, not necessarily in the mandatory «admin-c» or «tech-c» attributes, but possibly in an optional attribute like «descr», «org» or «remarks». Proposers’ response: We do not believe so, for the following reasons, and keeping the current practice and policies in consideration: 1. The RIPE NCC does not consider that 2023-04 changes the contact registration requirements in any way[1][2][3]. Absent any (rough) consensus in the Working Group to the contrary, we defer to the RIPE NCC’s judgement on this point. 2. The practice of creating assignments with all contact information delegated is already widespread. If this was a policy violation made possible due to the RIPE NCC implementing RIPE policy incorrectly, we would have expected the community to take action to correct this situation. However, no such policy proposal has been put forward by the community. 3. Outsourcing and delegation of contact information is a common practice across many industries, including in networking and information technology. There is no policy language that explicitly prohibits this for IPv4 assignments. Absent that, we believe any implicit prohibition found “between the lines” is essentially «void for vagueness»[4]. 4. An obligation to publish the End User’s contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User’s contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence). 5. The policy’s stated goal of registering assignments is «to ensure uniqueness and to provide information for Internet troubleshooting at all levels»[7]. Requiring LIRs to publish the contact information of End Users who often will not have any knowledge or capability to aid with troubleshooting does work towards this attaining goal. On the contrary, delegating the contact information to the LIR/ISP may well be the only way to attain this goal. [1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01… [2] https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013… [4] https://www.law.cornell.edu/wex/void_for_vagueness [5] https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms [6] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d… [7] https://www.ripe.net/publications/docs/ripe-804#3 2. The «assignment-size» attribute should be a CIDR prefix length Leaving it undefined could result in some LIRs using it to represent an IPv4 address count, while others would use it to represent a CIDR prefix length. Proposers’ response: We agree «assignment-size» should be a CIDR prefix length. We understand that, if proposal 2023-04 would be accepted, the RIPE NCC could implement the «assignment-size» attribute for IPv4 inetnum objects to be a CIDR prefix length, and document it as such. Therefore we do not believe it is necessary to spell this out explicitly in the policy document (it is not spelled out in the IPv6 policy document either). Thank you for your attention and enjoy your holidays! Best regards, Jeroen and Tore Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara <adallara(a)ripe.net<mailto:adallara@ripe.net>> het volgende geschreven: 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(a)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://lists.ripe.net/mailman/listinfo/address-policy-wg

2 years, 1 month

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