[ncc-services-wg] 2023-03 Voluntary Transfer Lock

Hi Peter



On Fri, 19 May 2023 at 10:36, Peter Hessler <phessler at theapt.org> wrote:
>
> I support 2023-03 Voluntary Transfer Lock.
>
> This is a good option for all members to have available.  Since it is
> voluntary, and has the same authority requirements as transfers,

Interesting comment. So both a transfer and a lock can be authorised
in the same way, but both cannot be applied.

> I feel
> there is minimal risk that this will be inappropriately used.  I also
> feel that we should _not_ unduely delay acceptance of this policy, even
> if we wish to propose another policy on this topic.  Crucially, the very
> first sentence of:
>  https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfers-in-the-ripe-ncc-service-region
> gives us all of the authority needed:
>
> """All resource holders in the RIPE NCC region can transfer resources in
> accordance with RIPE policies."""

No it doesn't. "policies" is plural. If this is approved we will have
two policies relating to transfers and they DO conflict.

>
>
> Furthermore, I disagree with Denis that there is a conflict between
> policies.

I think we have different opinions :)  In the end the only opinion
that matters is that of the legal team. Let me add some more points
for them to consider with examples.

> This policy is clearly intended to carve out an exception,

'Intention' is a very interesting concept when we talk about policies.
It is an abstract concept unless the wording of the policy very
strictly incorporates the intention in the wording. I am in a minority
in the RIPE community. I am a native English speaker. I am also an
analyst who is quite good at using and understanding the, sometimes
deep, meaning of English text. Let me give you an example of (failed)
policy intent.

During the run out of IPv4 there was a policy implemented to only
allow 1 allocation per 1 LIR. There was LOTS of discussion about the
intention that the last remnants of IPv4 should be used for new
entrants into the industry who wanted to operate as an LIR and offer
LIR services to customers. They needed to have some IPv4 address space
to operate these services. There was a CLEAR INTENTION to keep these
last bits of IPv4 for this purpose. However the wording of the IPv4
allocation policy did not incorporate this clear intent. So what
actually happened? Investors moved in, who had the financial resources
to open large numbers of LIRs, and literally drained the pool. The
'intention' was completely ignored by all parties as it was not
reflected in the wording of the policy. I should point out that in
this example no one violated any policies. The policies were just
poorly written. But it nicely illustrates the importance of the
wording of policies. Something that few people pay much attention to.

The text of this policy proposal makes no mention of being an
exception to the transfer policy. As with the address policy, this
intention is therefore irrelevant.

> and it is very specific in describing how.

Sorry but it is anything BUT specific in this area. Let me illustrate
this with another example.

Suppose we approve this policy proposal. We have one policy that
describes how to transfer a resource and another separate policy that
describes how to block the transfer of a resource. Let's look at how
this might play out in practice. An LIR holds an allocation that is
not covered by any of the restrictions mentioned in the transfer
policy. If this LIR was to request a transfer and provide the
appropriate documentation the RIPE NCC MUST implement the transfer. If
they refuse they are violating RIPE policy. Now suppose this LIR
invokes this transfer block policy and provides any necessary
documentation. The RIPE NCC MUST implement a block on transferring
this allocation otherwise they are violating RIPE policy. Now this LIR
requests a transfer of this allocation. What does the RIPE NCC do?
Forget about 'intention'. If there is a legal challenge in court, what
matters is what the policies actually say. Intention is subjective and
open to interpretation. If all the right documentation is provided for
the transfer, we have a transfer policy that says the RIPE NCC MUST
transfer the resource otherwise they are in violation of policy. We
have a transfer block policy that says the RIPE NCC MUST NOT transfer
this resource otherwise they are in violation of policy. The RIPE NCC
is put in the impossible situation where they have to make a judgement
and either way they violate a policy. We have never had a situation
before where 2 or more policies directly contradict each other. This
is a first. The judgement the RIPE NCC would be forced to make may be
open to a legal challenge in court.

There is no way to solve this conflict if we have two separate
policies. We can mitigate the problem by adding a clause in the
transfer block policy saying that in the event of a conflict with the
transfer policy the transfer block policy takes precedent. This would
also be a first. I don't think we have ever had a situation where one
policy is allowed to override another existing policy. We may also
have to amend the transfer policy by adding an exception that allows
the transfer lock policy to override this policy. Do we want to set
these precedents when there are viable alternatives? Some people may
object to this policy proposal, myself included, because we don't want
to set these precedents.

I really do not understand why so many people want to go down this
path. So many problems, so many precedents and there is no need for
it. We have a transfer policy. That policy has a section for
exceptions to transfers. A transfer block is a simple extension to
those exceptions. At the end of Sander's email he comments that
complex problems can have a simple solution that is wrong. Complex
problems can also have a simple solution that is right. As for timing,
the chairs of the services WG have started a new discussion phase of
this policy proposal. That effectively takes us back to the start of
the PDP process. To propose an update to the existing transfer policy
to include a block as an exception will take the same time to
complete.

It makes absolutely no sense to me to create a new policy that
conflicts with an existing policy, with all the complications that
creates, when a simple addition to the exceptions of that existing
policy is the clear way forward.

Perhaps another question this whole discussion raises is, what is the
legal status of a policy? Everyone assumes the RIPE NCC must follow
RIPE policy. Is that actually the case? Is that written into the
articles of association? If the RIPE NCC violates RIPE policy can that
be legally challenged?

In case I wasn't clear, I oppose this policy proposal.

cheers
denis
co-chair DB-WG


>
> -peter
>
> --
> There are no data that cannot be plotted on a straight line if the axis
> are chosen correctly.
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/