- address-policy-wg - mailman.ripe.net

Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by David Monosov 21 Apr '14

21 Apr '14

Dear address-policy-wg, With such a policy in place, IP address broker needs to offers potential IP space buyers only a marginally lower price than the cost of being a LIR for the expected duration of use of the IPv4 PI space in question (and requesting this IP space from the last /8 or realizing an inter-LIR PA transfer) in order to create a perverse incentive for IPv4 address buyers to line the pockets of IP address brokers instead of stepping up and becoming members of the RIPE NCC. This policy appears to fail the most basic economic incentive test, and will in practice create a secondary and desirable 'asset class' from which IP transfer brokers benefit considerably more than the community as a whole. To deconstruct the arguments which purportedly support this proposal: a) "Currently the policy for PA and PI space isn’t the same and people don’t understand the difference between the various types of IP Space." Ignoring that this is a superfluous argument which goes in the face of nearly two decades of policy, this appears to argue that letting PI space be sold would somehow eliminate this distinction. This, of course, is disingenuous. If this is indeed the goal, a policy should be introduced to allow PI space to be converted into PA space and assigned to a LIR - this will enable its "transferability" and eliminate many of the concerns raised above by ensuring that all holders of "transferred" IPv4 space are first rate LIRs who contribute financially toward the operation of the RIPE NCC and fall under all obligations imposed on such. b) "There is already some trade in PI space, however it is not documented or registered, which doesn’t help to keep the registry updated." This is also disingenuous, as every IPv4 PI space holder has a contract with the sponsoring LIR (and indirectly, with the RIPE NCC). This LIR can, and should, regularly verify and update these details in cooperation with the registrant. c) "A lot of current PI space holders are more than happy to have their assignments re-assigned to other parties, but due to the current policy it is not possible. The same goes for the documentation provided to the RIPE NCC during mergers or acquisitions of infrastructure with PI space. Due to the current policy, some changes in company names are marked as mergers or acquisitions when they are actually a transfer of IP space with added documentation to make it look like an merger or acquisition of infrastructure." If a legitimate transfer has occurred as part of legitimate organizational restructuring, there is no disincentive to document it. The disincentive only exists if the registrant fears the transfer's legitimacy may be questioned, which is exactly the intention for non-transferable, end-user assigned PI space. Such transferred allocations could, and should, per current policy, be simply reclaimed. d) "We want to have an open and honest communication to the RIPE NCC from the community and we need to make sure that the registry is up to date, without having to fluff up the procedures, bend the rules and truth in communication to the RIPE NCC to be able to transfer the IP space." Alternatively, elements which "bend the rules and truth" could be identified, and, within reason, have their resources reclaimed. Certainly, such enforcement can never be perfect - but speed traps also do not catch 100% of speeding cars. With a few documented instances, this would create tremendous uncertainty and disincentive to engage in such practices from the buy side, as it will mean that any resources acquired in this manner may very suddenly get written off. e) "The goal of this policy change is to get PI space on-par with PA space in respect to the ability to transfer it." See (a). It seems very disingenuous to make PI and PA "equal for purposes of transferability" but maintain the distinction in all other aspects. To summarize, I strongly object to this policy in its current form. I concur that the mobility of IPv4 PI space toward those who value it most is desirable - on the condition that this mobility occurs as part of a wider reform to eliminate the distinction between PA and PI status of IPv4 resources. This should result in equitable burden for all resource holders toward the RIPE NCC instead of lining the pockets of IP address brokers by helping address space speculators which presently hoard IPv4 PI assignments against policy realize profits at the expense of the community. -- Respectfully yours, David Monosov

5 7

Policy Proposal Implemented: 2013-03, "Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text"
by Marisol Estrada 17 Apr '14

17 Apr '14

Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2013-03, "Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text". In accordance with the new policy, the RIPE NCC will no longer require LIRs to complete a forecast-based documentation of need when requesting /22 IPv4 allocations, when making assignments to End Users, or when requesting approval for IPv4 transfers. Accordingly, this also means that the "Assignment Window" is no longer applicable. As a result, we have updated the following request forms and supporting notes: - IPv4 First Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-608 - Supporting Notes For The IPv4 First Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-609 - IPv4 Additional Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-610 - Supporting Notes for the IPv4 Additional Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-611 Both the Provider Aggregatable (PA) Assignment Request Form and the Supporting Notes for Provider Aggregatable (PA) Assignment Request Form have also been removed due to this change. RIPE NCC members can still access the list of their past assignments approved by the RIPE NCC as well as their Assignment Window history, which is available in the "Archive" section of the LIR Portal. The IP Analyser functionality of the LIR Portal has been changed, as explained at: https://labs.ripe.net/Members/AlexBand/modifications-to-the-ip-analyser-to-… The archived policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2013-03 The updated RIPE Document "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is available at: http://www.ripe.net/ripe/docs/ripe-606 Kind regards Marisol Estrada RIPE NCC Registration Services

1 0

Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by Richard Hartmann 15 Apr '14

15 Apr '14

I am afraid that I didn't have time to review the text in-depth yet, but I agree with the general direction this is going. Richard

1 0

APWG agenda for RIPE 68, first draft
by Gert Doering 14 Apr '14

14 Apr '14

Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Warsaw in the following time slots: Wednesday, May 14, 09:00 - 10:30 Wednesday, May 14, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Marco Schmidt, NCC RS - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE67 2013-03 Post-Depletion Reality Adjustment and Cleanup (consensus, policy) 2013-05 No Restrictions on End User Assignments in Intra-RIR Transfers (consensus, policy) 2013-06 PA/PI Unification IPv6 Address Space (withdrawn) - brief overview over new proposals (if any) E. On Personal Identity - for internet resources registered to natural persons, what level of identity verification does the community require from the RIPE NCC? - with (hopefully) lots of input from the Anti-Abuse WG, on what they see necessary - results will be presented to NCC services WG, as this is important for the "due dilligence" considerations of the NCC D. Feedback From NCC Registration Service - Andrea Cima (NCC RS) (+ discussion with the group) [might be moved to "after coffee break" if we run out of time] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back G. On SHOULDs and MUSTs - RFC 2119 language in RIPE documents followup to RIPE 67, findings by Marco Schmidt and Jan Zorz F. Discussion of open policy proposals 2012-02 Policy for Inter-RIR transfers of IPv4 Address Space (which will hopefully be restarted until then) 2014-01 Abandoning the Minimum Allocation Size for IPv4 (Carsten Schiefner) 2014-02 Allow IPv4 PI transfer (Erik Bais) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." Z. AOB

1 0

Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
by Rob Evans 09 Apr '14

09 Apr '14

> http://www.ripe.net/ripe/policies/proposals/2014-01 Overall I think this is a good thing, but I wonder if there is a reason for leaving 5.4 (minimum sub-allocation size) as-is? If we open the door to transfer prefixes smaller than a /24, should sub-allocation of them be prevented? The routing side of me, of course, might consider the alternative of clamping the transfers at /24 too, but perhaps that should just be left for consenting adults to negotiate between themselves. Cheers, Rob

11 26

report address policy violation
by Tom Norda 08 Apr '14

08 Apr '14

Hi: I know a RIPE member with an unused ipv4 /20 block not used in the last 2 years and i'm wondering if that's a RIPE community policy violation. I checked https://www.ripe.net/ripe/docs/current-ripe-documents/ripe-policiesbut i still have doubts if it is accepted or not. Best regards

2 1

Re: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by Tore Anderson 01 Apr '14

01 Apr '14

* Marco Schmidt > https://www.ripe.net/ripe/policies/proposals/2014-02 I think it makes sense to allow PI transfers, at least when taking into account that we already do so for PA. So I'm generally supportive of this proposal A few comments though: 1) The new policy says: «Changes to the original criteria must be documented in the RIPE Registry, or the assignment will no longer be considered valid». What exactly are the implications of this requirement? I am assuming that the «RIPE Registry» is not the RIPE DB; as the original criteria isn't documented in the RIPE DB to begin with. As I understand it, any criteria that somehow involves «operating a network» is a valid assignment criteria (cf. section 3.0.3), with no requirement for specifics. I'm thinking that it might be better to simply say something along the lines of an assignment being valid for as long as it is being used according to the policy, rather than worrying about the «original criteria» and how it possibly have changed. Most networks evolve and change over time; it wouldn't surprise me if a majority of assignments are now being used differently than originally documented in their associated assignment request form. That's not a bad thing though, is it? 2) Editorial: The new section 6.4 «Transfers of PI space» appears to me to be pretty much a carbon copy of section 5.5 «Transfers of Allocations» with a tiny bit changed here and there. Rather than duplicating all that text, would it not be better to move 5.5 out of section 5, and re-title and generalise it so that it applies equally to PI and PA? 3) The new section 6.4 speaks of «Non-approved transfers». Under which circumstances would a transfer not be approved, exactly? Do we really need this language anymore? (I'm regretting that 2013-03 didn't do away with it already. Oh well...) Tore

2 2

Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
by Erik Bais 01 Apr '14

01 Apr '14

> You can find the full proposal at: > http://www.ripe.net/ripe/policies/proposals/2014-01 Support +1 Erik Bais

1 0

2014-02 New Policy Proposal (Allow IPv4 PI transfer)
by Marco Schmidt 31 Mar '14

31 Mar '14

Dear colleagues, A proposed change to RIPE Document ripe-606, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-02 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 29 April 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
by Sascha Luck 29 Mar '14

29 Mar '14

All, On Mon, Mar 24, 2014 at 02:18:44PM +0100, Marco Schmidt wrote: >You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-01 > >We encourage you to review this proposal and send your comments to I don't think this proposal takes into account operational reality. The fact of the matter is, that there is a lower limit to what allocation size is operationally useful to a LIR (unless the routing community is prepared to accept /32s in the DFZ). Add to that the extra complexity of reverse delegating </24 zones that is mentioned elsewhere in the thread and the likely outcome is a mess. I think the better way to do this would be to: - retain the /22 min-alloc size until the last /8 is gone - possibly change the *transfer* policies to allow transfers of /24< x </22 - implement something like 2014-01 but with a min-alloc size of /24 when that happens - review after a year(?) with a view to whether any smaller allocation size is actually *operationally useful* to LIRs I do not want to go back to the not-so-long-ago days of having to concoct fiction in order to get a useful amount of resources out of the NCC. rgds, Sascha Luck

3 6