On 01/11/2013 21:49, Sander Steffann wrote:
Please don't confuse things like this. Option 2.6 is only there so that we don't cripple the database by taking away things that are already there...
There's no confusion: I'm aware of what I'm suggesting.
This policy proposal builds the foundations for legacy resource holders to work together with the RIPE NCC, although legacy resource holders cannot be forced into an agreement: The legacy resource holders had their resources before the NCC started, and the NCC assumed responsibility for maintaining the database for legacy address space. The NCC has an obligation to the community (not only to its members) of running a correct registry.
yep, agreed completely.
Option 2.6 recognises that: legacy resource holders that don't want to participate don't get any rights to new services, but the registry will be maintained.
I've addressed the issue before. The root of my objection is that there is no quid pro quo, and this proposal formalises this situation in such a way that it will not be possible to change it in future. Because of the way that the PDP works, any future attempt to change this situation will be shot down. So in essence, LRHs who opt for or fall into section 2.6 and decide that they aren't going to bother to fund the services they use, will be rewarded for doing so by being given free service in perpetuity. This is an objectively unfair proposition - namely it lacks quid pro quo, one of the universally accepted cornerstones of a good quality terms-of-service arrangement. But the proposal is fixable within the terms that we all agree on, namely that the registry accuracy is given highest priority.
- Force legacy resource holders to enter into an agreement? That is legally not possible because the RIPE NCC never provided the resources to them and cannot now claim to have authority over them.
- Refuse to cooperate with legacy resource holders? Don't provide any services to them? That would mess up the registry that the NCC is supposed to maintain for the community (not just its members)
- Work with legacy resource holders that want to participate, and do the minimum (keep the registry up to date but nothing else) for those that don't? That is exactly what 2012-07 is doing...
I'm proposing that the RIPE NCC lets LRHs update and maintain the registry info for their inetnums, but for those organisations who by default or by choice fall into category 2.6, that (after due effort from the RIPE NCC to engage with them) if they continue to decline to pay for registry services that they lose some services, e.g. reverse dns and/or route: objects for those inetnums. This suggestion is made on a payment for services basis. The RIPE community can continue to acknowledge that RIPE policies do not apply to legacy resource holders, but if these LRHs wish to continue to use the full range of registry services, they will need to pay the RIPE NCC for them. Neither RIPE NCC nor the RIPE community make any claims to the resources in this way, nor is the holder stopped from using the resources in any way they want. This establishes a reasonable balance between the rights of the LRHs and the requirements of the RIPE NCC to provide accurate registry services and operate in a fiscally responsible manner which is kept as objectively fair as possible. Given the precedent of the RIPE NCC in charging €50 per resource for PI address blocks, I doubt if the figures involved are going to be large. I'm aware that this option is unpalatable to some people because no-one likes to have to pay money where they didn't have to before, but some realism would help here: the amount of money we're talking about is going to be vanishingly small, and it is not unreasonable to expect people to pay for services rendered. Quite the opposite, in fact: it is unreasonable to expect the RIPE NCC to provide services for free forever, funded by the NCC membership. Incidentally, I apologise for mixing up certification in my previous email. You're correct that certification can only occur for those organisations who choose options 2.1 through 2.4 and establish a contractual chain to the RIPE NCC. Nick