On Fri, Jun 5, 2015 at 2:04 PM, John Curran <[email protected]> wrote: > On Jun 5, 2015, at 1:36 PM, William Herrin <[email protected]> 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 ................ [email protected] [email protected] Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
