2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space)
Dear Colleagues The draft document for the version 2.0 of the proposal 2012-02, "Policy for Inter-RIR Transfers of IPv4 Address Space", has been published. The impact analysis that was conducted for this proposal has also been published. The only change in the new version is: -modified the first sentence in the second paragraph of section 5.5, "Transfer of Allocation", in the RIPE Policy document ripe-582, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2012-02 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-02/draft We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 March 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC
Dear AP WG members, On Mon, Mar 04, 2013 at 02:46:03PM +0100, Emilio Madaio wrote:
The draft document for the version 2.0 of the proposal 2012-02, "Policy for Inter-RIR Transfers of IPv4 Address Space", has been published. The impact analysis that was conducted for this proposal has also been published. [..] You can find the full proposal and the impact analysis at:
https://www.ripe.net/ripe/policies/proposals/2012-02
and the draft document at:
https://www.ripe.net/ripe/policies/proposals/2012-02/draft
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 March 2013.
Let me remind you again that we need your explicit voice of support if you want to see this proposal implemented. (If you do *not* want that, an explicit voice of opposition would be helpful, too). "No response" is making our lives as WG chairs somewhat difficult - it will lead to "extention of the review period", and then after some more months to "asking the proposer to drop the proposal due to lack of support"... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi Gert, Opposed. I see this as potentially creating a good deal of admin overhead for the RIRs, which will impact all LIRs, while the upside will only be for those few who want to further commoditise Internet numbering resources. the relevant bits of the impact analysis are quoted below: "C. Impact of Policy on RIPE NCC Operations/Services Registration Services: It is very relevant to note that the implementation of this policy proposal will require a significant effort of co-ordination between the RIPE NCC and the other RIRs. It is unclear at the moment how much time and resources will be needed to fully implement the proposal. . . D. Legal Impact of Policy If this policy proposal will be accepted, the RIPE NCC will need to create appropriate legal procedures and template agreements in order for all parties to understand and agree on the preconditions and the consequences of the transfer in accordance with the provisions of this policy." -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel On Mon, Mar 11, 2013 at 8:47 AM, Gert Doering <gert@space.net> wrote:
Dear AP WG members,
On Mon, Mar 04, 2013 at 02:46:03PM +0100, Emilio Madaio wrote:
The draft document for the version 2.0 of the proposal 2012-02, "Policy for Inter-RIR Transfers of IPv4 Address Space", has been published. The impact analysis that was conducted for this proposal has also been published. [..] You can find the full proposal and the impact analysis at:
https://www.ripe.net/ripe/policies/proposals/2012-02
and the draft document at:
https://www.ripe.net/ripe/policies/proposals/2012-02/draft
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 March 2013.
Let me remind you again that we need your explicit voice of support if you want to see this proposal implemented. (If you do *not* want that, an explicit voice of opposition would be helpful, too).
"No response" is making our lives as WG chairs somewhat difficult - it will lead to "extention of the review period", and then after some more months to "asking the proposer to drop the proposal due to lack of support"...
Gert Doering -- APWG chair -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
* McTim
I see this as potentially creating a good deal of admin overhead for the RIRs, which will impact all LIRs
Having recently been told over dinner by an NCC employee something along the lines of «I don't think the RIPE Community quite realises how much effort goes into implementing policy changes», I find this worrisome as well. Especially considering that the Impact Analysis makes an explicit point out of it.
while the upside will only be for those few who want to further commoditise Internet numbering resources.
Can't say I agree with this. If I, having absolutely no agenda «to further commoditise Internet numbering resources», need to obtain IPv4 address space for purely technical reasons, a transfer is the only way to go about it these days. This proposal would increase the number of sellers I could buy from, which would be to my benefit. On the other hand, it would at the same time increase the number of buyers I would have to compete with, so it might well be a zero-sum game for me. Or maybe not. Difficult to predict, really. In any case, the cost (i.e., the administrative overhead) of this proposal may be justified if there is enough members that are actually interested in participating in the IPv4 transfer market in the first place. I think the implementation of proposal 2012-05 might provide valuable data in this regard. I'll stay on the fence about 2012-02 until than, at least. Another thing I'm curious about is how this proposal will impact transfers of legacy/pre-RIR/ERX space (if at all), how these are handled today, and if there's any interaction with 2012-07 to be considered. -- Tore Anderson
Hi, On Mon, Mar 11, 2013 at 06:28:55PM +0100, Tore Anderson wrote:
I'll stay on the fence about 2012-02 until than, at least.
I find this a bit hard to classify - is this a "support", "neutral" or "do not support today (but might at a later time)"? Gert Doering -- APWG -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
* Gert Doering
On Mon, Mar 11, 2013 at 06:28:55PM +0100, Tore Anderson wrote:
I'll stay on the fence about 2012-02 until than, at least.
I find this a bit hard to classify - is this a "support", "neutral" or "do not support today (but might at a later time)"?
My apologies. "neutral". -- Tore Anderson
On 11 Mar 2013, at 17:28, Tore Anderson <tore@fud.no> wrote:
Having recently been told over dinner by an NCC employee something along the lines of «I don't think the RIPE Community quite realises how much effort goes into implementing policy changes», I find this worrisome as well. Especially considering that the Impact Analysis makes an explicit point out of it.
Tore, the whole point of the Impact Analysis stage of the PDP is to help the community to avoid doing things that create unreasonable burdens on the NCC. Or invent policies which are unworkable/illegal/etc. In principle the community could pass a policy which instructs Axel to hand out €100 notes on Dam Square until the NCC is bankrupt or lease offices on the Space Station. So some sort of sanity check in the PDP is needed before policies are finally nailed down. Now it would be nice if that Impact Analysis could take place earlier in the PDP. But that's impractical. First, it could mean the NCC was "making policy". Which would be bad. Next, until a rough consensus forms around some policy proposal, it's not necessarily clear what that proposal's impact on the NCC (and beyond) is likely to be. Cool domain name BTW!
* Jim Reid
On 11 Mar 2013, at 17:28, Tore Anderson <tore@fud.no> wrote:
Having recently been told over dinner by an NCC employee something along the lines of «I don't think the RIPE Community quite realises how much effort goes into implementing policy changes», I find this worrisome as well. Especially considering that the Impact Analysis makes an explicit point out of it.
Tore, the whole point of the Impact Analysis stage of the PDP is to help the community to avoid doing things that create unreasonable burdens on the NCC. Or invent policies which are unworkable/illegal/etc. In principle the community could pass a policy which instructs Axel to hand out €100 notes on Dam Square until the NCC is bankrupt or lease offices on the Space Station. So some sort of sanity check in the PDP is needed before policies are finally nailed down.
Now it would be nice if that Impact Analysis could take place earlier in the PDP. But that's impractical. First, it could mean the NCC was "making policy". Which would be bad. Next, until a rough consensus forms around some policy proposal, it's not necessarily clear what that proposal's impact on the NCC (and beyond) is likely to be.
Hi Jim, I'm not quite sure what you're trying to tell me here, or what you think that I was trying to say earlier? I wasn't making any complaint that the Impact Analysis was posted too late, and I already know and agree with everything you wrote (except for calling the Impact Analysis a stage of the PDP, which it is not). The Impact Analysis says, quote, «It is very relevant to note that the implementation of this policy proposal will require a significant effort of co-ordination between the RIPE NCC and the other RIRs». What I was trying to say was: I agree, this is indeed "very relevant to note", and furthermore I find it worrisome - because I was not at all convinced that the IPv4 transfer market is actually large enough to justify a «significant effort». So I'd say that the Impact Analysis did exactly what it was supposed to do in this case, by pointing out an issue that I hadn't considered, so that I may make up a (hopefully) more informed opinion about the proposal than I could without it. That said, since posting my last message I also came across this presentation, which offers a sneak preview some of the transfer stats 2012-05 will give us: http://www.menog.org/presentations/menog-12/127-IPv4_Transfers-RIPE_NCC_Upda... Slide 10 seems to suggest there's been a total of 17 transfers in the last five months. That's *way* fewer than I expected, it does not make sense to me to instruct the NCC to undertake a «significant effort» to expand a so marginal service. Chairs: "do not support today". vh, -- Tore Anderson
On 11 Mar 2013, at 19:21, Tore Anderson <tore@fud.no> wrote:
I'm not quite sure what you're trying to tell me here, or what you think that I was trying to say earlier?
I thought you were talking about Impact Analysis in general rather than the specifics of 2012-02. Apologies for the confusion.
I brokered the first two Inter-regional transfers, both involving a sale of ARIN addresses to APNIC buyers. I shepherded the transaction through both RIRs in my role as a registered broker in both RIRs, and my impression was that the amount of extra work was minimal. There was some tweaking of a transfer template required, and after the initial transfer, the APNIC Whois record incorrectly referred to the addresses as having been part of the ERX process. That was quickly addressed, and the entire transfer process took about a week. Of course this extra effort on the part of ARIN and APNIC enriched me in my role as a broker, and if that's all it did, then McTim would have an accurate point. However my client, who had already received his maximum /22 from APNIC, was able to continue to grow, so he benefited. And the increased supply of addresses available in Asia as a result of the ability to transfer from ARIN has resulted in lower prices in the ARIN/APNIC market than in the RIPE market, where prices are higher. The inclusion of RIPE into the global market will lower prices due to increased supply, and this benefit will inure to all RIPE buyers. And of course many in Asia see it as a fairness thing, with ARIN having gotten the lion's share of addresses it is viewed as only fair that they have access to that ARIN abundance. http://www.circleid.com/posts/ipv6_transitional_uncertainties/ In this article, Geoff Huston asks the question: What's the level of risk that the differing environments of transition lead to significantly different outcomes in each region as the process of transition takes of a different momentum in different regions? And if this eventuates will we still have a single coherent Internet as a common asset, or will we find that market forces interact in unpredictable ways that create different outcomes in each region? One way to minimize the risk of uneven runout is to facilitate a global transfer market. I support the proposal. Regards, Mike Burns IPTrading.com -----Original Message----- From: McTim Sent: Monday, March 11, 2013 9:42 AM To: Gert Doering Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2012-02 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) Hi Gert, Opposed. I see this as potentially creating a good deal of admin overhead for the RIRs, which will impact all LIRs, while the upside will only be for those few who want to further commoditise Internet numbering resources. the relevant bits of the impact analysis are quoted below: "C. Impact of Policy on RIPE NCC Operations/Services Registration Services: It is very relevant to note that the implementation of this policy proposal will require a significant effort of co-ordination between the RIPE NCC and the other RIRs. It is unclear at the moment how much time and resources will be needed to fully implement the proposal. . . D. Legal Impact of Policy If this policy proposal will be accepted, the RIPE NCC will need to create appropriate legal procedures and template agreements in order for all parties to understand and agree on the preconditions and the consequences of the transfer in accordance with the provisions of this policy." -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel On Mon, Mar 11, 2013 at 8:47 AM, Gert Doering <gert@space.net> wrote:
Dear AP WG members,
On Mon, Mar 04, 2013 at 02:46:03PM +0100, Emilio Madaio wrote:
The draft document for the version 2.0 of the proposal 2012-02, "Policy for Inter-RIR Transfers of IPv4 Address Space", has been published. The impact analysis that was conducted for this proposal has also been published. [..] You can find the full proposal and the impact analysis at:
https://www.ripe.net/ripe/policies/proposals/2012-02
and the draft document at:
https://www.ripe.net/ripe/policies/proposals/2012-02/draft
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 March 2013.
Let me remind you again that we need your explicit voice of support if you want to see this proposal implemented. (If you do *not* want that, an explicit voice of opposition would be helpful, too).
"No response" is making our lives as WG chairs somewhat difficult - it will lead to "extention of the review period", and then after some more months to "asking the proposer to drop the proposal due to lack of support"...
Gert Doering -- APWG chair -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
All, I don't really have a horse in this race, tbh, but I am swayed by Tim's argument that it creates admin overhead for the RIRs with possible membership fee increases to the members while enabling resource traders to make a profit. So I'll register opposition to this proposal. cheers, Sascha Luck On Mon, Mar 11, 2013 at 01:47:11PM +0100, Gert Doering wrote:
Dear AP WG members,
On Mon, Mar 04, 2013 at 02:46:03PM +0100, Emilio Madaio wrote:
The draft document for the version 2.0 of the proposal 2012-02, "Policy for Inter-RIR Transfers of IPv4 Address Space", has been published. The impact analysis that was conducted for this proposal has also been published. [..] You can find the full proposal and the impact analysis at:
https://www.ripe.net/ripe/policies/proposals/2012-02
and the draft document at:
https://www.ripe.net/ripe/policies/proposals/2012-02/draft
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 March 2013.
Let me remind you again that we need your explicit voice of support if you want to see this proposal implemented. (If you do *not* want that, an explicit voice of opposition would be helpful, too).
"No response" is making our lives as WG chairs somewhat difficult - it will lead to "extention of the review period", and then after some more months to "asking the proposer to drop the proposal due to lack of support"...
Gert Doering -- APWG chair -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 11/03/2013 12:47, Gert Doering wrote:
Dear AP WG members,
On Mon, Mar 04, 2013 at 02:46:03PM +0100, Emilio Madaio wrote:
The draft document for the version 2.0 of the proposal 2012-02, "Policy for Inter-RIR Transfers of IPv4 Address Space", has been published. The impact analysis that was conducted for this proposal has also been published. [..] You can find the full proposal and the impact analysis at:
https://www.ripe.net/ripe/policies/proposals/2012-02
and the draft document at:
https://www.ripe.net/ripe/policies/proposals/2012-02/draft
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 March 2013. Let me remind you again that we need your explicit voice of support if you want to see this proposal implemented. (If you do *not* want that, an explicit voice of opposition would be helpful, too).
"No response" is making our lives as WG chairs somewhat difficult - it will lead to "extention of the review period", and then after some more months to "asking the proposer to drop the proposal due to lack of support"...
I'm worried by the wooliness of phrases such as "The Originating LIR and the IPv4 address space transferred are in compliance with the Originating Policy" I really don't know what this means and I see a world of pain unless it's clarified. What does "in compliance with" actually mean in this context? Nigel
I support this policy, but I'm concerned about how much cost/overhead it will cause on RIPE NCC and in the end us as LIRs. // Andreas Med vänlig hälsning Andreas Larsen IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Besöksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se Den 2013-03-11 13:47 skrev Gert Doering <gert@space.net>:
Dear AP WG members,
On Mon, Mar 04, 2013 at 02:46:03PM +0100, Emilio Madaio wrote:
The draft document for the version 2.0 of the proposal 2012-02, "Policy for Inter-RIR Transfers of IPv4 Address Space", has been published. The impact analysis that was conducted for this proposal has also been published. [..] You can find the full proposal and the impact analysis at:
https://www.ripe.net/ripe/policies/proposals/2012-02
and the draft document at:
https://www.ripe.net/ripe/policies/proposals/2012-02/draft
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 March 2013.
Let me remind you again that we need your explicit voice of support if you want to see this proposal implemented. (If you do *not* want that, an explicit voice of opposition would be helpful, too).
"No response" is making our lives as WG chairs somewhat difficult - it will lead to "extention of the review period", and then after some more months to "asking the proposer to drop the proposal due to lack of support"...
Gert Doering -- APWG chair -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 4 March 2013 13:46, Emilio Madaio <emadaio@ripe.net> wrote:
The draft document for the version 2.0 of the proposal 2012-02, "Policy for Inter-RIR Transfers of IPv4 Address Space", has been published. The impact analysis that was conducted for this proposal has also been published.
Just re-read this and thought that: "Such address space must not contain any block that is assigned to an End User" might cause a problem for those want to transfer space with the end user intact or even in some cases maybe just the end user. I know its out of scope, but was there logic behind this? J -- James Blessing 07989 039 476
Hi, On Mon, Mar 11, 2013 at 02:00:46PM +0000, boggits wrote:
On 4 March 2013 13:46, Emilio Madaio <emadaio@ripe.net> wrote:
The draft document for the version 2.0 of the proposal 2012-02, "Policy for Inter-RIR Transfers of IPv4 Address Space", has been published. The impact analysis that was conducted for this proposal has also been published.
Just re-read this and thought that:
"Such address space must not contain any block that is assigned to an End User"
might cause a problem for those want to transfer space with the end user intact or even in some cases maybe just the end user. I know its out of scope, but was there logic behind this?
Well, that's the "original" transfer policy - which compromised on "ok, we'll permit transfers, but only transfers of empty PA blocks!" Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 3/11/13 15:47 , "Gert Doering" <gert@space.net> wrote:
Well, that's the "original" transfer policy - which compromised on "ok, we'll permit transfers, but only transfers of empty PA blocks!"
That's exactly right. One of the joys of working through consensus is that you keep going until, well, you reach consensus or you give up. This is one (of several) limitations that got introduced into the original policy proposal in order to get everybody to agree. As this was the first transfer policy to get accepted, other regions had an opportunity to look at our train wreck and subsequently did a better job. Now if only there was a policy proposal out there to clean up the IPv4 policyŠ Best Remco van Mook Director of Interconnection, EMEA EQUINIX | 80 Cheapside, London, EC2V 6EE, United Kingdom E remco@equinix.com | T +31-6-11356365 HOW ARE WE DOING? <http://www.customersat3.com/csc/equinix> Please click here to Tell Equinix - We're Listening Equinix.co.uk <http://www.equinix.co.uk/> | Twitter <https://twitter.com/equinix> | LinkedIn <http://www.linkedin.com/company/equinix> | Facebook <http://www.facebook.com/Equinix> | YouTube <http://www.youtube.com/user/equinixvideos> This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
"Such address space must not contain any block that is assigned to an End User" Well, that's the "original" transfer policy - which compromised on "ok, we'll permit transfers, but only transfers of empty PA blocks!"
what if the buyer has contracted to support the sub-allocation? randy
Hi,
"Such address space must not contain any block that is assigned to an End User" Well, that's the "original" transfer policy - which compromised on "ok, we'll permit transfers, but only transfers of empty PA blocks!"
what if the buyer has contracted to support the sub-allocation?
The transfer policy explicitly says 'empty PA'. But in the case you describe it might be possible to do this through the mergers/acquisitions procedures because the buyer isn't buying address space but acquiring a part of a business. The NCC will probably look at such things case-by-case. And I might be wrong :-) Sander
what if the buyer has contracted to support the sub-allocation? The transfer policy explicitly says 'empty PA'. But in the case you describe it might be possible to do this through the mergers/acquisitions procedures
someone has a critical, very hard and slow to move (think dns or something), service in the middle of a chunk of address space they sell. the sales agreement does something kinky to make that service stay up. this is not a merger. randy
Hi Randy,
what if the buyer has contracted to support the sub-allocation? The transfer policy explicitly says 'empty PA'. But in the case you describe it might be possible to do this through the mergers/acquisitions procedures
someone has a critical, very hard and slow to move (think dns or something), service in the middle of a chunk of address space they sell. the sales agreement does something kinky to make that service stay up.
this is not a merger.
Ah, then I misunderstood your scenario. Sorry. In the case you describe the current RIPE transfer policy does not allow the transfer to happen. Changing the subject... Question to the WG: I can see the need for something like this (and thinking of it: many other cases as well) to be allowed. The current limits on the transfer policy were set in a time when transfers were not well understood, and limits were placed to avoid abuse of the policy (hoarding, speculation etc). Is it now time to reconsider those limits we placed years ago? Thanks, Sander
* Sander Steffann
someone has a critical, very hard and slow to move (think dns or something), service in the middle of a chunk of address space they sell. the sales agreement does something kinky to make that service stay up.
this is not a merger.
Ah, then I misunderstood your scenario. Sorry. In the case you describe the current RIPE transfer policy does not allow the transfer to happen.
Current policy says about assignments: «In general, addresses can be replaced on a one-to-one basis. Valid assignments can be replaced with the same number of addresses if the original assignment criteria are still met.» The way I see it, this opens up for the new LIR (the alloc buyer) to inherit the documentation relating to the assignment from the old LIR (the seller), and on that basis make a new assignment that happens to consist of the exact same addresses as before.
Changing the subject...
Question to the WG: I can see the need for something like this (and thinking of it: many other cases as well) to be allowed. The current limits on the transfer policy were set in a time when transfers were not well understood, and limits were placed to avoid abuse of the policy (hoarding, speculation etc). Is it now time to reconsider those limits we placed years ago?
When 2012-09^w2013-02^w2013-03 eventually enters the discussion phase you'll probably get answers to at least some of those questions.. ;-) -- Tore Anderson
Current policy says about assignments: «In general, addresses can be replaced on a one-to-one basis. Valid assignments can be replaced with the same number of addresses if the original assignment criteria are still met.»
The way I see it, this opens up for the new LIR (the alloc buyer) to inherit the documentation relating to the assignment from the old LIR (the seller), and on that basis make a new assignment that happens to consist of the exact same addresses as before.
You're probably right. Right in the sense that this can be resolved by a kind of creative policy interpretation and/or the RIPE NCC playing fast and loose with policies and procedures in the name of being reasonable. That doesn't change the fact that the IPv4 Policy is in need over a complete overhaul. It has served well for many years in a world where there was a large pool of un-allocated space that could be distributed according to need. That is no longer the world we live in. And today large sections of it are completely obsolete (PI anyone?) while others can still be applied today but make little sense (AW raise after six months to a /21?) It is in my opinion not enough to just cut out a few sections and make a few edits. The current document is very much written for a world that no longer exists and it probably needs a complete rewrite from scratch. Thoughts? Alex Le Heux Kobo Inc
Hi, On Sat, Mar 16, 2013 at 12:24:29PM +0100, Alex Le Heux wrote:
It is in my opinion not enough to just cut out a few sections and make a few edits. The current document is very much written for a world that no longer exists and it probably needs a complete rewrite from scratch.
Thoughts?
Expect some announcements next week... :-) Gert Doering -- APWG chairs -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Mar 16, 2013, at 7:24 AM, Alex Le Heux <aleheux@kobo.com> wrote:
(Tore Anderson wrote:) Current policy says about assignments: «In general, addresses can be replaced on a one-to-one basis. Valid assignments can be replaced with the same number of addresses if the original assignment criteria are still met.»
The way I see it, this opens up for the new LIR (the alloc buyer) to inherit the documentation relating to the assignment from the old LIR (the seller), and on that basis make a new assignment that happens to consist of the exact same addresses as before.
You're probably right. Right in the sense that this can be resolved by a kind of creative policy interpretation and/or the RIPE NCC playing fast and loose with policies and procedures in the name of being reasonable.
Just for reference, the concept of being able to transfer an existing block from one party to another also has a basis in the early Internet Registry system documents, i.e. RFC 2050 (1997), which included the guideline: "The transfer of IP addresses from one party to another must be approved by the regional registries. The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR." Clearly, the policy as developed by the RIPE community is what truly matters, but it should be noted that the outcome will not be new ground in any case. FYI, /John John Curran President and CEO ARIN
-----Original Message-----
That doesn't change the fact that the IPv4 Policy is in need over a complete overhaul. It has served well for many years in a world where there was a large pool of un-allocated space that could be distributed according to need. That is no longer the world we live in.
[Milton L Mueller] completely agree. Indeed, have been saying this for five years.
It is in my opinion not enough to just cut out a few sections and make a few edits. The current document is very much written for a world that no longer exists and it probably needs a complete rewrite from scratch.
Thoughts?
[Milton L Mueller] We are gaining experience with transfer markets. There is still a small but entrenched old guard that throws up roadblocks to this change, mostly in the area of needs assessments and unrealistic time frames for defining need. In the meantime, scarcity and market-related incentives are eroding the old principles behind the scenes - all in ways that are quite predictable to any economist. Until community fears of market trading and bogeymen related to "speculation" are overcome, it will be difficult to "overhaul" v4 allocation policies in the way that is needed.
On Mon, Mar 4, 2013 at 2:46 PM, Emilio Madaio <emadaio@ripe.net> wrote:
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 March 2013.
Needs a _lot_ more discussion. 1) The impact analysis implies that this applies to RIPE LIRs getting PA/legacy IP space from non-RIPE RIRs. As I understand the text, this is not the case. The proposal merely deals with transfer of RIPE PA/legacy IP space to non-RIPE LIRs. IMO, this means that the wording in the PDP is unclear or that the impact analysis is flawed. Either way, this is not desirable. 2) What are the requirements so that another RIR's policy is seen as "compatible inter-RIR transfer policy"? Who defines this and where? 3) "Increases the supply of IPv4 addresses available to RIPE NCC LIRs" Again, I can not see this in the wording of the PDP. If anything, this decreases the available pool. I am not saying this is good or bad, merely stating a fact. 4) "Maintains the integrity of RIPE's whois database and ensures they are part of the approval and transfer process" If transfers outside of RIPE are not allowed, surely the whois database will remain correct. If it's not correct and policies have been circumvented in the process there are procedures to deal with this. I am not saying I agree or disagree with the apparent(?) intention behind all this; I think we need to have a clear understanding of what's actually proposed before we can argue about specifics. -- Richard PS: "of an RIR" is incorrect; it's "of a RIR"
Hi, On Mon, Mar 11, 2013 at 03:31:21PM +0100, Richard Hartmann wrote:
On Mon, Mar 4, 2013 at 2:46 PM, Emilio Madaio <emadaio@ripe.net> wrote:
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 March 2013.
Needs a _lot_ more discussion.
1) The impact analysis implies that this applies to RIPE LIRs getting PA/legacy IP space from non-RIPE RIRs. As I understand the text, this is not the case. The proposal merely deals with transfer of RIPE PA/legacy IP space to non-RIPE LIRs.
Please read the policy proposal more thoroughly. The wording change to the existing policy only covers "to non-RIPE LIRs" (indeed), but there's a whole new document, the "Inter-RIR transfer policy" - which covers to and from RIPE, starting after the block "[Following text will result in a new RIPE Policy Document ?Policy for Inter-RIR Transfers of IPv4 address space?, if the proposal reaches consensus.]" (The wording change to the existing RIPE IPv4 policy document is needed to avoid a conflict between the new document and the existing policy) Section 2.0 of that new document starts with: "2.0 Transferring IPv4 address space to the RIPE NCC service region" which I find very much to cover "to the RIPE NCC service region"...? [..]
2) What are the requirements so that another RIR's policy is seen as "compatible inter-RIR transfer policy"? Who defines this and where?
"We permit transfers to RIPE NCC, and transfers from the RIPE NCC, when certain (locally defined) conditions are met" = compatible "We do not permit transfers outside our region" = "incompatible" Explained in more details in the new policy document...
3) "Increases the supply of IPv4 addresses available to RIPE NCC LIRs"
Again, I can not see this in the wording of the PDP. If anything, this decreases the available pool. I am not saying this is good or bad, merely stating a fact.
Please read the document more thoroughly. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Mon, Mar 11, 2013 at 3:44 PM, Gert Doering <gert@space.net> wrote:
Please read the policy proposal more thoroughly.
Indeed. Re-reading the page, I honestly can't say for sure how I overlooked that large block of text right in the middle of the page. It may have been the copying of the text into vimdiff to highlight the changes and then mentally closing the rest of the page. Either way, this is more for the record and an attempt at an explanation, not an excuse for not properly reading the proposal. If anything, this is more motivation to start a PDP within the services WG to request proper diff handling for all PDPs. I can't say I see a valid long-term need for this proposal, but I am not particularly opposed to it either. As other people went to a lot of trouble to get to this point and as, presumably, ARIN & APNIC already have compatible policies, I don't see the harm in allowing ARIN space to flow to RIPE and APNIC and RIPE space to APNIC. If AfriNIC joins as well, APNIC can grow even more ;) Weak support. Richard
Dear AP WG, On Mon, Mar 04, 2013 at 02:46:03PM +0100, Emilio Madaio wrote:
The draft document for the version 2.0 of the proposal 2012-02, "Policy for Inter-RIR Transfers of IPv4 Address Space", has been published. The impact analysis that was conducted for this proposal has also been published. [..] You can find the full proposal and the impact analysis at:
https://www.ripe.net/ripe/policies/proposals/2012-02 [..] We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 18 March 2013.
Some comments have been received, but the voice of the community is less than clear to me. I have 3 voices of opposition, 4 voices of support, and a number of voices that are asking for clarification. This is far from consensus, and it's a bit unlucky that the real discussion is starting so late in the process - but anyway, now you're talking and I'm happy to see this. To try to reach a more clear picture, the WG chairs have decided to extend the review period for this proposal by 4 weeks as well. Emilio will do the formal announcement soon. I want to ask the proposer (Sandra Brown) to use that time to sort out the remaining issues regarding language - if needed, we can always do a v3.0 of the proposal, possibly changing it completely - and work with those that oppose the proposal to see whether middle ground can be found. In addition to that, some behind-the-scenes talk suggested to me that there was "lots of interest" in this proposal - so show it to me, by speaking up. Appended below is a list of people voicing an opinion in the review phase, and my interpretation of their support/non-support for the proposal. If you disagree with our interpretation of what has been said, and the conclusion we have drawn from it, please let us know. Gert Doering -- APWG chair ------------------------------------------- 2012-02 2.0 review phase (2013-03-04 - 2013-03-18) Sandra Brown: explanation of the reason for a v2.0 McTim: opposition based on impact analysis and NCC workload Tore Anderson: worried about amount of work created, neutral Sascha Luck: opposition based on admin overhead creating fee increase Mike Burns: support Nigel Titley: worried about language not precise enough answered by Sandra Brown Andreas Larsen: support, but worried about cost/overhead at RIPE NCC Boggits: question about existing transfer policy clauses ("must be empty") (short side-track to clarify) Richard Hartmann: neutral, but "proposal is not ready, needs more discussion, it's not actually clear waht this is all about" (short side-track, WG chair pointing to relevant bits of proposal) -> still "neutral" to "weak support" Mike Simkins: "more clarification needed", tend to opposition Andre de la Haye / RIPE NCC: clarification about implementation costs -> Tore Anderson "return to neutral wrt proposal" Phil Rushton: support -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
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
On Thu, Mar 21, 2013 at 11:53 PM, Tore Anderson <tore@fud.no> wrote:
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...
One point I think is worth mentioning in this thread: you referenced http://www.menog.org/presentations/menog-12/127-IPv4_Transfers-RIPE_NCC_Upda... the fact that there have been only 17 transactions to date, as an argument that 2012-02 is less of a priority than 2012-13. One thing that really stuck out to me from that presentation was the fact that there was "Currently 6,144 IPs offered vs 1,714,176 requested" on the RIPE listing service. I have also heard that many organizations seeking to obtain addresses via transfer in the RIPE region are having trouble doing so, because of the scarcity of supply. This has undoubtedly reduced the volume of transactions. I have also heard that it is resulting in organizations setting for much less space than they'd like due to the high price (relative to the prevailing market price in the ARIN and APNIC regions). Given that, I do think it is important to pass a compatible inter-RIR transfer policy as soon as feasible, to allow organizations in the RIPE region to get access to resources from other regions.
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. Perhaps the key would be to have RIPE continue doing needs assessment on transfers, while allowing LIRs to reassign space to customers without any particular requirements. I'm not sure if RIPE would still have to collect some sort of usage information on reassigned space in the event an LIR came back for another block via transfer, but I suspect that'd be a much lower burden than the current needs-assessment-on-everything situation.
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».
Yes, there will definitely need to be some coordination there. -Scott
On Mon, Mar 25, 2013 at 1:35 PM, Scott Leibrand <scottleibrand@gmail.com>wrote:
On Thu, Mar 21, 2013 at 11:53 PM, Tore Anderson <tore@fud.no> wrote:
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.
Perhaps the key would be to have RIPE continue doing needs assessment on transfers, while allowing LIRs to reassign space to customers without any particular requirements. I'm not sure if RIPE would still have to collect some sort of usage information on reassigned space in the event an LIR came back for another block via transfer, but I suspect that'd be a much lower burden than the current needs-assessment-on-everything situation.
Specifically, maybe we could simply use the same language used in the APNIC transfer policy (http://www.apnic.net/policy/transfer-policy), which is currently being used for inter-RIR transfers between ARIN and APNIC: 3.3 Conditions on recipient of the transfer The recipient entity will be subject to current APNIC policies. Recipients that do not already hold IPv4 resource must demonstrate a detailed plan for the use of the transferred resource within 24 months. Recipients that already hold IPv4 resources must: Demonstrate a detailed plan for the use of the transferred resource within 24 months, Show past usage rate, and Provide evidence of compliance with APNIC policies with respect to past delegations. -Scott
* Scott Leibrand
One point I think is worth mentioning in this thread: you referenced http://www.menog.org/presentations/menog-12/127-IPv4_Transfers-RIPE_NCC_Upda... and the fact that there have been only 17 transactions to date, as an argument that 2012-02 is less of a priority than 2012-13. One thing that really stuck out to me from that presentation was the fact that there was "Currently 6,144 IPs offered vs 1,714,176 requested" on the RIPE listing service. I have also heard that many organizations seeking to obtain addresses via transfer in the RIPE region are having trouble doing so, because of the scarcity of supply. This has undoubtedly reduced the volume of transactions. I have also heard that it is resulting in organizations setting for much less space than they'd like due to the high price (relative to the prevailing market price in the ARIN and APNIC regions).
Given that, I do think it is important to pass a compatible inter-RIR transfer policy as soon as feasible, to allow organizations in the RIPE region to get access to resources from other regions.
Well, the community response to 2012-02 hasn't exactly been overly enthusiastic either. That, plus the small amount of in-region transfers seen so far, makes me of the opinion that the entire transfer market thing is rather over-hyped. (I've heard that there are more space available for sale in the region than what's listed in the LIR Portal though. Sellers might opt to use a broker instead of the listing service, for example.) That said, I'm not opposed to 2012-02 per se - I'm just convinced that 2013-03 is going to be more important and beneficial to the day-to-day operations of the majority of LIRs in our region. I don't feel it's right to insist on a continued bureaucracy enforced on *all* the LIRs in the region for the sole purpose of allowing a fraction of those LIRs to engage in inter-region allocation trade with ARIN. If the continued bureaucracy could be a voluntary thing for those LIRs that wanted to trade with ARIN, then it'd be different. Maybe if 2012-02 said something like "If you receive space from ARIN you agree that the space is bound by ARIN's address policies with regards to need justification for 24 months"? Probably easier to say than do, I guess... I have no problems seeing 2012-02 pass alongside 2013-03. Those two policy proposals aren't in conflict in any way. While the resulting total would be in conflict with ARIN, we would have enabled for transfers to/from APNIC. And the door would then automatically open for ARIN too, the moment they rescind the need requirement in their end. Same goes for AfriNIC and LACNIC too, the moment they pass appropriate policy in their end.
Perhaps the key would be to have RIPE continue doing needs assessment on transfers, while allowing LIRs to reassign space to customers without any particular requirements.
Problem with this is that I don't think ARIN would be satisified: LIR: «Hey NCC, can you give us the "need certificate" so we can justify the transfer of a /8 from the ARIN region?» NCC: «Well, describe your need for the allocation then.» LIR: «We want to make an assignment of 1 billion addresses to the coffee maker in our office.» NCC: «Does your coffee maker really need 1 billio...oh wait, that's a completely valid assignment nowadays. Here's your need certificate!» This is why I made 2013-03 remove the need concept for allocations. It simply does not make sense to keep it, because once you remove the need concept at the lowest level (i.e., assignments), the entire chain upward collapses and it makes no sense to keep the need concept around any longer at any level. Tore
participants (18)
-
Alex Le Heux -
Andreas Larsen -
boggits -
Emilio Madaio -
Gert Doering -
Jim Reid -
John Curran -
McTim -
Mike Burns -
Milton L Mueller -
Nigel Titley -
Randy Bush -
Remco Van Mook -
Richard Hartmann -
Sander Steffann -
Sascha Luck -
Scott Leibrand -
Tore Anderson