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


-- 

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

Reply via email to