[arin-ppml] ARIN-PPML 2015-2

[William Herrin]

On Fri, Jun 5, 2015 at 2:04 PM, John Curran <jcurran at arin.net> wrote:
> On Jun 5, 2015, at 1:36 PM, William Herrin <bill at herrin.us> wrote:
>> So you can tell us the draft exceeds policy and impinges on ARIN
>> business procedure? You've suckered folks into that game one too many
>> times. Tell me the words you'd accept as requiring transfer
>> reciprocity and compatibility go beyond lip service and I'll advance
>> those words.
>
> Bill -
>
>    As always, I’m happy to aid you in policy development if you need
>    assistance.  With respect to NIR policy compatibility, is your your
>    expectation that it has to allow outward transfers unconditionally,
>    or simply allow the potential for outward transfers subject to any
>    other conditions, e.g. payment of processing fee, signing of an
>    agreement, etc?

Hi John,

Call it the transfer GPL: I ask that the receipient registry's
outbound transfer policy be little more onerous than our own, but at
the same time sufficiently diligent as to prevent addresses from
eventually landing at a registry which either directly prevents
outbound transfers or engages such onerous practices as effectively
prevent outbound transfers.

That line has a gray zone to it, to be sure, but practices like making
out-transfers illegal are rather obviously to one side of the line
while charging a nominal processing fee is rather obviously on the
other.

>  Do your require and/or allow enforcement of the
>    condition that the source address holder must not have received a
>    block within a certain time frame (if contained within NIR policy)

The key thing is that each transfer in a sequence should comply with
the rules of every registry in the sequence, not just the two
registries involved in that particular step. If ARIN requires that the
receiving registry also permit global out-transfers then no registry
in the sequence may operate under contrary restraints.

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.

The requirement is that "key" paragraph. The long timer is one
mechanism which contributes to meeting the requirement.


>    Does the time period have to match those in the ARIN policy
>    presently and/or stay in alignment with ARIN’s at all times?

If they employ a cooldown, its details (including length) should
render it effective at disrupting sequences which use multiple
transfers to evade one or more of the registries' transfer rules.

>    Post-transfer, dd you require the NIR to make any source entity
>    ineligible to receive  future sources via allocation and/transfer
>    for some period?  Does the period have to match ARIN’s present
>    and/or ARIN’s future ineligibility period?

The post transfer requirements should have the effect of preventing a
sequence of transfers from thwarting the requirement that the
addresses not be transferred to a registry where out-transfer is not
permitted.

The whole playing field must be level, not just the part between here
and the 30 yard line.

I would set hard requirements on -how- they achieve that effect only
if there's no other practical way to assure that they -do- achieve
that effect.



>    If you answer the questions above, I can craft text that should
>    require NIR transfer reciprocity and compatibility to the level
>    that you desire.

Answered, and I stand by to refine and clarify as needed.

Regards,
Bill Herrin




-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>