Hi Jan, Thanks for your input.
I don't see how this proposal solves the issues it claims it is introduced to solve. It rather seems to guarantee that information in the database will increasingly become stale. This policy proposal is technically only about inetnum objects and how far the LIR needs to specify (sub-)allocations in the RIPE DB. All the other information for abuse e.g. is already mentioned in the RIPE Database Terms and Conditions<https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms> in article 6.2 and also Abuse Contact Management in the RIPE Database policy<https://www.ripe.net/publications/docs/ripe-705>. Also if the LIR doesn’t need to spend time creating unnecessary objects they are probably more willing and also have more time to focus on the information that is more relevant. Also, the new address policy says the following even when something similar is also mentioned in the Terms and Condition and in the Abuse Contact policy "LIRs are responsible for the address space that they received by the RIPE NCC and must ensure that the registration data (range, contact information, status, etc.) in the database is maintained correct at all times and that operations such as abuse handling can be performed efficiently." So when an LIR not updates the information and let it get stale, they would handle against the policy. "One of the main reasons for registering IPv4 PA assignments was that LIRs could show their use of IPv4 and thus justify the request for an additional IPv4 allocation from the RIPE NCC. However, this requirement has become obsolete since the RIPE NCC ran out of IPv4 addresses in 2019." This merely means that this particular reason is no longer relevant for IPv4 addresses. "The application of IPv4 assignment registration policies in the RIPE Database is inconsistent. Some resource holders flood the database with tiny assignments (e.g. assignments for individual IP addresses), while many others do not register any assignments." This proposal does nothing to resolve the perceived database inconsistency, there is no proposed cleanup of current database entries. "This proposal is in line with the data consistency and data minimisation principles (as defined in the DBTF report [3]: * Data stored in the RIPE Database should be adequate, relevant, and limited to only what is necessary. * It is recommended that resource registration requirements are applied consistently." This proposal does not adequately describe this. What your thinking is missing or could be improved to adequately describe it? "Reduce the risk of LIRs registering personal data in the public database for no longer beneficial administrative/policy reasons." This is a red herring. If this was the goal of a proposal, why not propose minimizing the amount of personal data, by e.g. restricting the use and publication of personal names and personal e-mail addresses? "More flexibility: LIRs can choose for themselves which information they think is necessary to document and which is not, making it easier to adapt to different situations." This appears to be the core and only real argument for the proposal. The core reason is indeed for more flexibility for the LIR. But I think it is also good to note the side benefits/drawbacks of changing the policy for a complete picture. Kind regards, Jeroen
-- 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
