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.