Hi Denis, On Fri, 2023-12-15 at 14:20 +0100, denis walker wrote:
We have been through all these arguments before, but it is the review phase now so they need to be repeated.
Indeed. We will now restate our responses too, as required by the PDP. That said, there are no new arguments presented, so anyone reading this should feel free to skip the rest of this message.
On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore@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 hypothesise that this trend is least partially caused by LIRs considering that registering all assignments individually is too labour-intensive and not worth the effort, especially in highly dynamic environments where individual (but otherwise identical) assignments rapidly come and go.
Pure speculation without any numbers.
We have no hard data that prove (or disprove) this hypothesis, that is true. We have not surveyed the LIRs in question to ask them why they opt not to register assignments. That said, as we do have quite a bit of experience as LIR hostmasters (including working with highly dynamic network environments), we would prefer to call the hypothesis an educated guess, rather than pure speculation.
But what you are suggesting is that some LIRs don't consider it worth the effort to comply with RIPE policy and don't want to get involved in discussions to change the policy.
Regrettably, yes.
I don't agree with your proposal but at least you are trying to change something you don't agree with.
We do appreciate you recognising that.
As for the labour intensity, we know the answer to that, but no one will even talk about updating the 25 - 30 year old RIPE Database design, data model and technology...
We don't doubt that updating the RIPE database design, data model and technology is a good idea, but we believe this question falls outside of the scope of proposal 2023-04 (and the AP-WG charter entirely).
As for 2023-04 increasing the level of End User assignment coverage, this is pure fantasy. In theory you could perhaps argue that the 'coverage' has increased if many LIRs create aggregated objects and claim that many assignments have been made from within that block.
If a WHOIS lookup of an IPv4 address that today will return an ALLOCATED PA object (even though it is in fact assigned and in use) but after the implementation of 2023-04 will return an AGGREGATED-BY-LIR object, then we consider that the assignment coverage has increased.
But the End User details will be completely lost within that amorphous block.
We believe this concern has been addressed in the following 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/0139...
Not even the assignment boundaries can be deduced.
As mentioned in the proposal text itself, we did not see any independent justification for making the assignment-size attribute mandatory in IPv4, as its use in the calculation of the HD-ratio in IPv6 is not applicable. That said, if you or anyone else in the working group can identify and clearly articulate an independent justification for making the assignment-size attribute mandatory in IPv4 too, then we will certainly give that due consideration and possibly amend the proposal accordingly.
Many other LIRs may well anonymize their future or even already existing assignments by removing all references to the End User's identity and contact details. This may be done at the request of the End User. Or it may be done because the LIR has adopted a policy of not entering any details of their customers (End Users) into a public database. I have spoken to LIRs who have made it clear that it is already their policy regardless of current RIPE address policy requirements. They consider it commercially sensitive data.
We believe these concerns have been addressed in the following 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/0139...
There are technical solutions to mitigate this but again no one will talk about the database.
We assume you refer to improving the RIPE database technology here, which we have answered earlier on in this message.
2023-04 would provide these LIRs a less labour-intensive option to register such assignments. Whether or not they would avail themselves of the new option is of course an open question, but it seems clear that something has to be done if the current trend towards less assignment coverage in the database is to be reversed.
Less labour intensive by dumping the detail. This is about eliminating a problem rather than solving the problem, again because no one will talk about technical solutions. You cannot define a trend based on two measurement points. I agree something does need to be done to get more LIRs complying with RIPE policies. But changing the registration rules so that more people appear to follow them is not the way forward.
We believe the concerns about «dumping the detail» and «changing the registration rules» have been addressed in the following 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/0139... As for the «technical solutions» part, we assume you refer to improving the RIPE database technology, which we have answered earlier in this message.
Taking into account the current policies and procedures, we suspect that the information about the End Users that LEAs can obtain directly from the RIPE database is inserted there voluntarily in the first place.
Or because some LIRs have correctly interpreted the current policy.
We do not believe that interpretation to be correct, as noted in the following 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/0139...
It is a good idea to align the IPv4 and IPv6 systems of registration 'where appropriate'.
Agreed.
But maybe copy and paste without due consideration is not the best way to do it.
We believe we have given this due consideration prior to submitting the proposal. We have looked at how AGGREGATED-BY-LIR is being used in IPv6 (it appears to be popular amongst LIRs as there are almost 60k such objects in the database) and contrasted this with how there is an ongoing challenge with LIRs not registering their IPv4 assignments at all (cf. ripe-767 section 6.1.2). We truly believe AGGREGATED-BY-LIR strikes a good balance here, otherwise we would not have submitted our proposal.
There are differences. In those "many years" of aggregating IPv6 assignments not much of the internet was using IPv6. So it is not a valid argument to say there have been no problems with aggregating IPv6 over those "many years" so it must be OK. As more of the internet moves to IPv6, maybe we will start to see the problems that have been insignificant in the past.
IPv6 is extensively used nowadays, yet so far we have not seen anyone describing any problems caused by AGGREGATED-BY-LIR in IPv6 (much less attempt to fix them). If there truly were any problems with IPv6 AGGREGATED-BY-LIR, we would have expected them to manifest by now. We have not seen any reason to expect that IPv4 AGGREGATED-BY-LIR would be any more (or less) problematic than IPv6 AGGREGATED-BY-LIR.
Maybe we will need to expand the IPv6 registration of assignments to match the current IPv4 policy.
That is certainly something the community could do if it wanted. That would not be our preferred approach, though, as we fear this might import the problem of LIRs not registering assignments (cf. ripe-767 section 6.1.2) from IPv4 into IPv6, do nothing to help with the labour intensiveness of keeping the RIPE database up to date in highly dynamic environments (rather it would introduce or aggravate that problem in IPv6), as well as leave us with a major headache about what to do with the ~60k invalidated AGGREGATED-BY-LIR inet6num objects.
Again there are technical solutions here that no one will talk about.
We assume you refer to improving the RIPE database technology here, which we have answered earlier on in this message. Best regards, Jeroen and Tore