[arin-ppml] ARIN-PPML 2015-2

John Curran jcurran at arin.net
Mon Jun 8 17:09:01 EDT 2015


On Jun 8, 2015, at 1:55 PM, William Herrin <bill at herrin.us> wrote:
> Without a globally coordinated policy there are no transfer common
> requirements, just the combination of the requirements applied by each
> registry independently.

In addition, absent global coordination, the entire mechanism is dependent
upon ARIN; i.e. you can’t create a dependency on how another RIR will 
handle the resources subsequently, instead you have to presume that 
unless a given requirement is provided by the applicable policy for all \
possible future transfers, the requirement is not met.

For example - with globally coordinated policy, you can have something 
such as “resources recently transferred from another RIR must not be 
transferred to another registry not supporting this policy.”   Absent any
global coordination, ARIN must assess whether the submitted request
will allow resources to be transferred in any manner to a situation where
the specified requirements will not be met.

> I'm asking that the combined requirements of
> all registries in the sequence (combined, not common) be met at each
> step of the transfer sequence. In particular, the transfer should fail
> if the combined policies are self-contradictory.

One does not know the future transfers that might be submitted for a 
number resource block once out of the region, so that means applying 
the combined requirements for all registries before approved a transfer
to another region.  It also requires that ARIN interpret other registries
policy text in order to assess compatibility, not just with ARIN’s policies,
but with any other registry that could end up with the address block.

> An example: a transfer which involves both ARIN and CNNIC somewhere in
> the sequence should fail because ARIN requires transfer reciprocity
> while CNNIC refuses out-transfers altogether. Introducing additional
> transfer steps in the middle of the sequence should not make such a
> transfer possible.

Impossible to know if it involves ARIN and CNNIC up front, as It may
just be a request which is ARIN to APNIC for now, and CNNIC later.    

Do we disallow all transfers to APNIC on the presumption that any of the
address blocks might then be transferred to CNNIC?

>>> The cooldown timer resolves this by simply saying: there shall be no
>>> sequence of transfers leading outregion. You have to hold and use the
>>> addresses long enough that the next transfer is independent.
>> 
>> So is safe to presume that you wish a long hold timer for the common
>> transfer requirements?
> 
> Call it a long hold timer before the sequence is considered complete
> and a new transfer can start without considering the whole chain of
> registry policies.

How long for a timer?

>> To allow each registry its own approach to the problem than requires
>> that each registry review the approach used by the other and decide
>> if they will accept it, and then communicate that to the others.  This is
>> an (n)! situation
> 
> That sounds about right. With more than 3 or 4 registries in the
> sequence a transfer would be hopelessly complex, hence blocked.

Are you referring to a request to transfer sequentially through 3 registries, 
or the potential that a transferred block would subsequently be transferred 
at a later time via a policy not compatible with earlier registries and hence 
must be rejected now (unless we know the receiving registry only transfers 
to registries with compatible policies, now and in the future.

>> and does not appear practice (as opposed to simply
>> establishing a clear reference approach which can be readily and
>> independently confirmed.   Thoughts?
> 
> Clear reference approach = globally coordinated policy, yes?
> 
> Even if successful, that'd leave the problems with section 8.4 in
> limbo for an awfully long time, would it not?

It would take time, but would also provide a very clear outcome.  A non-
coordinated approach might “fixing 8.4” by breaking it until/if the stars 
align up at some future time.

Thanks,
/John

John Curran
President and CEO
ARIN



More information about the ARIN-PPML mailing list