Re: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published(Policy for Inter-RIR Transfers of IPv4 Address Space) (Tore Anderson)
Back in December, I suggested that the wording be changed from ?LIRs? to something more generic. The rationale was that if the policy explicitly refers to LIRs only, this will prevent inter-region transfers of PI address space held by non-LIRs, even if the IPv4 policy is amended to allow for in-region transfers of PI addresses.
The proposer responded: ?I am quite willing to change the wording from LIR's to Organizations if all agree?. I saw no objections, but version 2.0 still refers to LIRs specifically. So I'd still like to see this changed.
That said...
I support the idea of allowing inter-region transfers in general as long as the marginal cost of doing so is reasonably low, so I feel a bit bad about this, but: I do *not* support this proposal.
The reason for this is that inter-region transfers are being used as an argument against proposal 2013-03, see:
http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-March/007757.h...
My view is that if the cost of allowing for inter-region transfers (specifically in a way that is compatible with ARIN's policy) is to uphold the need bureaucracy and operational overhead relating to assignments for all RIPE region LIRs, then the marginal cost is not reasonably low, but unacceptably high. If it's an either/or situation between 2012-02 and 2013-03, I'm firmly in the 2013-03 camp. I elaborate on why here:
http://www.ripe.net/ripe/mail/archives/address-policy-wg/2013-March/007764.h...
This issue might be resolved by having 2012-02 add some text that upholds the need principle for transfers coming in from regions that demand it (read: ARIN), or for the recipient LIRs of such transfers overall. I have no suggestion on exactly how this text could look like, I'm afraid. I suspect the proposer would have to discuss it with ARIN staff in order to get confirmation that any proposed text does indeed satisfy their definition of ?needs-based general number resource policies?.
Tore
Tore, I agree with all you say, and in fact, the more open and inclusive the process, the better. The problem I ran into in trying to include PI space and end user space in inter-Regional transfers, is that it is not included in intra-regional transfers, and to change 2012-02 to include more, I would have to open a larger kettle of fish. So I chose to keep the scope narrow for now, thinking that the scope could be widened for all assignment types later. The warning that no needs justification in the RIPE region will give cause for ARIN to not allow inter-RIR transfers from ARIN to RIPE does not hold water. Say ARIN is giving out new IP's that will shortly be traded to RIPE and monetized, if RIPE does not have a needs justification checkpoint. That implies that ARIN has no confidence in its own needs justification system for new IP's. The counter point is that there are many address holders from, say the 1990's, who want to monetize and they didn't just get IP's and they still have their IP's exposed to that same needs justification on their buyers (ie. the wrong party, it's the sellers who are supposedly in the wrong). Needs justification is supposed to be on the part of the buyer, but as I understand it, this ARIN argument is that needs justification is needed to prevent the seller from getting away with IP theft. RIPE needs justification on the buyer will not prevent a new IP recipient in the ARIN region from selling its IP's to RIPE. The needs justification argument fails in this case. Needs justification arguments in the past were that buyers of IP's had to prevented from stockpiling and cornering the market. I guess the proponents of this theory have realized that cornering the IP market could be like cornering the silver market. http://en.wikipedia.org/wiki/Nelson_Bunker_Hunt So if there is no argument in favor of needs justification to prevent sellers from cheating, and no argument to prevent buyers from cheating, Tore's idea must be a good one. Still, +1. Sandra
participants (1)
-
sandrabrown@ipv4marketgroup.com