This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2023-04 Are anonymised assignment objects valid?
- Next message (by thread): [address-policy-wg] 2023-04 Are anonymised assignment objects valid?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sander Steffann
sander at steffann.nl
Mon Oct 2 18:08:32 CEST 2023
Hi, > I think I mostly agree with Nick here and I feel like Tore is a bit > dismissive of the concerns raised by denis. > > I don't really feel that strongly about this policy proposal in itself > but I do now see that it is a significantly larger change than Tore > suggests that it is. > I wouldn't be surprised if more people who have said "+1" to this > proposal did so without realizing that it's not such a minor change. +1 to that! Guilty person right here :) > As such, I really think that there needs to be more discussion about > this in the context of changing a meaningful part of the policy. I totally agree. This is a change that we have to take consciously, not as a side-effect of a different idea. I personally have no problem with this change. I recognise the importance of documenting every end-user’s contact details, as end-users were often actively involved in running their network. But in this day and age of outsourcing, the value of the information is much lower than it used to be. I’m not saying that there is no value anymore! There are many cases where resource holders are actually network operators with relevant information in the DB, but I don’t think that changing the policy will cause them to suddenly stop creating DB objects. And for those who don’t *want* to document things, they have already found ways around that in the current implementation of the policy. I think the best way forward would be: - encourage operators to document *useful* contact info (a SHOULD) - don’t require what we don’t/won’t/can’t enforce (no MUST) - realise that the current internet is not the internet that this DB was designed for - align IPv4 and IPv6 requirements/standards where possible So: - the ALLOCATION objects will always have validated information enforced by the RIPE NCC - objects below that are for delegating responsibility and contact points - if an LIR wants to keep/assume responsibility, very few additional DB objects are needed I realise there are quite a few potentially controversial statements here, please use this as a thought provoking discussion point ;) Cheers! Sander
- Next message (by thread): [address-policy-wg] 2023-04 Are anonymised assignment objects valid?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]