Hi Gert, Thank you also for your feedback.
This seems to be very similar to the pre-proposal sent by Jeroen in May, which did not meet overwhelming support. Like, I was highly sceptical, and had a sub-discussion with James about the suspected intent, and nobody spoke up in favour of going this way. I tried to update the policy on the feedback that was given by the few people on the mailing list and at RIPE84. What I understand as feedback was there shouldn’t be a difference in own usage or if it is used by a third party and the /25 problem is a database issue. This formal proposal has some changes to the pre-proposal, but I can still not support the motivation - one of the fundamental pillars of RIPE address policy is "documentation", so argueing with, quote, "unnecessary efforts by LIRs to register IPv4 prefixes and by the RIPE NCC to ensure that LIRs complied with the policy" will meet very strong resistance from side. The proposal tries to aim for the extra work that needs to be done for making allocations in the RIPE DB. So it is just about the allocations and not about other information in the RIPE DB. I can imagine now you point it out, that the word choice could meet strong resistance. Would you maybe have an alternative for it? If we want to do away with registration requirements because we think that knowing the holder of an address block is less important nowadays, then say so. But "the inconvenience of following the policy" is a very bad reason to do away with it. Nowhere is concluded that knowing the holder of an address block is less important nowadays. In the end, the final responsibility is still at the LIR whereby this information is already in the database added by RIPE NCC itself. Next of that, it is still obligated (as the Terms and Conditions<https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms>/Abuse Contact Management in the RIPE Database policy<https://www.ripe.net/publications/docs/ripe-705> specifies) to put in enough information for efficient abuse handling for example. Also, the inconsistencies show that in practice not all information is added like the rules are telling. So at the moment, the policy is out of sync in comparison with what happens in reality. We have three options for this situation. - One way we stronger enforce the current rules. - The second one is to not do anything and keep the rules out of sync in comparison with reality. - Or we can change the policy to what is already in real life happening In my opinion, I think in this case it would be better to go for the 3rd option. It is better to focus on important information like the right contact information than if someone didn’t specify enough information about how their IPv4 prefix reservation is for their network. Also, I think the bigger majority of the LIRs are more than willing to put enough information in the database to make sure everyone can get the information they need like in the case of abuse. LIRs that outsource the IP space to third parties also benefit from having the right information. What is left is a really small group of LIRs that don't keep to the rules. With this policy change, I don’t see any difference in effect in comparison with writing down the wrong information. Next of that, this is only about inetnum objects and not about contact information. The second rationale is "there is too much stuff in the DB that should not be there" - since this was put in voluntarily by over-eager LIRs (as it seems), I (still!) do not see how changing the registration from "mandatory" to "voluntary" would change that. With changing from mandatory to voluntary we make sure that the LIR doesn’t get obligated to fill in repetitive information. I think having a BCP document that explains to LIRs what the community expects to see in the RIPE DB ("for a netblock that has /32s assigned to private end users, documenting the block only is considered better than having end user data in the RIPE DB", and stuff like that) is a much more useful way forward with perceived inconsistency between the way LIRs handle the existing lack of guidance in this respect. A BCP would maybe help indeed. But even with the courses and certifications that are already available, there are still LIRs that don’t follow this guideline and find a more suitable way for them to document stuff. I don’t think that stronger enforcement is the right way of pushing LIRs to follow rules exactly that are for them not practical. Also, I think no one is waiting for the extra resources RIPE NCC would need to enforce this. Personally, I think there is enough space to create the freedom for the LIR to choose what is suited best for the LIR itself. So there is space for changing the rules to what is already happening in practice. We can also try to think about a lot of situations different LIRs are facing and create a ton of rules for it with exceptions and all other stuff. But I think that just a guideline to "document what is needed” for inetnum objects is much more practical and saves everyone a bunch of overhead. Technically, the "new policy text" wouldn't work the way it is written - it says "Registration is the final step in making an allocation", but the sentence before that says "... not mandatory". Now what? Also when the policy changes is still the registration the final step. The only difference is that the LIR can choose what to register for inetnum objects. But in the end, the IP block is already registered by RIPE NCC in the database, and also the right contact information still needs to be filled in. 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
