From melchior at aelmans.eu Mon May 10 16:08:44 2021 From: melchior at aelmans.eu (Melchior Aelmans) Date: Mon, 10 May 2021 16:08:44 +0200 Subject: [address-policy-wg] a third WG co-chair In-Reply-To: References: <10AB26A8-3DBE-422D-8C13-C519B976E46E@bais.name> <891A2DA7-B9C6-451E-885C-67B01B629E0F@rfc1035.com> <23026FFF-F59B-424C-9905-C49BF8059B0F@rfc1035.com> Message-ID: I think having a third chair is an excellent opportunity for someone with less experience to run with the 2 other chairs to gain experience and learn from them. I believe Job expressed a similar idea a few meetings ago for the routing WG. On Sat, Apr 10, 2021 at 6:56 PM Leo Vegoda wrote: > Hi, > > I echo James on Gert's accumulated experience. Separately, I think > it's worth noting that a team of three provides more resilience. In > the event that one person is unavailable or has to recuse themselves > from a discussion, there is always another person to work through > issues with. > > Kind regards, > > Leo > > On Fri, Apr 9, 2021 at 1:15 PM Kennedy, James via address-policy-wg > wrote: > > > > Hi Jim, > > > > Honestly I had a similar reaction when I first heard the suggestion - > considering how quiet the AP-WG has been of late, do we really have the > need for three chairs now? > > > > As Gert wrote earlier, we have heard that some people want a systematic > review of the AP documents performed to make them easier to follow and > comprehend, and to improve consistency within and between the docs. Kurt > highlighted some good examples on Tuesday. Such an activity would > considerably increase the workload for the WG and the chair team. > > > > This, along with Gert leaving a sizable footprint (size 47) of knowledge > and experience to fill, leaves me to believe that having three chairs for > the upcoming period offers more benefit than harm. > > > > Regards, > > James > > > > -----Original Message----- > > From: address-policy-wg On Behalf > Of Jim Reid > > Sent: Friday 9 April 2021 18:12 > > To: Sander Steffann > > Cc: Piotr Strzyzewski ; RIPE address policy > WG > > Subject: Re: [address-policy-wg] a third WG co-chair > > > > > > > > > On 9 Apr 2021, at 17:06, Sander Steffann wrote: > > > > > > That is actually not true. I volunteered to become co-chair > > > immediately after the APWG session where Hans Petter resigned, and was > > > accepted as co-chair by the working group at the next RIPE meeting. > > > > I stand corrected Sander. > > > > No matter. My point remains. Why does the WG need a third co-chair? > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri May 14 12:19:48 2021 From: gert at space.net (Gert Doering) Date: Fri, 14 May 2021 12:19:48 +0200 Subject: [address-policy-wg] recorded RIPE NCC presentations are now online Message-ID: Dear AP WG, as Erik already announced, this meeting is different :-) - in the last meeting, we noticed that Meetecho is actually quite good in enabling a "real" discussion - but we had no time. So, this time, the "we want to discuss this!" topics are online as a pre-recording, as of right now for the NCC PO/RS talks (Marco and Angela). Because I'm already enjoying my soon-to-be WG chair retirement, I'm just being lazy and forward Marco's Mail with the links and with the reminder: to have an informed discussion, you are expected to watch these before the actual meeting on Tuesday (or at least look at the Slides). We will *not* use our WG time to play back videos - we'll do Q&A, and then discussion, on the questions raised by these talks. See you next week (virtually...) Gert Doering creaky APWG chair ----- Forwarded message from Marco Schmidt ----- From: Marco Schmidt Hello Erik, Gert, James and Leo, The pre-recorded presentations from Angela and me are now online and published as part of the APWG agenda https://ripe82.ripe.net/programme/meeting-plan/ap-wg/ With the direct links https://ripe82.ripe.net/wp-content/uploads/presentations/ripe-82-policy-development-office-update.mp4 https://ripe82.ripe.net/wp-content/uploads/presentations/ripe-82-feedback-rs.mp4 Please feel free to inform that WG members to watch these presentations before the session. I see the risk that some people will not expect that they need to watch the presentation upfront. So as earlier they know about it, the more this risk is minimized. Have a nice weekend and see you next week! Regards, Marco Schmidt ----- End forwarded message ----- -- 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 adavies at ripe.net Mon May 17 12:08:06 2021 From: adavies at ripe.net (Alun Davies) Date: Mon, 17 May 2021 12:08:06 +0200 Subject: [address-policy-wg] New on RIPE Labs: SCION - A Novel Internet Architecture Message-ID: <29544051-C62B-410A-9437-15A465BD1D48@ripe.net> Dear colleagues, At RIPE 81, a group of enthusiastic researchers and practitioners from industry and academia discussed with the RIPE community what role RIRs and LIRs could take on in the SCION next-generation Internet architecture. Ahead of the SCION BoF taking place today at RIPE 82, David Hausheer looks back at what happened at the last BoF, reports on what has happened since then, and presents what potential RIPE involvement could look like in the future. Read more on RIPE Labs: https://labs.ripe.net/author/hausheer/scion-a-novel-internet-architecture/ Kind regards, Alun Davies RIPE Labs Editor RIPE NCC From ripedenis at gmail.com Mon May 17 15:16:04 2021 From: ripedenis at gmail.com (denis walker) Date: Mon, 17 May 2021 15:16:04 +0200 Subject: [address-policy-wg] Mass deletion of assignments from RIPE Database? Message-ID: Colleagues [Apologies for the long email, but I feel the video is an oversimplification of the issues involved.] I have watched the video from the AP-WG agenda for RIPE 82 by the RIPE Database Task Force (TF). As a netizen, rather than in any other capacity, I am totally opposed to this recommendation which would allow the removal of all IPv4 assignments from the public registry of IP addresses. I would like to present some opposing arguments before the discussion tomorrow in the AP session at RIPE 82. In the video there are 4 justifications given. None of these can actually be considered as a justification for this recommended policy change. 1/ some allocations have no registered assignments This should be followed up by the RIPE NCC with ARCs. If the current policy has not been followed, then assignment objects should be created. If a few resource holders don't follow the policy, that is not a justification for changing the policy. Encouragement to follow, or enforcement of, the policy is the answer to this. 2/ Small (/24) allocations require even smaller (/25) assignments There is an action point in the DB-WG (NWI-4) to allow multiple status values in INETNUM allocation objects which would address this issue without policy change. 3/ data minimisation, less data to maintain = more accurate [implying that having no data gives 0% error] Googling for 'data minimisation' it is hard to find any definition that doesn't relate to personal data. This is the best fit I found: "The principle of data minimization involves limiting data collection to only what is required to fulfill a specific purpose." If there is a valid purpose for assignment data then this isn't 'data minimisation', it is 'data loss' resulting in reduced functionality. So the historical, present and future use of assignment data is the real question to consider. 4/ justify additional allocations This was 'one of' the historical reasons for creating assignments in the DB. Since run out this reason no longer applies. But that does not mean there are no other reasons for having assignment data in the DB. In the video the TF suggest that 'now' this reason no longer applies, perhaps we can drop this policy requirement. As ripe-733 (assignment policy) no longer even mentions this as a reason for creating assignments in the RIPE Database, I don't see the connection between this long since discarded reason and changing the policy now. The video ignores any other reasoning for the existence of assignments in the DB. The suggestion in the video was that creating (PA) assignments would be optional. It also said "Partitions and sub-allocations 'should' be registered. It is important to note that in policy speak, 'should' is not the same as 'must'. This makes everything more specific to (PA) allocations optional. What are the likely consequences to this change? Many operators maintain internal software to align their internal address management with the RIPE Database. This involves a lot of time, effort and money to keep the RIPE Database up to date. They are also open to criticism if anyone finds a single email in the DB that is invalid. It also exposes their publicly identified customers to being directly accountable for their use of address space assigned to them. While most end users probably don't have an issue with that, internet abuse originates from somewhere. Those networks probably prefer to be hidden out of view. By making all this data optional, resource holders can simply delete all this data from the RIPE Database. They can archive the software used to align their internal systems with the RIPE Database. They can shield their customers behind the court order firewall from any exposure to questioning of their usage of their assigned address space. The resource holder can hide themselves behind a contract putting responsibility of usage of address space on their (now) hidden customers. Without a court order this all becomes private, hidden data. It is easy to see benefits to resource holders and operators for this change, but does it have a negative impact on other RIPE Database data consumers? I suspect making this policy change could/would result in a mass deletion of (PA) assignment data from the RIPE Database leaving only the allocations made by the RIPE NCC. In this scenario what happens with abuse reporting? All reports would have to be sent to the LIR holding the allocation resource. They could put a simple mail forwarder on that email address and forward all reports to the appropriate (hidden) customers. If anyone questions a report sent, the answer could be "I forwarded it on to the user. If they haven't replied to you, get a court order to reveal the customer details and take it up with them directly." What happens with blocking & blacklisting addresses? Unless it is possible to determine assignment sizes from other data (routing perhaps?) then the only option is to block or blacklist the whole allocation. There are no aggregated objects with assignment sizes like with IPv6. Removing assignment objects also impacts the use of the RIPE Database as a contact DB for network operators. Resource holders will have to weigh up if the need for more specific network contacts was important enough to justify them maintaining all their assignment data in the RIPE Database. For larger resource holders, given the savings to them by ditching this data, they may well choose to sacrifice network contacts. In the video the TF talks about the 'freedom' of LIRs to choose if they want to enter assignment data or not. Their freedom is someone else's denial. They also talk about a smaller, common, useful database. This smaller, common database is not very useful to anyone who uses the assignment data that is discarded to make it smaller. Looking at it from the perspective of accountability, openness and abuse issues, deleting 94% of the IPv4 registry data from this public registry and turning all this information into private data requiring individual court orders to access each bit of what was public data, I believe would be a huge backwards step. Even if the reality turned out to be half the assignments being deleted, is a partial data set, with less eyes focussed on the reliability and accuracy of the data, of any use to anyone? In recent years the use of the DB by LEAs, abuse handlers and researchers has been hotly debated and contested. If you look at recent policy discussions and DB functionality issues, two phrases come up time and time again. "It's not the purpose of the RIPE Database to do 'abc'." "It's not the function of the RIPE NCC to do 'xyz'." So many engineers and operators seem to have difficulty accepting that the purpose of the RIPE Database has evolved over time and is now more than an engineer's and operator's tool. In today's society the internet is not only an essential part of every day life, it is also a dangerous place. The DB has become an essential tool for LEAs and companies & organisations that try to address internet abuse. That is despite many engineers and operators constantly dismissing this as not a (historical) purpose of the RIPE Database. The same argument is used against researchers. Use as a research tool was not on the original list of purposes of the DB. The whole umbrella of research is an essential part of moving forward with technology. It is time to stop the endless arguments about the purpose of the RIPE Database and accept that use by LEAs, abuse handlers and researchers is now part of the fabric of the RIPE Database. Whilst the TF acknowledges this friction in their draft requirements document, there are no recommendations to resolve this issue. I would like to see the TF address this and recognise these as valid purposes of the RIPE Database. I hope recommendations will be included in a future draft of the TF's requirements document that recognises these new and important purposes of the RIPE Database by an expanding and diversifying set of data consumers. Moving forward on address policy with these newly accepted purposes of the DB, the IPv4 assignments take on a more important role. In this context I do not believe assignments should be made optional, and almost certainly deleted to become hidden, private data, behind a court order firewall. cheers denis long standing, but forward looking, netizen Question to the RIPE NCC... Can you select a random week day and calculate the total number of queries where the query string is an IPv4 address. If possible can you determine if the query string address is contained within a PA assignment object and calculate the percentage of these queries that would have returned an assignment object. If this recommendation is accepted, these queries in future would most likely only return the resource allocation object. From eshryane at ripe.net Tue May 18 22:13:49 2021 From: eshryane at ripe.net (Edward Shryane) Date: Tue, 18 May 2021 22:13:49 +0200 Subject: [address-policy-wg] Mass deletion of assignments from RIPE Database? In-Reply-To: References: Message-ID: <8587E232-792C-46BB-B905-9E00597DD5A2@ripe.net> Hi Denis, > On 17 May 2021, at 15:16, denis walker wrote: > > ... > Question to the RIPE NCC... > Can you select a random week day I selected yesterday, 17th May. > and calculate the total number of > queries where the query string is an IPv4 address. I found 54M queries for an IPv4 address out of 68M total queries. > If possible can you > determine if the query string address is contained within a PA > assignment object I found 33M queries where the query string is directly within an IPv4 "ASSIGNED PA" (inetnum) object (ignoring any flags). > and calculate the percentage of these queries that > would have returned an assignment object. Taking the hierarchical query flags into account, 33M queries also returned at least one IPv4 "ASSIGNED PA" inetnum object, so 100%. > If this recommendation is > accepted, these queries in future would most likely only return the > resource allocation object. > These numbers have some uncertainty, as I used the split files generated at 3AM this morning, versus query logs for the whole of yesterday. Lots of inetnum objects were deleted or created during the day. Regards Ed Shryane RIPE NCC