From Matt.Mather at gamma.co.uk Fri Mar 1 17:42:52 2013 From: Matt.Mather at gamma.co.uk (Matt Mather) Date: Fri, 1 Mar 2013 16:42:52 +0000 Subject: [address-policy-wg] RIPE Policy Proposals 2012-02 and 2012-03. Message-ID: <5CECD6D6BA99B6439BD9E35334C10A150C797FCAF0@INF-MX-MB-CL.gammatelecom.com> Hi there, I am representing GTHL, AS31655 and I am trying to find out a little more about the polices mentioned in the subject line of this mail. I am particularly interested in when the current phase will to come conclusion and if proposals will either become policy or not. If you help shed some light on this I would appreciate it. Thanks and regards, Matt Mather. Matt Mather IP Design & Test Engineer [cid:175335.png at 93d11731.469d99cb] +44 333 240 3348 [cid:a4dd06.png at ca9b06cb.4cb60299] +44 7848 026 072 [cid:2064f1.png at a37f7ca9.4fa780ae] matt.mather at gamma.co.uk [cid:f2ed08.png at 33e479c2.45839582] http://www.gamma.co.uk [cid:image81cfba.JPG at 07754e56.4a9e851f] Follow us [cid:image18ed05.GIF at bcc7563d.4f9c7814][cid:image018a85.GIF at 21bb7df6.4190c541][cid:imagee5cab3.GIF at aca78f6f.4692f34b] ________________________________ This is an email from Gamma Telecom Ltd, trading as ?Gamma?. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 175335.png Type: image/png Size: 813 bytes Desc: 175335.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: a4dd06.png Type: image/png Size: 640 bytes Desc: a4dd06.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2064f1.png Type: image/png Size: 646 bytes Desc: 2064f1.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: f2ed08.png Type: image/png Size: 925 bytes Desc: f2ed08.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image81cfba.JPG Type: image/jpeg Size: 20964 bytes Desc: image81cfba.JPG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image18ed05.GIF Type: image/gif Size: 1422 bytes Desc: image18ed05.GIF URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image018a85.GIF Type: image/gif Size: 1412 bytes Desc: image018a85.GIF URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagee5cab3.GIF Type: image/gif Size: 1427 bytes Desc: imagee5cab3.GIF URL: From gert at space.net Fri Mar 1 18:54:39 2013 From: gert at space.net (Gert Doering) Date: Fri, 1 Mar 2013 18:54:39 +0100 Subject: [address-policy-wg] RIPE Policy Proposals 2012-02 and 2012-03. In-Reply-To: <5CECD6D6BA99B6439BD9E35334C10A150C797FCAF0@INF-MX-MB-CL.gammatelecom.com> References: <5CECD6D6BA99B6439BD9E35334C10A150C797FCAF0@INF-MX-MB-CL.gammatelecom.com> Message-ID: <20130301175439.GV51699@Space.Net> Hi, On Fri, Mar 01, 2013 at 04:42:52PM +0000, Matt Mather wrote: > I am representing GTHL, AS31655 and I am trying to find out a little more about the polices mentioned in the subject line of this mail. I am particularly interested in when the current phase will to come conclusion and if proposals will either become policy or not. The "current phase" is "waiting for the WG chairs / waiting for the proposer" (not a phase, strictly, but the status in-between formal phases where decisions about the next steps are made), which you can find out via the "open policy proposals" status page on https://www.ripe.net/ripe/policies/current-proposals/current-policy-proposals we had some lengthy internal discussions about these two proposals, and decided to put them back to review period (for a short review phase), which will be formally announced on Monday. After Emilio's announcement on Monday, I would welcome a somewhat more verbose community participation than previously for those two proposals, as we can't go ahead without more voices of support. (*After* the announcement, as the review phase has not yet formally begun) 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 From Matt.Mather at gamma.co.uk Mon Mar 4 09:09:43 2013 From: Matt.Mather at gamma.co.uk (Matt Mather) Date: Mon, 4 Mar 2013 08:09:43 +0000 Subject: [address-policy-wg] RIPE Policy Proposals 2012-02 and 2012-03. In-Reply-To: <20130301175439.GV51699@Space.Net> References: <5CECD6D6BA99B6439BD9E35334C10A150C797FCAF0@INF-MX-MB-CL.gammatelecom.com> <20130301175439.GV51699@Space.Net> Message-ID: <5CECD6D6BA99B6439BD9E35334C10A150C797FCE19@INF-MX-MB-CL.gammatelecom.com> Thanks for adding some clarity to the current status Gert, I can see how these would be quite contentious. I'll look out for Emilio's announcement later today. Matt Mather IP Design & Test Engineer T: +44 333 240 3348 M: +44 7848 026 072 E: Matt.Mather at gamma.co.uk W: http://www.gamma.co.uk This is an email from Gamma Telecom Ltd, trading as "Gamma". The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY. -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: 01 March 2013 17:55 To: Matt Mather Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] RIPE Policy Proposals 2012-02 and 2012-03. Hi, On Fri, Mar 01, 2013 at 04:42:52PM +0000, Matt Mather wrote: > I am representing GTHL, AS31655 and I am trying to find out a little more about the polices mentioned in the subject line of this mail. I am particularly interested in when the current phase will to come conclusion and if proposals will either become policy or not. The "current phase" is "waiting for the WG chairs / waiting for the proposer" (not a phase, strictly, but the status in-between formal phases where decisions about the next steps are made), which you can find out via the "open policy proposals" status page on https://www.ripe.net/ripe/policies/current-proposals/current-policy-proposals we had some lengthy internal discussions about these two proposals, and decided to put them back to review period (for a short review phase), which will be formally announced on Monday. After Emilio's announcement on Monday, I would welcome a somewhat more verbose community participation than previously for those two proposals, as we can't go ahead without more voices of support. (*After* the announcement, as the review phase has not yet formally begun) 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 From Christoph.Neukirch at xing.com Mon Mar 4 12:13:59 2013 From: Christoph.Neukirch at xing.com (Christoph Neukirch) Date: Mon, 4 Mar 2013 11:13:59 +0000 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <874079a0-d397-40c0-b81e-cb9b8ced2263@XING-EXCHSVR02.xing.hh> Message-ID: Am 28.02.13 14:04 schrieb "Marco Schmidt" unter : > >Dear Colleagues > >A new RIPE Policy Proposal has been made and is now available for >discussion. > > >You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-02/ > >We encourage you to review this proposal and send your comments to > before 28 March 2013. > >Regards > >Marco Schmidt >on behalf of the Policy Development Office >RIPE NCC supported -- kind regards Christoph Neukirch From dcunningham at airspeed.ie Mon Mar 4 12:28:44 2013 From: dcunningham at airspeed.ie (Donal Cunningham) Date: Mon, 4 Mar 2013 11:28:44 +0000 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: References: <874079a0-d397-40c0-b81e-cb9b8ced2263@XING-EXCHSVR02.xing.hh> Message-ID: > >We encourage you to review this proposal and send your comments to > > before 28 March 2013. Support. D. From emadaio at ripe.net Mon Mar 4 14:46:03 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 04 Mar 2013 14:46:03 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) Message-ID: 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 at ripe.net before 18 March 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Mon Mar 4 15:26:03 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 04 Mar 2013 15:26:03 +0100 Subject: [address-policy-wg] 2012-03 New Draft Document and Impact Analysis Published (Intra-RIR Transfer Policy Proposal) Message-ID: Dear Colleagues The draft document for the version 3.0 of the proposal 2012-03, "Intra-RIR Transfers Policy Proposal", has been published. The impact analysis that was conducted for this proposal has also been published. The only change in the new version is: -removed a modification to the second paragraph of section 5.5, "Transfer of Allocation", in the RIPE Policy document ripe-592, "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-03 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 18 March 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC From Ragnar.Anfinsen at altibox.no Mon Mar 4 15:54:53 2013 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Mon, 4 Mar 2013 14:54:53 +0000 Subject: [address-policy-wg] 2012-03 New Draft Document and Impact Analysis Published (Intra-RIR Transfer Policy Proposal) In-Reply-To: References: Message-ID: Why do we need this policy change, now that 2012-06 is approved and being implemented? MVH/Regards Ragnar > -----Original Message----- > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of Emilio Madaio > Sent: 4. mars 2013 15:26 > To: policy-announce at ripe.net > Cc: address-policy-wg at ripe.net > Subject: [address-policy-wg] 2012-03 New Draft Document and Impact > Analysis Published (Intra-RIR Transfer Policy Proposal) > > > > Dear Colleagues > > The draft document for the version 3.0 of the proposal 2012-03, > "Intra-RIR Transfers Policy Proposal", has been published. The impact > analysis that was conducted for this proposal has also been published. > > The only change in the new version is: > > -removed a modification to the second paragraph of section 5.5, > "Transfer of Allocation", in the RIPE Policy document ripe-592, "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-03 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-03/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 18 March 2013. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > From gert at space.net Mon Mar 4 16:02:20 2013 From: gert at space.net (Gert Doering) Date: Mon, 4 Mar 2013 16:02:20 +0100 Subject: [address-policy-wg] 2012-03 New Draft Document and Impact Analysis Published (Intra-RIR Transfer Policy Proposal) In-Reply-To: References: Message-ID: <20130304150220.GT51699@Space.Net> Hi, On Mon, Mar 04, 2013 at 02:54:53PM +0000, Anfinsen, Ragnar wrote: > Why do we need this policy change, now that 2012-06 is approved and being implemented? It's a different timeline - 2012-06 brought back 12 months, this is for 24 months. Whether you *need* this, I wouldn't know :-) - this is for the community to say. I'm just here to answer questions and to steer the process. 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 From sandrabrown at ipv4marketgroup.com Tue Mar 5 15:21:23 2013 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Tue, 05 Mar 2013 07:21:23 -0700 Subject: [address-policy-wg] 2012-03 New Draft Document and Impact Analysis Published (Intra-RIR Transfer Policy Proposal) Message-ID: <20130305072123.ec289651d84890fcbef5f195936e1217.7f5f6b5ce5.wbe@email17.secureserver.net> In reposting 2012-03, I updated the policy to refer only to time specific changes, ie the change from 3 months (and 12 months with 2012-06) to 24 months. I did not add any embellishments about the RIPE region that are not needed. The tweaks to section 5.5 fit with policy 2012-02 where we talk about the global nature. I prefer to see 2012-03 approved and the need period for all transfers to become 24 months without mentioning the transfer scope. This policy is only about the time for needs justification. From sandrabrown at ipv4marketgroup.com Tue Mar 5 15:24:25 2013 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Tue, 05 Mar 2013 07:24:25 -0700 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) Message-ID: <20130305072425.ec289651d84890fcbef5f195936e1217.92e882d165.wbe@email17.secureserver.net> In reposting 2012-02, I realized that this policy had awkwardly referred to "within the RIPE region" and based on comments received, I realized we needed to make it more global in nature. Hence I changed it to refer to "RIR's with compatible policies". Section 5.5 of the IPv4 policy had previously been meant for intra-RIR transfers only. So, in making this policy change, the goal is to tweak the intra-RIR transfer policy to allow a non-conflicting inter-RIR transfer policy to co-exist. From dhilario at ripe.net Wed Mar 6 10:22:15 2013 From: dhilario at ripe.net (David Hilario) Date: Wed, 6 Mar 2013 10:22:15 +0100 Subject: [address-policy-wg] Policy Proposal 2012-06 Revert "Run Out Fairly" implemented Message-ID: [Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2012-06, Revert "Run Out Fairly" , has been implemented. The RIPE NCC is now ready to accept requests for IPv4 assignments and IPv4 allocations under this policy. The full proposal can be found at: http://www.ripe.net/ripe/policies/archived-policy-proposals/proposals/2012-06 The updated "IPv4 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ripe-582 IPv4 assignments request forms have been updated. You can access the request forms through the LIR Portal or online at: http://www.ripe.net/ripe/docs/ripe-583 The supporting notes are available at: http://www.ripe.net/ripe/docs/ripe-584 If you have any questions, please contact. Regards, David Hilario Registration Services RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.vallerot at opdop.net Wed Mar 6 11:03:13 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Wed, 06 Mar 2013 11:03:13 +0100 Subject: [address-policy-wg] Policy Proposal 2012-06 Revert "Run Out Fairly" implemented In-Reply-To: References: Message-ID: <51371461.9000009@opdop.net> Hi, Seems to me that ripe-583 and ripe-584 lack indications about the length of the period to be considered to make IPv4 PA requests. This lets some confusion here and lead to unnecessary correction work on future requests or inappropriate documentation by LIRs using their allocation windows. I suggest the "3 months", "1 year" and "2 years" formulas from ripe-381 and ripe-382 to be used again to make them more explicit. Best regards, From gert at space.net Mon Mar 11 13:47:11 2013 From: gert at space.net (Gert Doering) Date: Mon, 11 Mar 2013 13:47:11 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: Message-ID: <20130311124711.GA13444@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 at 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 From dogwallah at gmail.com Mon Mar 11 14:42:43 2013 From: dogwallah at gmail.com (McTim) Date: Mon, 11 Mar 2013 09:42:43 -0400 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <20130311124711.GA13444@Space.Net> References: <20130311124711.GA13444@Space.Net> Message-ID: 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 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 at 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 > From richih.mailinglist at gmail.com Mon Mar 11 15:31:21 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 11 Mar 2013 15:31:21 +0100 Subject: [address-policy-wg] [policy-announce] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: Message-ID: On Mon, Mar 4, 2013 at 2:46 PM, Emilio Madaio wrote: > We encourage you to read the draft document text and send any comments > to address-policy-wg at 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" From boggits at gmail.com Mon Mar 11 15:00:46 2013 From: boggits at gmail.com (boggits) Date: Mon, 11 Mar 2013 14:00:46 +0000 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: Message-ID: On 4 March 2013 13:46, 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. 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 From gert at space.net Mon Mar 11 15:44:29 2013 From: gert at space.net (Gert Doering) Date: Mon, 11 Mar 2013 15:44:29 +0100 Subject: [address-policy-wg] [policy-announce] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: Message-ID: <20130311144429.GB51699@Space.Net> 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 wrote: > > > We encourage you to read the draft document text and send any comments > > to address-policy-wg at 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 From gert at space.net Mon Mar 11 15:47:09 2013 From: gert at space.net (Gert Doering) Date: Mon, 11 Mar 2013 15:47:09 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: Message-ID: <20130311144709.GC51699@Space.Net> Hi, On Mon, Mar 11, 2013 at 02:00:46PM +0000, boggits wrote: > On 4 March 2013 13:46, 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. > > 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 From richih.mailinglist at gmail.com Mon Mar 11 16:47:07 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 11 Mar 2013 16:47:07 +0100 Subject: [address-policy-wg] [policy-announce] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <20130311144429.GB51699@Space.Net> References: <20130311144429.GB51699@Space.Net> Message-ID: On Mon, Mar 11, 2013 at 3:44 PM, Gert Doering 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 From lists-ripe at c4inet.net Mon Mar 11 17:15:09 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 11 Mar 2013 16:15:09 +0000 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <20130311124711.GA13444@Space.Net> References: <20130311124711.GA13444@Space.Net> Message-ID: <20130311161509.GA58590@cilantro.c4inet.net> 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 at 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 > From nigel at titley.com Mon Mar 11 17:18:42 2013 From: nigel at titley.com (Nigel Titley) Date: Mon, 11 Mar 2013 16:18:42 +0000 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <20130311124711.GA13444@Space.Net> References: <20130311124711.GA13444@Space.Net> Message-ID: <513E03E2.6000608@titley.com> 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 at 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 From Remco.vanMook at eu.equinix.com Mon Mar 11 18:14:17 2013 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Mon, 11 Mar 2013 17:14:17 +0000 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <20130311144709.GC51699@Space.Net> Message-ID: On 3/11/13 15:47 , "Gert Doering" 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 at equinix.com | T +31-6-11356365 HOW ARE WE DOING? Please click here to Tell Equinix - We're Listening Equinix.co.uk | Twitter | LinkedIn | Facebook | YouTube 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. From tore at fud.no Mon Mar 11 18:28:55 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 11 Mar 2013 18:28:55 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: <20130311124711.GA13444@Space.Net> Message-ID: <513E1457.1070106@fud.no> * 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 From gert at space.net Mon Mar 11 18:43:28 2013 From: gert at space.net (Gert Doering) Date: Mon, 11 Mar 2013 18:43:28 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <513E1457.1070106@fud.no> References: <20130311124711.GA13444@Space.Net> <513E1457.1070106@fud.no> Message-ID: <20130311174328.GG51699@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From jim at rfc1035.com Mon Mar 11 18:48:35 2013 From: jim at rfc1035.com (Jim Reid) Date: Mon, 11 Mar 2013 17:48:35 +0000 Subject: [address-policy-wg] Impact analysis in the PDP In-Reply-To: <513E1457.1070106@fud.no> References: <20130311124711.GA13444@Space.Net> <513E1457.1070106@fud.no> Message-ID: <0D736AD9-CB59-4D77-B4D3-B17C64365CC8@rfc1035.com> On 11 Mar 2013, at 17:28, Tore Anderson 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! From tore at fud.no Mon Mar 11 18:52:35 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 11 Mar 2013 18:52:35 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <20130311174328.GG51699@Space.Net> References: <20130311124711.GA13444@Space.Net> <513E1457.1070106@fud.no> <20130311174328.GG51699@Space.Net> Message-ID: <513E19E3.6080505@fud.no> * 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 From andreas.larsen at ip-only.se Mon Mar 11 19:23:36 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Mon, 11 Mar 2013 19:23:36 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <20130311124711.GA13444@Space.Net> Message-ID: 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 : >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 at 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 > From tore at fud.no Mon Mar 11 20:21:37 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 11 Mar 2013 20:21:37 +0100 Subject: [address-policy-wg] Impact analysis in the PDP In-Reply-To: <0D736AD9-CB59-4D77-B4D3-B17C64365CC8@rfc1035.com> References: <20130311124711.GA13444@Space.Net> <513E1457.1070106@fud.no> <0D736AD9-CB59-4D77-B4D3-B17C64365CC8@rfc1035.com> Message-ID: <513E2EC1.7020105@fud.no> * Jim Reid > On 11 Mar 2013, at 17:28, Tore Anderson 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_Update.pdf 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 From jim at rfc1035.com Mon Mar 11 20:46:39 2013 From: jim at rfc1035.com (Jim Reid) Date: Mon, 11 Mar 2013 19:46:39 +0000 Subject: [address-policy-wg] Impact analysis in the PDP In-Reply-To: <513E2EC1.7020105@fud.no> References: <20130311124711.GA13444@Space.Net> <513E1457.1070106@fud.no> <0D736AD9-CB59-4D77-B4D3-B17C64365CC8@rfc1035.com> <513E2EC1.7020105@fud.no> Message-ID: <58DBD074-E2E8-4CB8-944F-4D391E47BFE4@rfc1035.com> On 11 Mar 2013, at 19:21, Tore Anderson 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. From mike at iptrading.com Mon Mar 11 21:14:20 2013 From: mike at iptrading.com (Mike Burns) Date: Mon, 11 Mar 2013 16:14:20 -0400 Subject: [address-policy-wg] 2012-02 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: <20130311124711.GA13444@Space.Net> Message-ID: 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 at 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 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 at 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 > From randy at psg.com Mon Mar 11 23:49:29 2013 From: randy at psg.com (Randy Bush) Date: Mon, 11 Mar 2013 15:49:29 -0700 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <20130311144709.GC51699@Space.Net> References: <20130311144709.GC51699@Space.Net> Message-ID: >> "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 From sandrabrown at ipv4marketgroup.com Tue Mar 12 14:37:57 2013 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Tue, 12 Mar 2013 06:37:57 -0700 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published(Policy for Inter-RIR Transfers of IPv4 Address Space) Message-ID: <20130312063757.ec289651d84890fcbef5f195936e1217.c9b039abe7.wbe@email17.secureserver.net> >>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? Currently the only RIR's with similar transfer policies are ARIN and APNIC. As an example, if the LIR is in ARIN region, then the LIR must be in compliance with ARIN policy in order to transfer its IPv4 address space to a RIPE LIR. The ARIN based LIR would apply to ARIN and request to transfer. (That is how it works for ARIN to APNIC transfers today.) ARIN makes sure the LIR has registration of the space before making the transfer. Similarly, I would expect for a RIPE to ARIN or APNIC transfer RIPE needs to ensure that the RIPE LIR has correct registration of the IP space being transferred. From gert at space.net Tue Mar 12 16:07:48 2013 From: gert at space.net (Gert Doering) Date: Tue, 12 Mar 2013 16:07:48 +0100 Subject: [address-policy-wg] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) In-Reply-To: References: Message-ID: <20130312150748.GA46658@Space.Net> Dear Address Policy WG, the review phase for 2012-10 has ended. Looking at the comments we got from the list in this phase, I counted 9 voices supporting the proposal, nobody objecting to it, and no side track discussions that hint at confusion about details. This is as strong supports as it gets (in addition to the overwhelming support in the discussion phase), so we think that we definitely have enough support to call consensus and move to Last Call. Emilio will do the formal announcement from the PDO later today or tomorrow. 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, Address Policy WG Chair On Mon, Feb 11, 2013 at 02:54:07PM +0100, Emilio Madaio wrote: > > Dear Colleagues, > > The draft document for the proposal described in 2012-10 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-10 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-10/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 11 March 2013. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > 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 From emadaio at ripe.net Tue Mar 12 16:23:54 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 12 Mar 2013 16:23:54 +0100 Subject: [address-policy-wg] 2012-10 Last Call for Comments (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) Message-ID: Dear Colleagues, The proposal described in 2012-10, "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis", is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 9 April 2013 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the co-Chairs of all RIPE Working Groups for consensus. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-10 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 9 April 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC From sander at steffann.nl Wed Mar 13 12:26:40 2013 From: sander at steffann.nl (Sander Steffann) Date: Wed, 13 Mar 2013 12:26:40 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: <20130311144709.GC51699@Space.Net> Message-ID: 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 From randy at psg.com Wed Mar 13 12:48:11 2013 From: randy at psg.com (Randy Bush) Date: Wed, 13 Mar 2013 07:48:11 -0400 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: <20130311144709.GC51699@Space.Net> Message-ID: >> 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 From sander at steffann.nl Wed Mar 13 12:53:22 2013 From: sander at steffann.nl (Sander Steffann) Date: Wed, 13 Mar 2013 12:53:22 +0100 Subject: [address-policy-wg] Transfer policy limits In-Reply-To: References: <20130311144709.GC51699@Space.Net> Message-ID: <8122C20F-AFF2-4BF5-AE0F-598787981F16@steffann.nl> 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 From tore at fud.no Wed Mar 13 14:29:29 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 13 Mar 2013 14:29:29 +0100 Subject: [address-policy-wg] Transfer policy limits In-Reply-To: <8122C20F-AFF2-4BF5-AE0F-598787981F16@steffann.nl> References: <20130311144709.GC51699@Space.Net> <8122C20F-AFF2-4BF5-AE0F-598787981F16@steffann.nl> Message-ID: <51407F39.2070303@fud.no> * 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 From mps31.ripe at gmail.com Wed Mar 13 14:48:25 2013 From: mps31.ripe at gmail.com (Mike Simkins) Date: Wed, 13 Mar 2013 13:48:25 +0000 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) References: Message-ID: <5BC888BF-E024-49C5-9AAA-3101FFEC5A11@gmail.com> > At the moment I think there is a lot of detail that needs to be clarified here, including the terms Originating Policy / Destination Policy and 'Compatible Inter-RIR Policies' > > If I read this right, a transfer size will depend on the larger of the RIPE (currently /22) and the other RIRs (e.g. ARIN /20). How strict or 'fuzzy' is 'Compatible' ? > > When the allocation (or justification period moves out (from 3 months to 12 months, or 24 months - the policy number escapes me at this time), will we be using a fixed formula for time based justifications (what is a 24 Month period ? /19 ?, /18 ?, /16 ?) - Different LIRs can use (as in the past) different requirements / predictions for time period 'x'. Or is this to be judged on the previous allocations to an LIR over the preceding period 'x'. > > At the moment I lean towards 'Oppose', as some of the text seems too vague to me, and may cause some interesting interpretations. > > Although not strictly mentioned in this proposal, what (for example) happens to ERX space?. If a RIPE member acquires ERX space (lets say a /16), and then wants to perhaps offer that space to another member, does the classification stay as ERX (and the basic exemptions), or (on transfer) does it become regulated space (possible impact from 2012-07) and limited to a /22 (currently) that can only be transferred? > > > Mike. From ripencc-management at ripe.net Wed Mar 13 15:57:34 2013 From: ripencc-management at ripe.net (Andrew de la Haye) Date: Wed, 13 Mar 2013 15:57:34 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) Message-ID: Dear colleagues, In order to clarify some points of the impact analysis and facilitate the current community discussion, we would like to highlight some details about the foreseen implementation activity related to the proposal 2012-02. With regards to the two points of the impact analyses that are being questioned: "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." If the proposal is accepted, it should be noted that the RIPE NCC service region will be the third region involved in inter-RIR transfers, after ARIN and APNIC. There already exists close coordination between the RS departments of all RIRs as an ongoing and ordinary activity, aimed at monitoring trends, issues and solutions related to the resource registration activities. This policy proposal would increase the importance and relevance of this existing coordination by broadening its scope to inter-RIR transfer resources as well. Therefore based on both ARIN's and APNIC's experience in this area the amount of effort may be somewhat reduced. Each inter-RIR transfer will consist of: - evaluation of RIPE Policy compliance - evaluation of official documentation - coordination with the other involved RIR staff - updating registry entries Therefore, the only additional step compared to intra-RIR transfers would be the coordination with the other RIR staff. With regards to the estimated volume of the potential inter-RIR transfers, it is difficult to make predictions, as the only data currently available is the number of transfers currently taking place, which is less than 20 intra-RIR transfers to date. Based on those numbers, we do not expect a major increase in effort. The anticipated number of inter-RIR transfers is unclear and some members of the RIPE community are suggesting that not all RIPE NCC members would directly benefit from this policy, as is the case with many RIPE Policies. However, it is worth emphasising that if no inter-RIR policy is in place there is a growing risk that some entities will choose to transfer number resources without informing the relevant RIRs or reflect these transfers in the relevant registries. This would dilute the accuracy of the collective RIR registries and have a direct impact on the entire RIPE NCC membership. Therefore, as both APNIC and ARIN already have this policy in place, the RIPE community should consider the consequences of not having an inter-RIR transfer policy in place. "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." Our legal department indicated that any changes to the appropriate legal procedures and template agreements would fit into the normal work processes that occur after any RIPE Policy has been implemented. Regards, Andrew de la Haye Chief Operations Officer RIPE NCC From sander at steffann.nl Wed Mar 13 21:27:41 2013 From: sander at steffann.nl (Sander Steffann) Date: Wed, 13 Mar 2013 21:27:41 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: Message-ID: <5652D77C-7ACB-406F-8F32-B08CE424A401@steffann.nl> Hi Andrew, > Each inter-RIR transfer will consist of: > > - evaluation of RIPE Policy compliance > - evaluation of official documentation > - coordination with the other involved RIR staff > - updating registry entries > > Therefore, the only additional step compared to intra-RIR transfers > would be the coordination with the other RIR staff. If I understand you correctly it comes down to: - If one RIR is involved that RIR does its evaluation. - If two RIRs are involved they both do their evaluation, and they communicate. If correct then it comes down to sending the other RIR an e-mail telling them 'we're fine with this transfer' and waiting for the other RIR to do the same before approving the transfer. Doesn't sound too bad :-) Cheers, Sander From tore at fud.no Thu Mar 14 09:05:52 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 14 Mar 2013 09:05:52 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <5652D77C-7ACB-406F-8F32-B08CE424A401@steffann.nl> References: <5652D77C-7ACB-406F-8F32-B08CE424A401@steffann.nl> Message-ID: <514184E0.4080506@fud.no> * Sander Steffann >> Each inter-RIR transfer will consist of: >> >> - evaluation of RIPE Policy compliance >> - evaluation of official documentation >> - coordination with the other involved RIR staff >> - updating registry entries >> >> Therefore, the only additional step compared to intra-RIR >> transfers would be the coordination with the other RIR staff. > > If I understand you correctly it comes down to: > - If one RIR is involved that RIR does its evaluation. > - If two RIRs are involved they both do their evaluation, and they > communicate. > > If correct then it comes down to sending the other RIR an e-mail > telling them 'we're fine with this transfer' and waiting for the > other RIR to do the same before approving the transfer. Doesn't sound > too bad :-) It doesn't, no. From the IA text alone I had understood that the amount of NCC work needed to implement this proposal to be ?significant?. But based on Andrew's clarification I withdraw my objection to 2012-02 and return to the neutral category. -- Tore Anderson From ripencc-management at ripe.net Thu Mar 14 09:52:08 2013 From: ripencc-management at ripe.net (Andrew de la Haye) Date: Thu, 14 Mar 2013 09:52:08 +0100 Subject: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished Message-ID: <51418FB8.1080408@ripe.net> Dear colleagues, The RIPE NCC has less than 100 32-bit Autonomous System Numbers (ASNs) available in its pool. Given current assignment rates, we expect that we will run out of 32-bit ASNs before May 2013. We will soon begin to assign 16-bit ASNs for all requests until our pool has been replenished by IANA. This will not result in any operational issues for requestors as 16-bit ASNs are compatible with equipment designed to run BGP. This situation was anticipated and covered during the RIPE NCC Registration Services update during the RIPE 65 Meeting. You can see the details in the "Feedback from RIPE NCC Registration Services" presentation available at: -------------------------- Replenishing our ASN Pool -------------------------- The RIPE NCC requests additional ASNs from IANA based on "IANA Policy for Allocation of ASN Blocks to RIRs: Under this policy, we need to demonstrate 80% usage of "the previously received ASN block" (which includes both 16-bit and 32-bit ASNs we received from IANA on 3 March 2012) to replenish our ASN pool. We are expecting to reach this usage rate within six to eight months. The RIPE NCC will return to the usual procedure of assigning 32-bit AS numbers "by default" once our ASN pool is replenished. -------------------------------------------------------------------- Background on 32-bit ASN assignments in the RIPE NCC service region -------------------------------------------------------------------- The RIPE NCC assigns ASNs based on the "Autonomous System (AS) Number Assignment Policies and Procedures": . In accordance with the RIPE Address Policy Working Group decision, announced at: , the RIPE NCC assigns 32-bit ASNs by default unless a 16-bit ASN is specifically requested. As a result of this practice, 32-bit ASNs are currently supported by most vendors and routed globally. Of the 3,400 32-bit ASNs in the global routing table, 64% were assigned by the RIPE NCC within its service region (Europe, the Middle East and parts of Central Asia). Best regards, Andrew de la Haye Chief Operations Officer RIPE NCC From rg at teamix.de Thu Mar 14 13:46:47 2013 From: rg at teamix.de (Rico Gloeckner) Date: Thu, 14 Mar 2013 13:46:47 +0100 Subject: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished In-Reply-To: <51418FB8.1080408@ripe.net> References: <51418FB8.1080408@ripe.net> Message-ID: <20130314124647.GI22559@teamix.net> Hi, On Thu, Mar 14, 2013 at 09:52:08AM +0100, Andrew de la Haye wrote: > The RIPE NCC has less than 100 32-bit Autonomous System Numbers (ASNs) > available in its pool. Given current assignment rates, we expect that we > will run out of 32-bit ASNs before May 2013. We will soon begin to > assign 16-bit ASNs for all requests until our pool has been replenished > by IANA. This will not result in any operational issues for requestors > as 16-bit ASNs are compatible with equipment designed to run BGP. This > situation was anticipated and covered during the RIPE NCC Registration > Services update during the RIPE 65 Meeting. > > Under this policy, we need to demonstrate 80% usage of "the previously > received ASN block" (which includes both 16-bit and 32-bit ASNs we > received from IANA on 3 March 2012) to replenish our ASN pool. We are > expecting to reach this usage rate within six to eight months. Mh, not April first. Seriously, where has this gone wrong? the utilization rate of 16Bit ASNs should not be a measure for replenishing the 32 bit Pool. It should never have been. This way you're actually forced to hand out 16bit ASNs BEFORE your 32bit pool runs out because there shouldnt be the situation that when somene explicitely asks for a 32bit ASN RIPE NCC is not able to "supply" one. Rico. MfG/regards, -- Rico Gloeckner Sr. System Engineer Amtsgericht Nuernberg, HRB 18320 Geschaeftsfuehrer: Oliver Kuegow, Richard Mueller From he at uninett.no Thu Mar 14 14:13:32 2013 From: he at uninett.no (Havard Eidnes) Date: Thu, 14 Mar 2013 14:13:32 +0100 (CET) Subject: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished In-Reply-To: <20130314124647.GI22559@teamix.net> References: <51418FB8.1080408@ripe.net> <20130314124647.GI22559@teamix.net> Message-ID: <20130314.141332.341694255.he@uninett.no> >> Under this policy, we need to demonstrate 80% usage of "the previously >> received ASN block" (which includes both 16-bit and 32-bit ASNs we >> received from IANA on 3 March 2012) to replenish our ASN pool. We are >> expecting to reach this usage rate within six to eight months. > > Mh, not April first. > > Seriously, where has this gone wrong? the utilization rate of 16Bit > ASNs should not be a measure for replenishing the 32 bit Pool. > > It should never have been. +1 - H?vard From bmaujean at rmi.fr Thu Mar 14 14:25:01 2013 From: bmaujean at rmi.fr (Bertrand MAUJEAN) Date: Thu, 14 Mar 2013 13:25:01 +0000 Subject: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished In-Reply-To: <20130314.141332.341694255.he@uninett.no> References: <51418FB8.1080408@ripe.net> <20130314124647.GI22559@teamix.net> <20130314.141332.341694255.he@uninett.no> Message-ID: <147C692B2643E149B535628F172D56481DF24471@RMI-EXCH.rmidom.intra> Hello, A very disappointing side-effect. Is it possible to have IANA derogate to the rule ? It's like falling in a trap we dug ourselves... Hopefully, we did not make the same mistake for IPv4/v6 addresses ! Bertrand -----Message d'origine----- De?: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] De la part de Havard Eidnes Envoy??: jeudi 14 mars 2013 14:14 ??: rg at teamix.de Cc?: address-policy-wg at ripe.net Objet?: Re: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished >> Under this policy, we need to demonstrate 80% usage of "the >> previously received ASN block" (which includes both 16-bit and 32-bit >> ASNs we received from IANA on 3 March 2012) to replenish our ASN >> pool. We are expecting to reach this usage rate within six to eight months. > > Mh, not April first. > > Seriously, where has this gone wrong? the utilization rate of 16Bit > ASNs should not be a measure for replenishing the 32 bit Pool. > > It should never have been. +1 - H?vard From aleheux at kobo.com Sat Mar 16 12:24:29 2013 From: aleheux at kobo.com (Alex Le Heux) Date: Sat, 16 Mar 2013 12:24:29 +0100 Subject: [address-policy-wg] Transfer policy limits In-Reply-To: <51407F39.2070303@fud.no> References: <20130311144709.GC51699@Space.Net> <8122C20F-AFF2-4BF5-AE0F-598787981F16@steffann.nl> <51407F39.2070303@fud.no> Message-ID: > 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 From gert at space.net Sat Mar 16 12:33:35 2013 From: gert at space.net (Gert Doering) Date: Sat, 16 Mar 2013 12:33:35 +0100 Subject: [address-policy-wg] Transfer policy limits In-Reply-To: References: <20130311144709.GC51699@Space.Net> <8122C20F-AFF2-4BF5-AE0F-598787981F16@steffann.nl> <51407F39.2070303@fud.no> Message-ID: <20130316113335.GS51699@Space.Net> 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 From jcurran at arin.net Sat Mar 16 12:49:31 2013 From: jcurran at arin.net (John Curran) Date: Sat, 16 Mar 2013 11:49:31 +0000 Subject: [address-policy-wg] Transfer policy limits In-Reply-To: References: <20130311144709.GC51699@Space.Net> <8122C20F-AFF2-4BF5-AE0F-598787981F16@steffann.nl> <51407F39.2070303@fud.no> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748F9BF1A4@CHAXCH01.corp.arin.net> On Mar 16, 2013, at 7:24 AM, Alex Le Heux 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 From mueller at syr.edu Sun Mar 17 14:32:54 2013 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 17 Mar 2013 13:32:54 +0000 Subject: [address-policy-wg] Transfer policy limits In-Reply-To: References: <20130311144709.GC51699@Space.Net> <8122C20F-AFF2-4BF5-AE0F-598787981F16@steffann.nl> <51407F39.2070303@fud.no> Message-ID: <855077AC3D7A7147A7570370CA01ECD2361FD5@SUEX10-mbx-10.ad.syr.edu> > -----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. From philip.m.rushton at bt.com Mon Mar 18 17:48:56 2013 From: philip.m.rushton at bt.com (philip.m.rushton at bt.com) Date: Mon, 18 Mar 2013 16:48:56 +0000 Subject: [address-policy-wg] 2012-02 Inter RIR IPv4 transfer policy Message-ID: I can't quote right now due to limited mail support, but I want to state support for 2012-02, the inter RIR IPv4 transfer policy". Sent from handheld device Regards Phil Rushton Standards and Numbering Policy Strategy BT Technology Service & Operations, Office:? + 44 (0) 1977 594807 Fax :???? +44 (0) 1908 862698 Email:? philip.m.rushton at bt.com This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 ? From leo.vegoda at icann.org Mon Mar 18 23:58:38 2013 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 18 Mar 2013 15:58:38 -0700 Subject: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished In-Reply-To: <147C692B2643E149B535628F172D56481DF24471@RMI-EXCH.rmidom.intra> References: <51418FB8.1080408@ripe.net> <20130314124647.GI22559@teamix.net> <20130314.141332.341694255.he@uninett.no> <147C692B2643E149B535628F172D56481DF24471@RMI-EXCH.rmidom.intra> Message-ID: <5648A8908CCB564EBF46E2BC904A75B15EFE7B1B40@EXVPMBX100-1.exc.icann.org> Hi, Bertrand MAUJEAN wrote: [...] > A very disappointing side-effect. Is it possible to have IANA derogate to the rule In performing the IANA Functions, ICANN has committed to act in-line with the policies developed by the policy developing communities, as documented in the ASO MoU (http://archive.icann.org/en/aso/aso-mou-29oct04.htm). Policy can be reviewed and revised when areas for improvement are identified. In the case of AS Number allocations, this has already happened with the replacement of the July 2008 policy (http://www.icann.org/en/resources/policy/global-addressing/global-policy-as n-blocks-31jul08-en.htm) with the current September 2010 policy (http://www.icann.org/en/resources/policy/global-addressing/global-policy-as n-blocks-21sep10-en.htm). The 2010 IANA Policy for Allocation of ASN Blocks to Regional Internet Registries creates a deterministic formula. ICANN performs a daily policy analysis based on the data provided by the RIRs on their FTP sites. The analysis for the RIPE NCC is published at: http://stats.research.icann.org/rir/RIPE/ASN/ Kind regards, Leo Vegoda Internet Corporation for Assigned Names & Numbers -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From gert at space.net Tue Mar 19 09:49:42 2013 From: gert at space.net (Gert Doering) Date: Tue, 19 Mar 2013 09:49:42 +0100 Subject: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B15EFE7B1B40@EXVPMBX100-1.exc.icann.org> References: <51418FB8.1080408@ripe.net> <20130314124647.GI22559@teamix.net> <20130314.141332.341694255.he@uninett.no> <147C692B2643E149B535628F172D56481DF24471@RMI-EXCH.rmidom.intra> <5648A8908CCB564EBF46E2BC904A75B15EFE7B1B40@EXVPMBX100-1.exc.icann.org> Message-ID: <20130319084942.GB51699@Space.Net> Hi, On Mon, Mar 18, 2013 at 03:58:38PM -0700, Leo Vegoda wrote: > (http://www.icann.org/en/resources/policy/global-addressing/global-policy-as > n-blocks-21sep10-en.htm). *sigh* Going back, I can see that this was a global policy proposal that came from the RIRs itself (2007-04 in RIPE land), and I can only lament the lack of foresight - on the side of the proposers, and on the side of the responsible AP WG chair (me). http://www.ripe.net/ripe/policies/proposals/2007-04 Allocating 32bit(-only) ASNs in chunks of 1024 and for a time period of 12 months is just needless overhead - it made sense for 16bit ASNs which are quite obviously limited, but for 32bit ASNs, just allocating "enough" (like "all of AS3.* to RIPE NCC") would have been much more wise... OTOH, judging from the successful deployment of a good number of 32bit ASNs in RIPE land, I think we can state that using up the remaining 16bit ASNs now (at least those in the NCC pool) will not "needlessly burn up a valuable resource" - and I assume that IANA will replenish RIPE NCC's pool with a useful mixture of 32bit-only and 16bit chunks... 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5023 bytes Desc: not available URL: From swmike at swm.pp.se Tue Mar 19 09:55:22 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 19 Mar 2013 09:55:22 +0100 (CET) Subject: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished In-Reply-To: <20130319084942.GB51699@Space.Net> References: <51418FB8.1080408@ripe.net> <20130314124647.GI22559@teamix.net> <20130314.141332.341694255.he@uninett.no> <147C692B2643E149B535628F172D56481DF24471@RMI-EXCH.rmidom.intra> <5648A8908CCB564EBF46E2BC904A75B15EFE7B1B40@EXVPMBX100-1.exc.icann.org> <20130319084942.GB51699@Space.Net> Message-ID: On Tue, 19 Mar 2013, Gert Doering wrote: > OTOH, judging from the successful deployment of a good number of 32bit > ASNs in RIPE land, I think we can state that using up the remaining > 16bit ASNs now (at least those in the NCC pool) will not "needlessly > burn up a valuable resource" - and I assume that IANA will replenish > RIPE NCC's pool with a useful mixture of 32bit-only and 16bit chunks... I would support any proposal for policy change to hand out 32 bit ASNs in larger chunks going forward, like 16384 at a time or even higher numbers. It would mean less work for people maintaining programs such as "whois - client for the whois directory service" because any range would last longer. I believe 32bit-ASNs should be handed out in 3-5 year forecasted growth. Doing small chunks just seems like needless overhead. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Tue Mar 19 10:05:54 2013 From: gert at space.net (Gert Doering) Date: Tue, 19 Mar 2013 10:05:54 +0100 Subject: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished In-Reply-To: References: <51418FB8.1080408@ripe.net> <20130314124647.GI22559@teamix.net> <20130314.141332.341694255.he@uninett.no> <147C692B2643E149B535628F172D56481DF24471@RMI-EXCH.rmidom.intra> <5648A8908CCB564EBF46E2BC904A75B15EFE7B1B40@EXVPMBX100-1.exc.icann.org> <20130319084942.GB51699@Space.Net> Message-ID: <20130319090554.GC51699@Space.Net> Hi, On Tue, Mar 19, 2013 at 09:55:22AM +0100, Mikael Abrahamsson wrote: > I would support any proposal for policy change to hand out 32 bit ASNs in > larger chunks going forward, like 16384 at a time or even higher numbers. > It would mean less work for people maintaining programs such as "whois - > client for the whois directory service" because any range would last > longer. I believe 32bit-ASNs should be handed out in 3-5 year forecasted > growth. > > Doing small chunks just seems like needless overhead. I'm not sure it's actually worth it - a global policy proposal is LOTS of work, and need to gain consensus in all the RIRs before it can go into effect. From the last Global Policy interactions with ARIN, most likely their lawyers will see some issue, change some wording, and break the whole thing right away - but even if they would follow common sense this time, it's still a lot of work (someone has to present to all 5 communities, lead the discussions, etc). IANA is free to chop up the ASN space in a reasonable way, so that the RIPE NCC would always receive ASN blocks from "AS3.*" (using the old asdot notation because it nicely reflects the 16+16 boundary) - and I think that RIPE DB maintenance can - and should - be automated for "oh, new chunk of ASNs" well enough so that it's not actually that much work. I still think what we have is reflecting strongly on the "conservation (and bureacratic processes!) above all else!!!" mentality IPv4 and 16bit ASNs brought upon us, but actually changing this particular aspect might not be worth the effort. That said, I won't stand in the way if someone wants to tackle this (and will be happy to help), of course. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From randy at psg.com Tue Mar 19 11:03:24 2013 From: randy at psg.com (Randy Bush) Date: Tue, 19 Mar 2013 12:03:24 +0200 Subject: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished In-Reply-To: <20130319084942.GB51699@Space.Net> References: <51418FB8.1080408@ripe.net> <20130314124647.GI22559@teamix.net> <20130314.141332.341694255.he@uninett.no> <147C692B2643E149B535628F172D56481DF24471@RMI-EXCH.rmidom.intra> <5648A8908CCB564EBF46E2BC904A75B15EFE7B1B40@EXVPMBX100-1.exc.icann.org> <20130319084942.GB51699@Space.Net> Message-ID: >> (http://www.icann.org/en/resources/policy/global-addressing/global-policy-as >> n-blocks-21sep10-en.htm). > *sigh* we have rules, not common sense i am sure we can exchange 42 more messages, three policy proposals, spend time in dublin, ... randy From jcurran at arin.net Tue Mar 19 15:34:02 2013 From: jcurran at arin.net (John Curran) Date: Tue, 19 Mar 2013 14:34:02 +0000 Subject: [address-policy-wg] RIPE NCC to Assign 16-bit ASNs Until ASN Pool is Replenished In-Reply-To: <20130319090554.GC51699@Space.Net> References: <51418FB8.1080408@ripe.net> <20130314124647.GI22559@teamix.net> <20130314.141332.341694255.he@uninett.no> <147C692B2643E149B535628F172D56481DF24471@RMI-EXCH.rmidom.intra> <5648A8908CCB564EBF46E2BC904A75B15EFE7B1B40@EXVPMBX100-1.exc.icann.org> <20130319084942.GB51699@Space.Net> <20130319090554.GC51699@Space.Net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748F9EC0F0@CHAXCH01.corp.arin.net> On Mar 19, 2013, at 5:05 AM, Gert Doering wrote: > > I'm not sure it's actually worth it - a global policy proposal is LOTS > of work, and need to gain consensus in all the RIRs before it can go > into effect. From the last Global Policy interactions with ARIN, most > likely their lawyers will see some issue, change some wording, and break > the whole thing right away - but even if they would follow common sense > this time, it's still a lot of work (someone has to present to all > 5 communities, lead the discussions, etc). Just to keep the discussion reality-based... The last "Global Policy for Allocation of ASN Blocks to the RIRs" actually went through the ARIN region in a prompt and straightforward fashion: - Formal introduction on PPML on 31 August 2009 - AC recommened Board adopt - 24 November 2009 - Adopted by the ARIN Board - 13 January 2010 Furthermore, the staff assessment indicated "Counsel does not see any material legal issues related to this policy." None of this is a predicator of how a revision to the Global ASN allocation policy would proceed, but in terms of Global Policy, it's likely the easiest one to change in short order. The real difficulty I see here is getting the community to actually converge on how they want these 16- and 32- bit ASN pools managed, and the process is completely secondary to the matter... FYI, /John John Curran President and CEO ARIN From emadaio at ripe.net Tue Mar 19 17:00:56 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 19 Mar 2013 17:00:56 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) Message-ID: Dear Colleagues A proposed change to RIPE Document ripe-582, "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/2013-03 We encourage you to review this proposal and send your comments to before 16 April 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC From dogwallah at gmail.com Tue Mar 19 18:39:53 2013 From: dogwallah at gmail.com (McTim) Date: Tue, 19 Mar 2013 13:39:53 -0400 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: I think that perhaps we should all read the latest draft of the RFC2050 update: https://www.ripe.net/ripe/policies/proposals/2013-03 1) Allocation Pool Management: Due to the fixed lengths of IP addresses and AS numbers, the pools from which these resources are allocated are finite. As such, allocations must be made in accordance with the operational needs of those running the networks that make use of these number resources and by taking into consideration pool limitations at the time of allocation. This proposal seems counter to the above, as well as in conflict with 2050 itself. I note the author has tried to provide counter arguments, but to me they are not sufficient to persuade me to support this proposal. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel On Tue, Mar 19, 2013 at 12:00 PM, Emilio Madaio wrote: > > Dear Colleagues > > A proposed change to RIPE Document ripe-582, "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/2013-03 > > We encourage you to review this proposal and send your comments to > before 16 April 2013. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > From james.blessing at despres.co.uk Tue Mar 19 19:07:42 2013 From: james.blessing at despres.co.uk (James Blessing) Date: Tue, 19 Mar 2013 18:07:42 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: On 19 March 2013 16:00, Emilio Madaio wrote: > A proposed change to RIPE Document ripe-582, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. Er, as written I do not support this. Whilst I agree the premise that we have moved from a point of enforced conservation to one of survival of the fittest I suspect this is the wrong way to go about it. Whilst the address being allocated to LIRs could follow this model the assignment of address space to end users should continue on a needs basis. J -- James Blessing 07989 039 476 From jcurran at arin.net Tue Mar 19 19:08:19 2013 From: jcurran at arin.net (John Curran) Date: Tue, 19 Mar 2013 18:08:19 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> On Mar 19, 2013, at 11:39 AM, McTim wrote: > I think that perhaps we should all read the latest draft of the RFC2050 update: > > https://www.ripe.net/ripe/policies/proposals/2013-03 > > 1) Allocation Pool Management: Due to the fixed lengths of IP > addresses and AS numbers, the pools from which these resources > are allocated are finite. As such, allocations must be made > in accordance with the operational needs of those running the > networks that make use of these number resources and by taking > into consideration pool limitations at the time of allocation. McTim - Note that you are referencing an Internet Draft which is only barely announced and yet to be considered by the community. The document is actually lists several additional goals (i.e. Hierarchical Allocation and Registration Accuracy) and they are to be considered as a whole, not taken singularly: "These goals may sometimes conflict with each other or be in conflict with the interests of individual end-users, Internet service providers, or other number resource consumers. Careful analysis, judgment, and cooperation among registry system providers and consumers at all levels via community-developed policies is necessary to find appropriate compromises to facilitate Internet operations." (This is very similar to language in the existing RFC 2050.) I have no view on the policy proposal, either supporting or against, but want to make clear that the RIPE community should decide what is best for it overall and not feel constrained by a reference to just one of these goals (whether from existing or revised RFC2050) FYI, /John John Curran President and CEO ARIN From dogwallah at gmail.com Tue Mar 19 19:43:18 2013 From: dogwallah at gmail.com (McTim) Date: Tue, 19 Mar 2013 14:43:18 -0400 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> Message-ID: Hi John, I had thought I had included a link to it in my ealrler post, but apparently not, so here it is: http://www.ietf.org/id/draft-housley-rfc2050bis-00.txt On Tue, Mar 19, 2013 at 2:08 PM, John Curran wrote: > On Mar 19, 2013, at 11:39 AM, McTim wrote: > >> I think that perhaps we should all read the latest draft of the RFC2050 update: >> >> https://www.ripe.net/ripe/policies/proposals/2013-03 >> >> 1) Allocation Pool Management: Due to the fixed lengths of IP >> addresses and AS numbers, the pools from which these resources >> are allocated are finite. As such, allocations must be made >> in accordance with the operational needs of those running the >> networks that make use of these number resources and by taking >> into consideration pool limitations at the time of allocation. > > McTim - > > Note that you are referencing an Internet Draft which is only > barely announced and yet to be considered by the community. > The document is actually lists several additional goals > (i.e. Hierarchical Allocation and Registration Accuracy) and > they are to be considered as a whole, not taken singularly: agreed, did not mean to imply otherwise, but only meant to highlight (by quoting) the bit that conflicts with this proposal. > > "These goals may sometimes conflict with each other or be in conflict > with the interests of individual end-users, Internet service > providers, or other number resource consumers. Careful analysis, > judgment, and cooperation among registry system providers and > consumers at all levels via community-developed policies is necessary > to find appropriate compromises to facilitate Internet operations." > > (This is very similar to language in the existing RFC 2050.) > > I have no view on the policy proposal, either supporting or against, > but want to make clear that the RIPE community should decide what > is best for it overall and not feel constrained by a reference to > just one of these goals (whether from existing or revised RFC2050) agreed. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From tore at fud.no Tue Mar 19 20:17:46 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 19 Mar 2013 20:17:46 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: <5148B9DA.9000109@fud.no> * McTim > I think that perhaps we should all read the latest draft of the RFC2050 update: > > https://www.ripe.net/ripe/policies/proposals/2013-03 > > 1) Allocation Pool Management: Due to the fixed lengths of IP > addresses and AS numbers, the pools from which these resources > are allocated are finite. As such, allocations must be made > in accordance with the operational needs of those running the > networks that make use of these number resources and by taking > into consideration pool limitations at the time of allocation. > > > This proposal seems counter to the above, as well as in conflict with > 2050 itself. > > I note the author has tried to provide counter arguments, but to me > they are not sufficient to persuade me to support this proposal. Hi McTim, The pool from which all allocations are drawn in the RIPE region is exclusively governed by the ?last /8 policy?, currently found in section 5.6 of the policy document. In a nutshell, it says: ?a single /22 per LIR, no more, no less - regardless of actual operational needs?. 2013-03 does not change the mechanics of this last /8 policy, at least that is not my intention. The proposal does "promote" it to be the main and only allocation policy found in the document, instead of being contained in section 5.6 all by itself - but again, the intention of this change is just editorial cleanup, clarification, and getting rid of defunct policy text - not to actually modify the effective policy. So, in summary, I don't see 2013-03 running any more afoul of the 2050-bis passage you quoted than what the current last /8 policy already have. Best regards, Tore Anderson From tore at fud.no Tue Mar 19 20:31:08 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 19 Mar 2013 20:31:08 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: <5148BCFC.4040902@fud.no> * James Blessing > Whilst the address being allocated to LIRs could follow this model the > assignment of address space to end users should continue on a needs > basis. Hi James, For what it's worth, my opinion is that it will indeed continue in this manner, even if 2013-03 is accepted. The way I see it, this will follow naturally from the depletion state we're in. LIRs know by now that they can no longer come running to the NCC to refill their pools should they run empty, hence they have all the incentive in the world to conserve what they have already been allocated, and therefore only assign to its End Users the space that the End User actually need and can justify. 2013-03 leaves it to the individual LIR to decide on what periods and criteria makes the most sense in each case, though. Should a LIR on the other hand opt not to do so, and assign to its End User the amount of addresses the End User asked for with no limitation, that LIR will realise soon enough that it has done a grave mistake. However, that mistake only hurts that LIR only - you, me, and the rest of the community are not affected by that LIRs mistakes (unlike what we would be if the same thing happened pre-depletion). The upside is that under 2013-03, if you or I get a new customer signing a, say, three-year contract, that leaves no doubt that he has a valid need for addresses in that period - the policy will actually allow us to make that assignment. Best regards, Tore Anderson From gert at space.net Tue Mar 19 23:15:55 2013 From: gert at space.net (Gert Doering) Date: Tue, 19 Mar 2013 23:15:55 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> Message-ID: <20130319221555.GA50861@Space.Net> Hi, On Tue, Mar 19, 2013 at 02:43:18PM -0400, McTim wrote: > http://www.ietf.org/id/draft-housley-rfc2050bis-00.txt I'm not sure whether RFC2050 or this personal draft is very relevant for decisions we do in RIPE community (and I've said so before). I consider the IETF to be not responsible at all anymore for the way the IANA and the RIRs handle IP address and ASN management - they have delegated the space to IANA, and accepted the existance of a bottom-up policy process for the local policies in the respective regions. RFC2050 *itself* acknowledges this in in the IESG note - it describes the *then* best current practice (in 1996). To quote from the Abstract: " This document describes the IP assignment policies currently used by the Regional Registries to implement the guidelines developed by the IANA. The guidelines and these policies are subject to revision at the direction of the IANA. The registry working group (IRE WG) will be discussing these issues and may provide advice to the IANA about possible revisions." it's not saying "the regional registries have to follow RFC2050", but vice versa, RFC2050 describes what the RIRs have been doing at that time, and explains it to the IETF community - which is good and useful, but should not be turned around. Thus, I consider any argument against this proposal solely based on RFC2050 or draft-2050-bis to be about as weak as "we have never done it this way, so we can't start now!" - times have changed, and our IPv4 policy is full of hard-to-explain historic stuff, primarily targeted at a situation that does no longer exist (LIRs justifying the size of their next allocation to the RIPE NCC). Therefore, I'd ask you to give it proper consideration, taking into account the fact that we're out of IPv4 addresses, and that this is not going to change any time soon. (This topic actually has come up at the previous two RIPE meetings when Rob Blokzijl presented his draft of an "IPv4 maintenance policy" - which didn't make it into a formal policy proposal yet, but Tore's proposal effectively does the same thing - leave in the policy document what is still relevant, throw out the rest) 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 From gert at Space.Net Wed Mar 20 14:15:34 2013 From: gert at Space.Net (Gert Doering) Date: Wed, 20 Mar 2013 14:15:34 +0100 Subject: [address-policy-wg] DRAFT agenda for RIPE66 Message-ID: <20130320131534.GA1022@Space.Net> 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 Dublin in the following two time slots: Wednesday, May 15, 09:00 - 10:30 Wednesday, May 15, 11:00 - 12:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". As we're conflicting with both database and DNS, we might have to shift stuff around somewhat more than usual to accomodate conflicts of interest - so if there is something that should be in "the other slot", tell me. If you have anything else you want to see on the agenda, or of we need to change anything, please let us know. 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 - Emilio Madaio - 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 RIPE65 - brief overview over new proposals (if any) D. Feedback From NCC Registration Service - Andrea Cima F. Discussion of open policy proposals 2012-02 Policy for Inter-RIR transfers of IPv4 Address Space 2012-03 Intra-RIR transfer policy proposal 2012-04 (IPv4) PI assignments from the last /8 2013-02 Removal of requirement for certification of reallocated IPv4 addresses ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- G. Discussion of open policy proposals (continued) 2013-03 No Need - Post-Depletion Reality Adjustment and Cleanup 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 -- 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 From gert at space.net Wed Mar 20 14:20:50 2013 From: gert at space.net (Gert Doering) Date: Wed, 20 Mar 2013 14:20:50 +0100 Subject: [address-policy-wg] 2012-03 New Draft Document and Impact Analysis Published (Intra-RIR Transfer Policy Proposal) In-Reply-To: References: Message-ID: <20130320132050.GA3174@Space.Net> Dear AP WG, On Mon, Mar 04, 2013 at 03:26:03PM +0100, Emilio Madaio wrote: > The draft document for the version 3.0 of the proposal 2012-03, > "Intra-RIR Transfers Policy Proposal", 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-03 [..] > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 18 March 2013. *No* comments have been received that could be interpreted as "support" or "opposition" to this proposal. (There was one question which was answered, and one statement from the proposer on the reason for a new version). Based on this, the WG chairs have decided to extend the review phase by 4 more weeks. Emilio will send the announcement later today or tomorrow. If the amount of feedback we receive during those next 4 weeks stays at this, we'll then proceed to kill the proposal due to lack of interest from the community. 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 From ripe.address-policy-wg at ml.karotte.org Wed Mar 20 14:40:14 2013 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Wed, 20 Mar 2013 14:40:14 +0100 Subject: [address-policy-wg] 2012-03 New Draft Document and Impact Analysis Published (Intra-RIR Transfer Policy Proposal) In-Reply-To: <20130304150220.GT51699@Space.Net> References: <20130304150220.GT51699@Space.Net> Message-ID: <20130320134014.GA23502@danton.fire-world.de> * Gert Doering [2013-03-04 16:03]: > Hi, > > On Mon, Mar 04, 2013 at 02:54:53PM +0000, Anfinsen, Ragnar wrote: > > Why do we need this policy change, now that 2012-06 is approved and being implemented? > > It's a different timeline - 2012-06 brought back 12 months, this is for > 24 months. I say keep it simple (and kill 2012-03). With 2012-06 in place we have a 12 months period everywhere. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From gert at space.net Wed Mar 20 14:59:18 2013 From: gert at space.net (Gert Doering) Date: Wed, 20 Mar 2013 14:59:18 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: Message-ID: <20130320135918.GA12787@Space.Net> 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 at 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 From ripe.address-policy-wg at ml.karotte.org Wed Mar 20 15:53:43 2013 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Wed, 20 Mar 2013 15:53:43 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5148BCFC.4040902@fud.no> References: <5148BCFC.4040902@fud.no> Message-ID: <20130320145343.GB23502@danton.fire-world.de> * Tore Anderson [2013-03-19 20:33]: > For what it's worth, my opinion is that it will indeed continue in this > manner, even if 2013-03 is accepted. The way I see it, this will follow > naturally from the depletion state we're in. LIRs know by now that they > can no longer come running to the NCC to refill their pools should they > run empty, hence they have all the incentive in the world to conserve > what they have already been allocated, and therefore only assign to its > End Users the space that the End User actually need and can justify. > 2013-03 leaves it to the individual LIR to decide on what periods and > criteria makes the most sense in each case, though. My first reaction was: Oh god, our sales people will go crazy dishing out the remaining IP space. Right now I can just point to the RIPE regulations and tell them that I need documentation. "LIRs know by now that they can no longer come running to the NCC" I would rephrase that as "Some technicians at the LIR know...". Having said that, I understand that it doesn't make sense for the RIPE NCC to have regulations that are no longer needed just to back internal arguments between IPv4 savvy technicians and sales/management/customers at an LIR. For us I don't see a big problem as I can implement an internal set of rules regulating the assignment of our remaining space. It would help, however, if the RIPE NCC would publish some sort of guidance document on how to establish/document the need for IP addresses. I assume that the RIPE NCC already has something like that for their resource analysts? > Should a LIR on the other hand opt not to do so, and assign to its End > User the amount of addresses the End User asked for with no limitation, > that LIR will realise soon enough that it has done a grave mistake. > However, that mistake only hurts that LIR only - you, me, and the rest > of the community are not affected by that LIRs mistakes (unlike what we > would be if the same thing happened pre-depletion). > > The upside is that under 2013-03, if you or I get a new customer signing > a, say, three-year contract, that leaves no doubt that he has a valid > need for addresses in that period - the policy will actually allow us to > make that assignment. Yes, I also see that the new flexibility could be useful. I support this proposal. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From nigel at titley.com Wed Mar 20 15:54:21 2013 From: nigel at titley.com (Nigel Titley) Date: Wed, 20 Mar 2013 14:54:21 +0000 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published(Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <20130312063757.ec289651d84890fcbef5f195936e1217.c9b039abe7.wbe@email17.secureserver.net> References: <20130312063757.ec289651d84890fcbef5f195936e1217.c9b039abe7.wbe@email17.secureserver.net> Message-ID: <5149CD9D.2050602@titley.com> On 12/03/2013 13:37, sandrabrown at ipv4marketgroup.com wrote: >>> 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? > > Currently the only RIR's with similar transfer policies are ARIN and > APNIC. > As an example, if the LIR is in ARIN region, then the LIR must be in > compliance > with ARIN policy in order to transfer its IPv4 address space to a RIPE > LIR. The > ARIN based LIR would apply to ARIN and request to transfer. (That is > how it works for > ARIN to APNIC transfers today.) ARIN makes sure the LIR has > registration of the > space before making the transfer. > > Similarly, I would expect for a RIPE to ARIN or APNIC transfer RIPE > needs to ensure > that the RIPE LIR has correct registration of the IP space being > transferred. > > > I know what you are trying to say, but I don't think you are actually saying it. An LIR cannot be "in compliance with" an RIR's policy. I think what you are trying to say is that the address space being transferred is being held in compliance with the RIR's policy. And unless this wording is fixed I can't support this policy. I have bitter experience of after-the-event nit picking, confusion and pain in the internet community. Nigel Nigel From tore at fud.no Wed Mar 20 16:51:08 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 20 Mar 2013 16:51:08 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130320145343.GB23502@danton.fire-world.de> References: <5148BCFC.4040902@fud.no> <20130320145343.GB23502@danton.fire-world.de> Message-ID: <5149DAEC.5050608@fud.no> * Sebastian Wiesinger > For us I don't see a big problem as I can implement an internal set of > rules regulating the assignment of our remaining space. It would help, > however, if the RIPE NCC would publish some sort of guidance document > on how to establish/document the need for IP addresses. I assume that > the RIPE NCC already has something like that for their resource > analysts? Hi, Existing LIRs are supposed to have something like this in place already. When an LIR is making an assignment that falls within its assignment window, that LIR alone is responsible for evaluating their End User's need and supporting documentation (and archiving it). Should 2013-03 pass, LIRs are free to continue justifying their assignments using the exact same criteria that they did before. The ripe-583 request form will formally be obsoleted by 2013-03, but that doesn't mean that LIRs can't continue to use it as if nothing happened. Tore From emadaio at ripe.net Wed Mar 20 16:59:31 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 20 Mar 2013 16:59:31 +0100 Subject: [address-policy-wg] 2012-02 Review Period extended until 17 April (Policy for Inter-RIR Transfers of IPv4 Address Space) Message-ID: Dear Colleagues, The Review Period for the proposal 2012-02 has been extended until 17 April. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-02 We encourage you to review this policy proposal and send your comments to before 17 April 2013. Regards, Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Wed Mar 20 17:01:46 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 20 Mar 2013 17:01:46 +0100 Subject: [address-policy-wg] 2012-03 Review Period extended until 17 April 2013 (Intra-RIR Transfer Policy Proposal) Message-ID: Dear Colleagues, The Review Period for the proposal 2012-03 has been extended until 17 April. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-03 We encourage you to review this policy proposal and send your comments to before 17 April 2013. Regards, Emilio Madaio Policy Development Officer RIPE NCC From mueller at syr.edu Wed Mar 20 17:16:52 2013 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 20 Mar 2013 16:16:52 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> This seems like a very well thought-out policy proposal. As the proposal points out, operational need as a criterion for free allocations only makes sense when there is a pool of unallocated addresses to conserve against excessive, unpriced occupation of number blocks. Once that basic fact no longer holds, needs assessments by the RIR serve no necessary function, but they do add bureaucracy, uncertainty, cost and the potential for arbitrariness to the process of re-allocating v4 numbers among competing uses and users. When the definition of need is based on arbitrarily defined and regularly changing time limits (3 months? 1 year? 3 years?) it illustrates how tenuous the process of needs assessment is. In fact, the concept of "need" is always contingent on price, time horizon, expected value, potential substitutes and a number of other economic factors that are best sorted out in the market. Right now, all demand for IPv4 number blocks competes with all current occupiers of the number space and all other prospective occupiers. It is competitive bidding in the market that should resolve who gets what, just as it does with labor, equipment, etc. If someone is willing to pay to extract number blocks from another holder, I don't see that the RIRs need to second-guess whether they need them or not, any more than they ask whether they actually need the amount of office space they are willing to pay for. The only argument I have heard for continued needs assessments comes what I see as unfounded fears of "speculation" and "hoarding." But these are economically driven phenomena. For these to be fatal objections, opponents of this proposal must believe that substantial acquisitions of number blocks would come from parties who have a) no operational use for the numbers and b) no interest in on-selling them efficiently to third parties who do have a use for them. Further, opponents must also believe that c) IPv6 does not constitute a viable intermediate-term option that acts as a constraint on the price of v4 transactions. I reject all three of these premises. I hope RIPE can cement its reputation as the most progressive RIR and pass this. Milton L. Mueller Professor, Syracuse University School of Information Studies Internet Governance Project http://blog.internetgovernance.org From mike at iptrading.com Wed Mar 20 17:42:20 2013 From: mike at iptrading.com (Mike Burns) Date: Wed, 20 Mar 2013 12:42:20 -0400 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need -Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> References: <8DA1853CE466B0 41B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> Message-ID: +1 The RIRs were always stewards of the free pool of addresses, charged with distributing them to those with demonstrated need. This stewardship was a requirement for the allocation of unpriced but scarce resources, to avoid the pitfalls of the Tragedy of the Commons. Upon effective exhaust of the free pool, the steward with the gentlest touch will step back from his stewardship and allow the market to ensure conservation. This is what markets are designed to do, allocate scarce resources efficiently. In addition to conservation, the RIRs were charged with maintaining uniqueness. In order to maintain stewardship of uniqueness, RIPE should simply act as a registrar, registering IPv4 transfers in its Whois directory. Imposing policies which restrict the free trading of addresses will endanger uniqueness as restricted trades continue underground. IPv6 is a barrier to speculators. What could be their plan, to hoard IPv4 addresses with the hope of driving up prices? That would work toward accelerating IPv6 and reducing IPv4 values. There is a natural ceiling to speculation, and there are also a billion IPv4 addresses un-advertised in the routing table. Securing enough IPv4 space to begin dictating pricing would require huge purchases from a large number of disparate sellers, and could not happen quickly or surreptitiously. I was the author of the current ARIN transfer policy, and when I introduced it, I included a limit of a /12, or about a million addresses per year which could be transferred by a single buyer without requiring a needs justification. I included this specifically as an anti-speculation measure, but the ARIN community would not allow any non-needs based transfer, and my proposal was changed to require a needs test for all transfers. This indicated to me that the real bogeyman in the ARIN community wasn't speculators, it was free markets. Is this also a RIPE bogeyman? -----Original Message----- From: Milton L Mueller Sent: Wednesday, March 20, 2013 12:16 PM To: 'address-policy-wg at ripe.net' (address-policy-wg at ripe.net) Subject: Re: [address-policy-wg] 2013-03 New Policy Proposal (No Need -Post-Depletion Reality Adjustment and Cleanup) This seems like a very well thought-out policy proposal. As the proposal points out, operational need as a criterion for free allocations only makes sense when there is a pool of unallocated addresses to conserve against excessive, unpriced occupation of number blocks. Once that basic fact no longer holds, needs assessments by the RIR serve no necessary function, but they do add bureaucracy, uncertainty, cost and the potential for arbitrariness to the process of re-allocating v4 numbers among competing uses and users. When the definition of need is based on arbitrarily defined and regularly changing time limits (3 months? 1 year? 3 years?) it illustrates how tenuous the process of needs assessment is. In fact, the concept of "need" is always contingent on price, time horizon, expected value, potential substitutes and a number of other economic factors that are best sorted out in the market. Right now, all demand for IPv4 number blocks competes with all current occupiers of the number space and all other prospective occupiers. It is competitive bidding in the market that should resolve who gets what, just as it does with labor, equipment, etc. If someone is willing to pay to extract number blocks from another holder, I don't see that the RIRs need to second-guess whether they need them or not, any more than they ask whether they actually need the amount of office space they are willing to pay for. The only argument I have heard for continued needs assessments comes what I see as unfounded fears of "speculation" and "hoarding." But these are economically driven phenomena. For these to be fatal objections, opponents of this proposal must believe that substantial acquisitions of number blocks would come from parties who have a) no operational use for the numbers and b) no interest in on-selling them efficiently to third parties who do have a use for them. Further, opponents must also believe that c) IPv6 does not constitute a viable intermediate-term option that acts as a constraint on the price of v4 transactions. I reject all three of these premises. I hope RIPE can cement its reputation as the most progressive RIR and pass this. Milton L. Mueller Professor, Syracuse University School of Information Studies Internet Governance Project http://blog.internetgovernance.org From swmike at swm.pp.se Wed Mar 20 18:50:09 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 20 Mar 2013 18:50:09 +0100 (CET) Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> Message-ID: On Wed, 20 Mar 2013, Milton L Mueller wrote: > This seems like a very well thought-out policy proposal. +1. I consider free pool of IPv4 depleted. Let everybody sit on their allocations and use them any way they see fit. RIPE role should be to keep the database up to date and accurate. This proposal is a step in the right direction of that. -- Mikael Abrahamsson email: swmike at swm.pp.se From nigel at titley.com Wed Mar 20 18:59:54 2013 From: nigel at titley.com (Nigel Titley) Date: Wed, 20 Mar 2013 17:59:54 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> Message-ID: <5149F91A.5060008@titley.com> On 20/03/2013 16:16, Milton L Mueller wrote: > This seems like a very well thought-out policy proposal. > I never thought to see the day when I would agree with Milton, but in this (one) case he's right. Let's try and get IPv4 out of the system as quickly as possible. It's a legacy protocol. Nigel From aleheux at kobo.com Wed Mar 20 23:42:33 2013 From: aleheux at kobo.com (Alex Le Heux) Date: Wed, 20 Mar 2013 22:42:33 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: Message-ID: <6A970D2A8B029E45826C95E9EEF9317F3692106D@koboexch1> This proposal is a gigantic leap in the right direction. Any future IPv4 policy should describe what to do with PI assignments though, after all they are more numerous than LIR allocations and the fact that the RIPE NCC will not be making any new assignments doesn't mean it won't have to deal with the tens of thousands there are out there in the future. The cleanest, and most radical, solution would of course be to say "addresses are addresses" and do away with the difference between PI and PA and strip all references the "PA" and "PI" from the policy and RIPE DB. Leaving them in limbo is not a good idea. Alex Le Heux Kobo Inc On 2013-03-19 17:00 , "Emilio Madaio" wrote: > >Dear Colleagues > >A proposed change to RIPE Document ripe-582, "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/2013-03 > >We encourage you to review this proposal and send your comments to > before 16 April 2013. > >Regards > >Emilio Madaio >Policy Development Officer >RIPE NCC > > From tore at fud.no Thu Mar 21 08:40:24 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 21 Mar 2013 08:40:24 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <6A970D2A8B029E45826C95E9EEF9317F3692106D@koboexch1> References: <6A970D2A8B029E45826C95E9EEF9317F3692106D@koboexch1> Message-ID: <514AB968.6090102@fud.no> Hi Alex, * Alex Le Heux > This proposal is a gigantic leap in the right direction. Thank you. I hope that the WG chairs and I can interpret this as a voice of support, despite what you write about PI below? > Any future IPv4 policy should describe what to do with PI assignments > [...] > Leaving them in limbo is not a good idea. I want to avoid having my policy proposal fix "everything" at the same time. While it may be tempting to have it fix issues A, B, C, D, E, F, and G in one go, the risk with that is that the community doesn't agree with, say, F - and on that basis alone killing the entire proposal. Therefore I want to limit the scope of changes as much as reasonably possible, so that we can discuss the actual issues only without getting side-tracked over another "nice to have" change that might prove controversial. For what it's worth my primary motivation for submitting the proposal (i.e, the "A" issue, or the itch I'm actually trying to scratch) is to get rid of the need justification bureaucracy relating to making PA assignments. In a nutshell: I know what my customers need for the contract periods they sign up for, and I want to be able to assign that space to them without being constrained by RIPE policies and without having to fill out any RIPE paperwork. The "B" issue it tackles, is getting rid of the need justification bureaucracy for [transfers of] allocations. This is not the main goal, but due to A it would make absolutely no sense to leave it in - otherwise any LIR could just synthesise whatever allocation need they wanted to (without actually running afoul of the policy). The "C" issue fixed by my proposal, the clean-up and restructuring, is due to A and B being so deeply intertwined in so many parts of the policy. I first tried to ?surgically remove? need justification text from all parts of the policy in order to solve A and B, and leave everything else intact, but I soon realised that it was easier to just delete all the old and obsolete sections completely, and (if necessary) replacing them with whatever the currently active policy (i.e., the "last /8" policy) had to say. > The cleanest, and most radical, solution would of course be to say > "addresses are addresses" and do away with the difference between PI and > PA and strip all references the "PA" and "PI" from the policy and RIPE DB. I've heard talk about such a ?PA/PI unification? proposal, at least for IPv6, but I don't think anything was ever actually submitted to the PDP. I would prefer that such a change could be proposed and discussed independently of 2013-03, though. That said: The eventual passing of 2013-03 would be a great benefit to such a proposal, as the amount of policy text that needs to be changed would decrease dramatically. See also: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-October/006496.html Best regards, Tore Anderson From rogerj at gmail.com Thu Mar 21 08:45:12 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Thu, 21 Mar 2013 08:45:12 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: On Tue, Mar 19, 2013 at 5:00 PM, Emilio Madaio wrote: > > Dear Colleagues > > A proposed change to RIPE Document ripe-582, "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/2013-03 > > We encourage you to review this proposal and send your comments to > before 16 April 2013. supported -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From sylvain.vallerot at opdop.net Wed Mar 20 21:16:19 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Wed, 20 Mar 2013 21:16:19 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> Message-ID: <514A1913.8090204@opdop.net> Hi all, please excuse my very stumbling english. On 20/03/2013 17:16, Milton L Mueller wrote: >It is competitive biddingin the market that should resolve who gets what, > The only argument I have heard for continued needs assessments comes what I see as > unfounded fears of "speculation" and "hoarding." But these are economically driven > phenomena. I think Ripe NCC has quite constantly refused to consider IP shoud be considerated as a product one could sell, and rather followed the conversation goal as a way to protect the public ressource. This is what I expect from a non-commercial structure actually, and from a regulator. > For these to be fatal objections, opponents of this proposal must believe > that substantial acquisitions of number blocks would come from parties who have > a) no operational use for the numbers and b) no interest in on-selling them efficiently > to third parties who do have a use for them. Further, opponents must also believe that > c) IPv6 does not constitute a viable intermediate-term option that acts as a constraint > on the price of v4 transactions. I reject all three of these premises. I strongly disagree with this view. First because the fact that some companies have enough money to buy high price ressource does not mean that other companies that have equally legitimate need but less ressources should be less served. Second, because letting this happen would authorize a market of abusively bought addresses develop in the hands of LIRs that so doing would significantly deviate from the Ripe goals that include to avoid waste, and not commercial abuse of a public ressource. Some examples have show already that resellers could buy an IP for 5? and re-sell it for 10 ?. That is 10,000 a /22 i.e. the space one can get buy simply becoming a LIR. This risk is particularly present while allocations reselling is now possible, which makes financial dealing of large IP spaces possible that bypass the IPv4 depletion max /22 allocation rule. I'm sorry but IPv6 does *not* yet represent a viable short-term nor middle-term option for many companies that *do* need IPv4 ressources now, either to establish their activity or to grow, wether they implement IPv6 in dual stack or not. This is a cruel evidence for some of our LIR members today. However since the changes only affect the way LIRs will make use of allocations they already have, and not deregulate the distribution of the remaining space between LIRs nor impact the allocation reselling mechanism, I am not opposed to this "do as you wish with your allocation" move. Nonetheless I feel like the conversation goal should not be completely erased from this policy, and remain. This makes sense also regarding the actual /22 max allocation rule, that *does* obey the conversation goal and should be backed by this principle. I also think the IPv4 policy should not be thought without a global vision of allocations movements and banish financial deals over public ressource. In particular, I think direct LIR to LIR reselling of empty space shoud be forbidden, and of partially occupied space sould be allowed under certain conditions aiming to garantee a business or a service is actually sold (not public ressource). Best regards, Sylvain From tore at fud.no Thu Mar 21 10:29:57 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 21 Mar 2013 10:29:57 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514A1913.8090204@opdop.net> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> Message-ID: <514AD315.7010309@fud.no> Hello Sylvain, * Sylvain Vallerot > I think Ripe NCC has quite constantly refused to consider IP shoud > be considerated as a product one could sell, and rather followed the > conversation goal as a way to protect the public ressource. This is > what I expect from a non-commercial structure actually, and from a > regulator. Two comments on this: 1) The ?public resource? is gone, so there is no longer anything to protect. This happened when the RIPE NCC reached the ?last /8? on the 14th of September last year. While the RIPE NCC strictly speaking still do have space left, it is exclusively governed by the ?last /8 policy?, which 2013-03 does not modify. 2) While the RIPE NCC itself does not consider themselves to be in the business of "selling" IP addresses, the current IPv4 address policy *does* allow for paid LIR-to-LIR transfers of IPv4 allocations. That's the status quo, and 2013-03 does not change it one way or the other. > First because the fact that some companies have enough money to buy > high price ressource does not mean that other companies that have > equally legitimate need but less ressources should be less served. See response #2 above. The status quo today is that, if two LIRs have equally legitimate need for IPv4 addresses, regular market mechanics will be the deciding factor (so in the general case: highest bidder wins). 2013-03 does not change this one way or the other. > Second, because letting this happen would authorize a market of > abusively bought addresses develop in the hands of LIRs that so doing > would significantly deviate from the Ripe goals that include to avoid > waste, and not commercial abuse of a public ressource. Some examples > have show already that resellers could buy an IP for 5? and re-sell > it for 10 ?. That is 10,000 a /22 i.e. the space one can get buy > simply becoming a LIR. Again, see response #2 above. This is already possible with current address policy, and 2013-03 does not change it one way or the other. > Nonetheless I feel like the conversation goal should not be > completely erased from this policy, and remain. This makes sense also > regarding the actual /22 max allocation rule, that *does* obey the > conversation goal and should be backed by this principle. See response #1, 2013-03 does not change the actual /22 max allocation rule. This part of the policy is left intact, the only changes relating to it is of the editorial kind (moving the text from one section to another and rewriting it slightly to improve clarity). > I also think the IPv4 policy should not be thought without a global > vision of allocations movements and banish financial deals over > public ressource. In particular, I think direct LIR to LIR reselling > of empty space shoud be forbidden, and of partially occupied space > sould be allowed under certain conditions aiming to garantee a > business or a service is actually sold (not public ressource). Again, see response #2 above. Current address policy already allows for "direct LIR to LIR reselling of empty space", and 2013-03 does not change this one way or the other. You are of course free to submit a separate policy proposal that would change this, but when it comes to 2013-03, this particular consideration seems to me to be out of scope. Best regards, Tore Anderson From sylvain.vallerot at opdop.net Thu Mar 21 11:40:17 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Thu, 21 Mar 2013 11:40:17 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514AD315.7010309@fud.no> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> Message-ID: <514AE391.8080705@opdop.net> On 21/03/2013 10:29, Tore Anderson wrote: > 1) The ?public resource? is gone, so there is no longer anything to > protect. This happened when the RIPE NCC reached the ?last /8? on the > 14th of September last year. While the RIPE NCC strictly speaking still > do have space left, it is exclusively governed by the ?last /8 policy?, > which 2013-03 does not modify. > 2) While the RIPE NCC itself does not consider themselves to be in the > business of "selling" IP addresses, the current IPv4 address policy > *does* allow for paid LIR-to-LIR transfers of IPv4 allocations. That's > the status quo, and 2013-03 does not change it one way or the other. The public ressource is not "gone" : it was allocated or assigned, but it's still there. And since the Ripe NCC has very few in reserve, this means LIRs now have it all in their hands. I do not see the point that would explain that the "fair" distribution by Ripe NCC should be replaced by a "market-ruled" exchange by LIRs now, since LIRs are supposed to conform to Ripe policies if you relax these policies in excess then you allow LIRs to do whatever they want, whereas they could (should) still be constrained by fair use and correct documentation necessity. It seems obvious to me that LIRs that have empty allocation should not be allowed to sell it but should return it to Ripe NCC that could make it equally available to LIRs that need in on the same fair allocation logic than before. If conservation and documentation requirements are abolished then this "garbage collection" will not occur. And not making this garbage collection means a big waste. This is why i am opposed to the first two principles of this proposal, namely : ? - Remove "Conservation" as a stated goal of the policy. - Removes all active policy text referring to documentation, evaluation of need, and validation of actual usage for both assignments and allocations. ? Maybe this will be possible when IPv6 will be really in place which for the moment is far from being a reality, because IPv4 will not be vital for anybody anymore. > change this one way or the other. You are of course free to submit a > separate policy proposal that would change this, but when it comes to > 2013-03, this particular consideration seems to me to be out of scope. Might come to this yes. Best regards, Sylvain Vallerot From sid at free.net Thu Mar 21 12:18:45 2013 From: sid at free.net (Dimitri I Sidelnikov) Date: Thu, 21 Mar 2013 15:18:45 +0400 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: <514AEC95.4080506@free.net> On Tue, Mar 19, 2013 at 5:00 PM, Emilio Madaio wrote: > Dear Colleagues > > A proposed change to RIPE Document ripe-582, "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/2013-03 > > We encourage you to review this proposal and send your comments to > before 16 April 2013. supported -- Kind regards, --- Dimitri I. Sidelnikov FREEnet Hostmaster From aleheux at kobo.com Thu Mar 21 13:33:58 2013 From: aleheux at kobo.com (Alex Le Heux) Date: Thu, 21 Mar 2013 12:33:58 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514AB968.6090102@fud.no> Message-ID: <6A970D2A8B029E45826C95E9EEF9317F36921AB9@koboexch1> Hi Tore, On 2013-03-21 08:40 , "Tore Anderson" wrote: >>This proposal is a gigantic leap in the right direction. > >Thank you. I hope that the WG chairs and I can interpret this as a voice >of support, despite what you write about PI below? Not so fast? :) >> Any future IPv4 policy should describe what to do with PI assignments >> [...] >> Leaving them in limbo is not a good idea. > >I want to avoid having my policy proposal fix "everything" at the same >time. While it may be tempting to have it fix issues A, B, C, D, E, F, >and G in one go, the risk with that is that the community doesn't agree >with, say, F - and on that basis alone killing the entire proposal. > >Therefore I want to limit the scope of changes as much as reasonably >possible, so that we can discuss the actual issues only without getting >side-tracked over another "nice to have" change that might prove >controversial. [?] I understand that. This is going to be tricky enough to shepherd through the PDP as it is. But, by ignoring PI and cutting it out completely, I do feel that your proposal creates a limbo where there was none before. Questions that will remain unanswered under the proposed policy include, but are probably not limited to: - Is a PI assignment valid as long as the original criteria remain valid? Or is it now valid no matter what happens? - What about transfers of PI? Not allowed? Allowed? If allowed, under which circumstances? - Are sub-assignments now allowed? - Is there a requirement to keep the registration data in the RIPE DB up to date? Even though the RIPE NCC will most likely not assign new PI in the future, these are still issues that its staff will have to deal with, and by extension, we as a community as well. Cheers, Alex Le Heux Kobo Inc From tore at fud.no Thu Mar 21 14:18:28 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 21 Mar 2013 14:18:28 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514AE391.8080705@opdop.net> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> Message-ID: <514B08A4.60902@fud.no> * Sylvain Vallerot > The public ressource is not "gone" : it was allocated or assigned, but > it's still there. The key word here is *public*. The *public* resource is gone. The numbers still exist in *private* pools at the LIR level and below, but the *public* pools (i.e., IANA and RIPE NCC) are empty. Best regards, Tore Anderson From tore at fud.no Thu Mar 21 15:09:54 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 21 Mar 2013 15:09:54 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <6A970D2A8B029E45826C95E9EEF9317F36921AB9@koboexch1> References: <6A970D2A8B029E45826C95E9EEF9317F36921AB9@koboexch1> Message-ID: <514B14B2.4060300@fud.no> Hi Alex, * Alex Le Heux > But, by ignoring PI and cutting it out completely, I do feel that your > proposal creates a limbo where there was none before. > > Questions that will remain unanswered under the proposed policy include, > but are probably not limited to: As I understand it, if something is not explicitly mentioned in the policy, it is by default not permitted. With that in mind, I'll try to answer your points below: > - Is a PI assignment valid as long as the original criteria remain valid? Yes, my proposal does not change or remove the relevant text that states this. See section 6.3. > - What about transfers of PI? Not allowed? Allowed? Not allowed, because no explicit policy that allows it exists. Note that this is also the case in current policy, so my proposal upholds the status quo. > - Are sub-assignments now allowed? Not allowed, because no explicit policy that allows it exists. Note that this is also the case in current policy, so my proposal upholds the status quo. > - Is there a requirement to keep the registration data in the RIPE DB up > to date? Yes, my proposal does not change or remove the relevant text that states this. See sections 3.0 (point 3), 4.0, and 6.3. > Even though the RIPE NCC will most likely not assign new PI in the future, > these are still issues that its staff will have to deal with, and by > extension, we as a community as well. The way I see it, ASSIGNED PI is now simply a historic status, in the exact same way that, e.g., ALLOCATED PI and ASSIGNED ANYCAST is. And it remains documented as such in section 7.0 of the proposed policy. I do not quite see why ASSIGNED PI specifically needs more documentation than those other historic types of delegations. That said, if you can suggest some text to add that would resolve your concerns, I would be very happy to incorporate it into the proposal. Tore From dogwallah at gmail.com Thu Mar 21 15:10:52 2013 From: dogwallah at gmail.com (McTim) Date: Thu, 21 Mar 2013 10:10:52 -0400 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514B08A4.60902@fud.no> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> Message-ID: Hi, On Thu, Mar 21, 2013 at 9:18 AM, Tore Anderson wrote: > * Sylvain Vallerot > >> The public ressource is not "gone" : it was allocated or assigned, but >> it's still there. > > The key word here is *public*. The *public* resource is gone. not entirely, or have I missed that announcement?. > > The numbers still exist in *private* pools at the LIR level and below, > but the *public* pools (i.e., IANA and RIPE NCC) are empty. "empty" in the sense that the red fuel low indicator light on my dashboard has gone on, but my vehicle still runs? I think this proposal actually lengthens the lifetime of v4, in that if an LIR makes a significant investment in v4 resources, they will be more likely to seek the longest ROI possible, thus delaying their v6 adoption. I do understand the arguments in favor, I just don't find them compelling. What is most striking to me is that we had a finite but significant supply of resources in the past, and we doled them out according to operational need. That made sense to me. Eliminate the operational needs requirement during a rationing phase just doesn't make sense to me. I also think that if adopted, this proposal would preclude an inter-RIR transfer market in that the "needs test" is required in the other regions, and that would mean that the RIPE region policies would not be "compatible" as called for in the other regions transfer policies. In other words, does 2013-03 preclude 2012-02 (if adopted) from being effective? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From tore at fud.no Thu Mar 21 15:32:56 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 21 Mar 2013 15:32:56 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> Message-ID: <514B1A18.2080608@fud.no> * McTim >> The key word here is *public*. The *public* resource is gone. > > not entirely, or have I missed that announcement?. Hi McTim, I don't count space covered by the "last /8" policy, if that's what you're alluding to here. This is because my proposal does not change it, and also because allocations made from this space are not sized according to the need principle. The "last /8" policy's "a single /22 per LIR, no more, no less" mechanic makes it impossible for a single LIR to allocate excessively from the space covered by the policy. This was not the case prior to the "last /8" policy - if it wasn't for the need principle, an LIR would have been able to repeatedly go to the NCC and receive space that it could in turn delegate further in an wasteful manner. With the "last /8" policy in effect, however, this safety mechanism is no longer necessary - because no matter how excessively an LIR makes delegations to its end users, it can only receive a single /22 from the space covered by the "last /8" policy, ever. > I think this proposal actually lengthens the lifetime of v4, in that > if an LIR makes a significant investment in v4 resources, they will be > more likely to seek the longest ROI possible, thus delaying their v6 > adoption. I don't understand this argument, could you explain? The amount of IPv4 addresses in existence would remain the same after 2013-03 passes, so it does not remove the depletion state we're in. > I also think that if adopted, this proposal would preclude an > inter-RIR transfer market in that the "needs test" is required in the > other regions, and that would mean that the RIPE region policies would > not be "compatible" as called for in the other regions transfer > policies. > > In other words, does 2013-03 preclude 2012-02 (if adopted) from being effective? Yes and no - it depends on the policy in effect in the other region space is being transferred to or from. I'm not intimately familiar with those, but I *believe* that ARIN would be incompatible, APNIC compatible, and that LACNIC and AfriNIC does not allow for inter-region transfers at all (so 2013-03 would not make any difference for those). Tore From andreas.larsen at ip-only.se Thu Mar 21 15:33:21 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Thu, 21 Mar 2013 15:33:21 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: Message-ID: +1 I do consider the ipv4 pool depleted and let the LIR decide how fast they want to run out themself. // Andreas Larsen Den 2013-03-20 18:50 skrev Mikael Abrahamsson : >On Wed, 20 Mar 2013, Milton L Mueller wrote: > >> This seems like a very well thought-out policy proposal. > >+1. > >I consider free pool of IPv4 depleted. Let everybody sit on their >allocations and use them any way they see fit. RIPE role should be to >keep >the database up to date and accurate. This proposal is a step in the >right >direction of that. > >-- >Mikael Abrahamsson email: swmike at swm.pp.se > From eirik at blixsolutions.no Thu Mar 21 14:56:11 2013 From: eirik at blixsolutions.no (Eirik Hjelle) Date: Thu, 21 Mar 2013 14:56:11 +0100 Subject: [address-policy-wg] Support for 2013-03 Message-ID: <514B117B.3070209@blixsolutions.no> I support 2013-03 by Tore Anderson of Linpro I represent LIR: Blix Group AS LIR: Blix Solutions AS -- Eirik Hjelle CEO ? Blix Solutions AS ? +(47) 21 55 56 66 IP Transit ? Colocation ? Dedicated servers From cfriacas at fccn.pt Thu Mar 21 17:46:24 2013 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 21 Mar 2013 16:46:24 +0000 (WET) Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <20130228131857.B7AC211A563@mx.anubis.local> References: <20130228131857.B7AC211A563@mx.anubis.local> Message-ID: Support. On Thu, 28 Feb 2013, Marco Schmidt wrote: > > Dear Colleagues > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-02/ > > We encourage you to review this proposal and send your comments to > before 28 March 2013. > > Regards > > Marco Schmidt > on behalf of the Policy Development Office > RIPE NCC > > From sandrabrown at ipv4marketgroup.com Thu Mar 21 18:33:52 2013 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Thu, 21 Mar 2013 10:33:52 -0700 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) Message-ID: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-03 > > We encourage you to review this proposal and send your comments to > before 16 April 2013. Support. This goal of 2012-03 was to align the justification period with the other RIR's who allow inter-RIR transfers. Tore's proposal 2013-03 will remove justification altogether, which is what all the RIR's need to do. The reason I went with a 24 month justification period in 2012-03 was because that was the period APNIC and ARIN use. I was hopeful that this would align the RIPE such that when transfers to and from those RIR's were considered, they would be allowed, because the RIPE would have a "like" policy. Tore's policy may have the impact of bringing ALL the RIR's into the current market reality: that when an entity is paying for IP's, that is needs justification enough. There is no hoarding in an unencumbered market. RIPE is demonstrating true world leadership here. Sandra Brown From scottleibrand at gmail.com Thu Mar 21 18:55:45 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 21 Mar 2013 10:55:45 -0700 Subject: [address-policy-wg] 2012-03 Review Period extended until 17 April 2013 (Intra-RIR Transfer Policy Proposal) In-Reply-To: References: Message-ID: I support 2012-03, the proposed Policy for Inter-RIR Transfers of IPv4 Address Space (not Intra-). -Scott On Wed, Mar 20, 2013 at 9:01 AM, Emilio Madaio wrote: > > Dear Colleagues, > > > The Review Period for the proposal 2012-03 has been extended until 17 > April. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2012-03 > > > We encourage you to review this policy proposal and send your comments > to before 17 April 2013. > > Regards, > > Emilio Madaio > Policy Development Officer > RIPE NCC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Thu Mar 21 18:58:09 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 21 Mar 2013 10:58:09 -0700 Subject: [address-policy-wg] 2012-03 Review Period extended until 17 April 2013 (Intra-RIR Transfer Policy Proposal) In-Reply-To: References: Message-ID: Sorry, I was confusing the two simiarly named proposals. I support both 2012-03, the modification of the Intra-RIR Transfer Policy Proposal to allow for 24-month needs justification instead of 3 months, and 2012-02, the proposed Policy for Inter-RIR Transfers of IPv4 Address Space. -Scott On Thu, Mar 21, 2013 at 10:55 AM, Scott Leibrand wrote: > I support 2012-03, the proposed Policy for Inter-RIR Transfers of IPv4 > Address Space (not Intra-). > > -Scott > > > On Wed, Mar 20, 2013 at 9:01 AM, Emilio Madaio wrote: > >> >> Dear Colleagues, >> >> >> The Review Period for the proposal 2012-03 has been extended until 17 >> April. >> >> >> You can find the full proposal at: >> >> https://www.ripe.net/ripe/policies/proposals/2012-03 >> >> >> We encourage you to review this policy proposal and send your comments >> to before 17 April 2013. >> >> Regards, >> >> Emilio Madaio >> Policy Development Officer >> RIPE NCC >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Thu Mar 21 18:52:02 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 21 Mar 2013 10:52:02 -0700 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> Message-ID: While I support the goals of 2013-03 in a post-IPv4-depletion world, we are currently in an uncomfortable intermediate state where IPv4 depletion has occurred in some regions (RIPE and APNIC) but not in others (ARIN, LACNIC, and AfriNIC). I think it will be wise to wait until IPv4 depletion to remove of (at least some) needs requirements in those regions that still have an IPv4 free pool. As a result of the fact of remaining RIR free pools, and the current policy and sentiment in the ARIN region that inter-RIR IPv4 transfers should occur only to organizations/regions that justify need for the addresses (to avoid a run on said free pool), I think it would be wise to do something like this: - First, pass an inter-RIR transfer policy in the RIPE region that is compatible with both the APNIC and ARIN inter-RIR transfer policies (i.e. has some form of needs justification). - Second, make sure that RIPE's transfer policy serves all organizations in the RIPE region, including those who in the past got PI space from RIPE. - Third, relax the ARIN region's inter-RIR transfer policy such that after IPv4 depletion in the ARIN region, transfers are allowed to regions with policies like 2013-03. - Fourth, pass something along the lines of 2013-03 in the RIPE region (to take effect) after IPv4 depletion has occurred in the ARIN region. - Fifth, update policy in other regions as well to align policy with the needs of a post-IPv4-depletion world. I'm more than happy to help drive #3 and eventually #5 in the ARIN region. -Scott On Thu, Mar 21, 2013 at 10:33 AM, wrote: > > You can find the full proposal at: > > > > https://www.ripe.net/ripe/policies/proposals/2013-03 > > > > We encourage you to review this proposal and send your comments to > > before 16 April 2013. > > Support. > > This goal of 2012-03 was to align the justification period with the > other RIR's who allow inter-RIR transfers. Tore's proposal 2013-03 will > remove justification altogether, which is what all the RIR's need to do. > The reason I went with a 24 month justification period in 2012-03 was > because that was the period APNIC and ARIN use. I was hopeful that this > would align the RIPE such that when transfers to and from those RIR's > were considered, they would be allowed, because the RIPE would have a > "like" policy. > > Tore's policy may have the impact of bringing ALL the RIR's into the > current market reality: that when an entity is paying for IP's, that is > needs justification enough. There is no hoarding in an unencumbered > market. RIPE is demonstrating true world leadership here. > > Sandra Brown > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Thu Mar 21 19:01:48 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 21 Mar 2013 11:01:48 -0700 Subject: [address-policy-wg] 2012-03 New Draft Document and Impact Analysis Published (Intra-RIR Transfer Policy Proposal) In-Reply-To: <20130320134014.GA23502@danton.fire-world.de> References: <20130304150220.GT51699@Space.Net> <20130320134014.GA23502@danton.fire-world.de> Message-ID: Since IMO we still have to have needs assessment for transfers (to allow for inter-RIR transfers), I think it makes sense to allow organizations seeking a transfer to justify their need over a timeframe that is reasonable for business planning, so I support a change to 24 months for transfers. But either way, what's probably more important is that we adopt an inter-RIR transfer policy. -Scott On Wed, Mar 20, 2013 at 6:40 AM, Sebastian Wiesinger < ripe.address-policy-wg at ml.karotte.org> wrote: > * Gert Doering [2013-03-04 16:03]: > > Hi, > > > > On Mon, Mar 04, 2013 at 02:54:53PM +0000, Anfinsen, Ragnar wrote: > > > Why do we need this policy change, now that 2012-06 is approved and > being implemented? > > > > It's a different timeline - 2012-06 brought back 12 months, this is for > > 24 months. > > I say keep it simple (and kill 2012-03). With 2012-06 in place we have > a 12 months period everywhere. > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE > SCYTHE. > -- Terry Pratchett, The Fifth Elephant > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Thu Mar 21 23:30:26 2013 From: sander at steffann.nl (Sander Steffann) Date: Thu, 21 Mar 2013 23:30:26 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514B1A18.2080608@fud.no> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> Message-ID: Hi, >> I also think that if adopted, this proposal would preclude an >> inter-RIR transfer market in that the "needs test" is required in the >> other regions, and that would mean that the RIPE region policies would >> not be "compatible" as called for in the other regions transfer >> policies. >> >> In other words, does 2013-03 preclude 2012-02 (if adopted) from being effective? > > Yes and no - it depends on the policy in effect in the other region > space is being transferred to or from. I'm not intimately familiar with > those, but I *believe* that ARIN would be incompatible Voluntary evaluation of need? It would be a service from the NCC. Something like: you don't need to prove need for the NCC, but if you want advice/evaluation the NCC will assist you and perform the needs based analysis. The NCC has a lot of expertise in this area. Even when showing/documenting need is not required anymore that knowledge could benefit LIRs. It could be useful for new LIRs that need a bit of guidance when assigning addresses to customers. And the NCC doing a "needs test" might make ARIN happy when doing transfers. (I just know that John will reply to this statement ;-) Cheers, Sander From farmer at umn.edu Fri Mar 22 01:00:40 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 21 Mar 2013 19:00:40 -0500 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> Message-ID: <514B9F28.3020001@umn.edu> On 3/21/13 17:30 , Sander Steffann wrote: > Hi, > >>> I also think that if adopted, this proposal would preclude an >>> inter-RIR transfer market in that the "needs test" is required in the >>> other regions, and that would mean that the RIPE region policies would >>> not be "compatible" as called for in the other regions transfer >>> policies. >>> >>> In other words, does 2013-03 preclude 2012-02 (if adopted) from being effective? >> >> Yes and no - it depends on the policy in effect in the other region >> space is being transferred to or from. I'm not intimately familiar with >> those, but I *believe* that ARIN would be incompatible > > Voluntary evaluation of need? It would be a service from the NCC. Something like: you don't need to prove need for the NCC, but if you want advice/evaluation the NCC will assist you and perform the needs based analysis. The NCC has a lot of expertise in this area. Even when showing/documenting need is not required anymore that knowledge could benefit LIRs. It could be useful for new LIRs that need a bit of guidance when assigning addresses to customers. My understanding of the intent of the ARIN's policy is NO that would not be acceptable, and such scenarios did come up during the ARIN community's discussion of Inter-RIR transfers. If it were acceptable, then someone with operational need could apply to transfer resource from the ARIN region and then transfer them to someone else without operational need once the resources were in the RIPE region, and out of ARIN's control. Rinse, repeat. If this were found to be acceptable, I highly expect there would be a policy proposal in the ARIN region to plug the leak, so to speak. The RIPE region is free to manage the resources under its control as it see fit. But so is the ARIN region, and deciding under what circumstances resources can be transferred out of a region is a perfectly reasonable exercise of such control. I will say there are good points and reasonable objections on both sides of this argument. There are those that are flat out opposed to a transfer market under any circumstances, and there are those that oppose any interference with the market. Operational need, has been the fundamental tenet of address assignment policy all the way back to the beginning. Even when whole class-As (/8s today) were handed out it was by operational need, there was a completely different definition of operational need than we use today, but there was operational need. Finally, my suggestion is operational need is should be maintained as the basis for IP address assignments, but how we measure and define that operational need should be carefully reviewed and probably evolve in light of IPv4 run-out. We were burning through class-Bs (/16s today) back in the mid 90's, so we decided we needed a new functional definition for operational need. We came up with slow-start and allocation windows based on historical use. With IPv6 we created a completely different definition for operational need too. Nothing says we can't find a new functional definition for operational need that meets the operational realities in the face of IPv4 run-out. I neither support or oppose the policy, as I do not represent any resources used within the RIPE region. Thanks. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From sander at steffann.nl Fri Mar 22 01:50:17 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 22 Mar 2013 01:50:17 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514B9F28.3020001@umn.edu> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514B9F28.3020001@umn.edu> Message-ID: <98FA51E9-C8A6-4AD0-B2B2-CB6BC7C1A61F@steffann.nl> Hi David, > My understanding of the intent of the ARIN's policy is NO that would not be acceptable, and such scenarios did come up during the ARIN community's discussion of Inter-RIR transfers. If it were acceptable, then someone with operational need could apply to transfer resource from the ARIN region and then transfer them to someone else without operational need once the resources were in the RIPE region, and out of ARIN's control. Rinse, repeat. If this were found to be acceptable, I highly expect there would be a policy proposal in the ARIN region to plug the leak, so to speak. I think a realistic approach could also be to add: 'organisations that transfer IPv4 addresses to other organisations thereby show that they have no need of additional address space for 12 months. When asking the NCC for an evaluation of need the NCC will give a negative answer during this period' In other words: if you sell address space you obviously don't need it. If this WG wants 2013-03 and transfers from ARIN are the only argument against 2013-03 then it might be a solution to add this bit of (IMHO) common sense for those who want to transfer addresses from the ARIN region. But I am just suggesting options for the WG. I'll stay out of the discussion and let the community (to all who are reading this: that includes you!) decide :-) Cheers, Sander From tore at fud.no Fri Mar 22 06:34:25 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 22 Mar 2013 06:34:25 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <98FA51E9-C8A6-4AD0-B2B2-CB6BC7C1A61F@steffann.nl> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514B9F28.3020001@umn.edu> <98FA51E9-C8A6-4AD0-B2B2-CB6BC7C1A61F@steffann.nl> Message-ID: <514BED61.2020804@fud.no> * Sander Steffann > I think a realistic approach could also be to add: 'organisations > that transfer IPv4 addresses to other organisations thereby show that > they have no need of additional address space for 12 months. When > asking the NCC for an evaluation of need the NCC will give a negative > answer during this period' > > In other words: if you sell address space you obviously don't need > it. > > If this WG wants 2013-03 and transfers from ARIN are the only > argument against 2013-03 then it might be a solution to add this bit > of (IMHO) common sense for those who want to transfer addresses from > the ARIN region. FWIW, the proposed policy contains the following (carried over from current policy): ?LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation.? I believe that in practice, this will mean most, if not all, LIRs that obtain address space through transfers will have an operational need for the space. My reasoning for that is that if they don't intend to use the addresses themselves, why would they go through the trouble to actually obtain them, if they are going to be stuck with them for a long time? After all, businesses are loath to spend money on stuff that's useless for them. That said, I doubt that this resolves the ARIN incompatibility. Tore From randy at psg.com Fri Mar 22 06:56:54 2013 From: randy at psg.com (Randy Bush) Date: Fri, 22 Mar 2013 07:56:54 +0200 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514B9F28.3020001@umn.edu> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514B9F28.3020001@umn.edu> Message-ID: > The RIPE region is free to manage the resources under its control as it > see fit. http://en.wikipedia.org/wiki/Noblesse_oblige From tore at fud.no Fri Mar 22 07:24:53 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 22 Mar 2013 07:24:53 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> Message-ID: <514BF935.4040003@fud.no> Hello Scott, * Scott Leibrand > While I support the goals of 2013-03 in a post-IPv4-depletion world, we > are currently in an uncomfortable intermediate state where IPv4 > depletion has occurred in some regions (RIPE and APNIC) but not in > others (ARIN, LACNIC, and AfriNIC). I think it will be wise to wait > until IPv4 depletion to remove of (at least some) needs requirements in > those regions that still have an IPv4 free pool. Geoff Huston's http://www.potaroo.net/tools/ipv4/index.html projects that global IPv4 depletion won't happen until July 2020, when AfriNIC is set to deplete as the last of the five RIRs. That is a *long* time to keep around a bureaucracy that no longer serves any purpose. > As a result of the fact of remaining RIR free pools, and the current > policy and sentiment in the ARIN region that inter-RIR IPv4 transfers > should occur only to organizations/regions that justify need for the > addresses (to avoid a run on said free pool), I think it would be wise > to do something like this: > > - First, pass an inter-RIR transfer policy in the RIPE region that is > compatible with both the APNIC and ARIN inter-RIR transfer policies > (i.e. has some form of needs justification). > - Second, make sure that RIPE's transfer policy serves all > organizations in the RIPE region, including those who in the past got PI > space from RIPE. > - Third, relax the ARIN region's inter-RIR transfer policy such that > after IPv4 depletion in the ARIN region, transfers are allowed to > regions with policies like 2013-03. > - Fourth, pass something along the lines of 2013-03 in the RIPE region > (to take effect) after IPv4 depletion has occurred in the ARIN region. > - Fifth, update policy in other regions as well to align policy with > the needs of a post-IPv4-depletion world. > > I'm more than happy to help drive #3 and eventually #5 in the ARIN region. While I see and acknowledge that 2013-03 conflicts with ARIN's need requirement for inter-region transfers, and that this is a valid argument against the proposed policy, I do feel that this argument alone is not strong enough to to stop 2013-03, for the following reasons: 1) It is entirely dependent on proposal 2012-02 passing, which is far from a certainty. 2012-02 has received at best a lukewarm response from the community - according to the chairs, it has, quote, ?far from consensus?. Should 2012-02 not pass, 2013-03's conflict with ARIN's need requirement is completely irrelevant. 2) According to Ingrid Wijte's MENOG12 presentation (http://www.menog.org/presentations/menog-12/127-IPv4_Transfers-RIPE_NCC_Update.pdf), there have been only a measly 17 permanent transfers in the RIPE region in the last three months. It would surprise me greatly if the amount of assignments having been made by the LIRs in the same period is not at least two orders of magnitude more. Choosing to uphold the need justification and documentation bureaucracy for all those assignments that we LIRs perform on a frequent basis, for the sole purpose of allowing only one specific flavour of the very rarely used allocation transfer mechanism to work, seems to me to fail a very basic cost-benefit analysis. 3) The RIPE community's benefit of allowing transfers from the ARIN region into the RIPE region is only obvious due to the fact that ARIN still has remaining free space in their address pool. ?They've still got more space, let's go grab as much of it as we can before it's all gone!? It is not certain that it is a net benefit to the RIPE community to allow transfers with depleted regions. The result may very well be that more address space is being transferred *out* of our region, than what is coming in - further exacerbating our depletion ordeal. This uncertainty makes the cost-benefit analysis I mentioned in #2 even more clear in favour of 2013-03. According to Geoff Huston, ARIN looks set to deplete exactly one year from now. Keeping in mind that 2012-02 appears to still have a long way to go in the PDP, the time period during which the benefit of allowing free trade with ARIN is obvious is only going to be a few months at most. Quite possibly, ARIN will deplete before 2012-02 gets implemented, if so the obvious beneficial period will not exist at all. 4) Again, ARIN is soon depleting. As I mentioned in the proposal itself, this might cause the ARIN community to do a reality adjustment similar to 2013-03, and rescind the need requirement for inter-region transfers. After all, there is little point in trying to prevent other regions from "bleeding them dry" if they have nothing left anyway. So that's your item #3, essentially. If you're willing to suggest that to the ARIN community now, I'm all for it. Best regards, Tore Anderson From tore at fud.no Fri Mar 22 07:53:37 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 22 Mar 2013 07:53:37 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: Message-ID: <514BFFF1.1050007@fud.no> > https://www.ripe.net/ripe/policies/proposals/2012-02 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.html 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.html 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 From jcurran at arin.net Fri Mar 22 11:34:52 2013 From: jcurran at arin.net (John Curran) Date: Fri, 22 Mar 2013 10:34:52 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA0F0A4@CHAXCH01.corp.arin.net> On Mar 21, 2013, at 6:30 PM, Sander Steffann wrote: > Voluntary evaluation of need? It would be a service from the NCC. Something like: you don't need to prove need for the NCC, but if you want advice/evaluation the NCC will assist you and perform the needs based analysis. The NCC has a lot of expertise in this area. Even when showing/documenting need is not required anymore that knowledge could benefit LIRs. It could be useful for new LIRs that need a bit of guidance when assigning addresses to customers. > > And the NCC doing a "needs test" might make ARIN happy when doing transfers. (I just know that John will reply to this statement ;-) ARIN's Inter-RIR transfer policy can only happen to an RIR which shares a "reciprocal, compatible, needs-based policy". A voluntary mechanism does not equate to a "needs-based" policy, so we would have a conflict. As noted by others on this list, there is nothing fundamentally wrong about such a conflict, other than the fact that it would mean additional discussion in both regions about the value of alignment and options for getting there. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Fri Mar 22 12:08:34 2013 From: jcurran at arin.net (John Curran) Date: Fri, 22 Mar 2013 11:08:34 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514BF935.4040003@fud.no> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <514BF935.4040003@fud.no> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA0F382@CHAXCH01.corp.arin.net> On Mar 22, 2013, at 2:24 AM, Tore Anderson wrote: > 3) The RIPE community's benefit of allowing transfers from the ARIN > region into the RIPE region is only obvious due to the fact that ARIN > still has remaining free space in their address pool. ?They've still got > more space, let's go grab as much of it as we can before it's all gone!? > > It is not certain that it is a net benefit to the RIPE community to > allow transfers with depleted regions. The result may very well be that > more address space is being transferred *out* of our region, than what > is coming in - further exacerbating our depletion ordeal. This > uncertainty makes the cost-benefit analysis I mentioned in #2 even more > clear in favour of 2013-03. > > According to Geoff Huston, ARIN looks set to deplete exactly one year > from now. Keeping in mind that 2012-02 appears to still have a long way > to go in the PDP, the time period during which the benefit of allowing > free trade with ARIN is obvious is only going to be a few months at > most. Quite possibly, ARIN will deplete before 2012-02 gets implemented, > if so the obvious beneficial period will not exist at all. I am not advocating for a policy outcome one way or the other, but should also note that there is a significant amount of early address assignments in the ARIN region (e.g. those that were classsful and done in 80's and early 90's) which may still be underutilized and therefore (with some effort) could become available as parties decide if renumbering down to free up some of the remainder is worthwhile. This is independent of the space being issued from ARIN's free pool, and hence is relevant even after depletion of the free pool in the ARIN region. Also note that source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request (this restriction does not include M&A transfers), so parties issued space from ARIN's free pool between now and its depletion are not likely to be able to make use of the Inter-RIR transfer policy in any case. FYI, /John John Curran President and CEO ARIN From sandrabrown at ipv4marketgroup.com Fri Mar 22 18:54:05 2013 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Fri, 22 Mar 2013 10:54:05 -0700 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published(Policy for Inter-RIR Transfers of IPv4 Address Space) (Tore Anderson) Message-ID: <20130322105405.ec289651d84890fcbef5f195936e1217.e89001d9e4.wbe@email17.secureserver.net> >>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.html >>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.html >>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 From tore at fud.no Sat Mar 23 13:43:19 2013 From: tore at fud.no (Tore Anderson) Date: Sat, 23 Mar 2013 13:43:19 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA0F382@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <514BF935.4040003@fud.no> <8DA1853CE466B041B104C1CAEE00B3748FA0F382@CHAXCH01.corp.arin.net> Message-ID: <514DA367.1050402@fud.no> * John Curran > I am not advocating for a policy outcome one way or the other, but > should also note that there is a significant amount of early address > assignments in the ARIN region (e.g. those that were classsful and > done in 80's and early 90's) which may still be underutilized and > therefore (with some effort) could become available as parties decide > if renumbering down to free up some of the remainder is worthwhile. > This is independent of the space being issued from ARIN's free pool, > and hence is relevant even after depletion of the free pool in the > ARIN region. Hi John, Absolutely. Wile there's also underutilised allocations in the RIPE region too, I have no problems accepting that there are more of them in the ARIN region. However, there *is* a connection to the ARIN free pool here. Its continued existence ensures there is a (almost) gratis way of obtaining IPv4 addresses for LIRs in the ARIN region, which in itself is going to limit the price ARIN region buyers are willing to pay other LIRs for their second-hand IPv4 addresses. When the ARIN free pool depletes, however, ARIN region LIRs seeking IPv4 space will be *forced* to obtain it on the second-hand market, just as APNIC and RIPE region LIRs are today. This might drive up the price they're willing to pay. And if it turns out that the price the market is willing for pay for IPv4 addresses in the ARIN region is higher than it is in the RIPE region (or the APNIC region for that matter), it is no certainty that the inter-region balance of trade for the RIPE region will be that there are more addresses coming in than there are going out. Note that I'm not saying that this *will* happen though - just that it is very hard to predict what the future holds - as it depends on a number of uncertain factors, including for example the level of IPv6 deployment in the various regions. Nor do I believe that the RIPE community should only participate in inter-region trading if we can somehow ascertain that we will be the "market winners". I believe that free trade is inherently a good thing. But - as with everything else in life, it boils down to comparing the pros and cons of doing something - and IMHO the potential pros of being able to trade IPv4 with the ARIN region are greatly outweighed by the cons of upholding the otherwise pointless assignment need bureaucracy and resulting operational overhead in the day to day operations of the LIRs in our region. Best regards, -- Tore Anderson From Ragnar.Anfinsen at altibox.no Sun Mar 24 13:23:16 2013 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Sun, 24 Mar 2013 12:23:16 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: Message-ID: Support /Ragnar On 19.03.13 17:00, "Emilio Madaio" wrote: > >Dear Colleagues > >A proposed change to RIPE Document ripe-582, "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/2013-03 > >We encourage you to review this proposal and send your comments to > before 16 April 2013. > >Regards > >Emilio Madaio >Policy Development Officer >RIPE NCC > > > From gert at space.net Sun Mar 24 17:27:35 2013 From: gert at space.net (Gert Doering) Date: Sun, 24 Mar 2013 17:27:35 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA0F382@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <514BF935.4040003@fud.no> <8DA1853CE466B041B104C1CAEE00B3748FA0F382@CHAXCH01.corp.arin.net> Message-ID: <20130324162735.GS51699@Space.Net> Hi, On Fri, Mar 22, 2013 at 11:08:34AM +0000, John Curran wrote: > I am not advocating for a policy outcome one way or the other, but should > also note that there is a significant amount of early address assignments > in the ARIN region (e.g. those that were classsful and done in 80's and > early 90's) Do these fall under ARIN policy? (ERX space handed out before the existance of the RIRs and then transferred to the RIPE NCC as part of documentation cleanup does *not* fall under RIPE address policy) 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 From dogwallah at gmail.com Sun Mar 24 17:32:32 2013 From: dogwallah at gmail.com (McTim) Date: Sun, 24 Mar 2013 12:32:32 -0400 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130324162735.GS51699@Space.Net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <514BF935.4040003@fud.no> <8DA1853CE466B041B104C1CAEE00B3748FA0F382@CHAXCH01.corp.arin.net> <20130324162735.GS51699@Space.Net> Message-ID: Hi Gert, On Sun, Mar 24, 2013 at 12:27 PM, Gert Doering wrote: > Hi, > > On Fri, Mar 22, 2013 at 11:08:34AM +0000, John Curran wrote: >> I am not advocating for a policy outcome one way or the other, but should >> also note that there is a significant amount of early address assignments >> in the ARIN region (e.g. those that were classsful and done in 80's and >> early 90's) > > Do these fall under ARIN policy? > > (ERX space handed out before the existance of the RIRs and then transferred > to the RIPE NCC as part of documentation cleanup does *not* fall under > RIPE address policy) If this is the case, then why does https://www.ripe.net/ripe/policies/proposals/2012-02 say: "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA." ? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From jcurran at arin.net Sun Mar 24 17:36:00 2013 From: jcurran at arin.net (John Curran) Date: Sun, 24 Mar 2013 16:36:00 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130324162735.GS51699@Space.Net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <514BF935.4040003@fud.no> <8DA1853CE466B041B104C1CAEE00B3748FA0F382@CHAXCH01.corp.arin.net> <20130324162735.GS51699@Space.Net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA2672C@CHAXCH01.corp.arin.net> On Mar 24, 2013, at 12:27 PM, Gert Doering wrote: > On Fri, Mar 22, 2013 at 11:08:34AM +0000, John Curran wrote: >> I am not advocating for a policy outcome one way or the other, but should >> also note that there is a significant amount of early address assignments >> in the ARIN region (e.g. those that were classsful and done in 80's and >> early 90's) > > Do these fall under ARIN policy? All address space in the ARIN region falls under ARIN policy. We do not presently have any policies which provide different treatment for early registrations, but we are not precluded from adopting such if desired by the community. FYI, /John John Curran President and CEO ARIN From info at leadertelecom.ru Sun Mar 24 20:17:34 2013 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Sun, 24 Mar 2013 23:17:34 +0400 Subject: [address-policy-wg] [Ticket#2013031901001932] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cle [...] In-Reply-To: References: Message-ID: <1364152653.505723.179896458.290643.2@otrs.hostingconsult.ru> I support. -- Alexey Ivanov LeaderTelecom ? 19.03.2013 20:01 - Emilio Madaio ???????(?): Dear Colleagues A proposed change to RIPE Document ripe-582, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: ????[1]https://www.ripe.net/ripe/policies/proposals/2013-03 We encourage you to review this proposal and send your comments to before 16 April 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC [1] https://www.ripe.net/ripe/policies/proposals/2013-03 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sun Mar 24 20:38:22 2013 From: sander at steffann.nl (Sander Steffann) Date: Sun, 24 Mar 2013 23:38:22 +0400 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <514BF935.4040003@fud.no> <8DA1853CE466B041B104C1CAEE00B3748FA0F382@CHAXCH01.corp.arin.net> <20130324162735.GS51699@Space.Net> Message-ID: <03A9D8EC-C410-4110-8CC5-95670795F146@steffann.nl> Hi, >> (ERX space handed out before the existance of the RIRs and then transferred >> to the RIPE NCC as part of documentation cleanup does *not* fall under >> RIPE address policy) > > If this is the case, then why does > https://www.ripe.net/ripe/policies/proposals/2012-02 say: > > "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 > address space that were previously allocated to them by either the > RIPE NCC or the IANA." > > ? There are cases where organisations got early registration addresses from IANA, and then afterwards voluntarily registered those resources under their LIR, thereby allowing the RIPE NCC to apply RIPE policies to those resources. So the resources are never allocated by the RIPE NCC but still follow RIPE policy. The text you quote accommodates that. Cheers, Sander From gert at space.net Sun Mar 24 21:34:31 2013 From: gert at space.net (Gert Doering) Date: Sun, 24 Mar 2013 21:34:31 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <514BF935.4040003@fud.no> <8DA1853CE466B041B104C1CAEE00B3748FA0F382@CHAXCH01.corp.arin.net> <20130324162735.GS51699@Space.Net> Message-ID: <20130324203431.GU51699@Space.Net> Hi, On Sun, Mar 24, 2013 at 12:32:32PM -0400, McTim wrote: > On Sun, Mar 24, 2013 at 12:27 PM, Gert Doering wrote: > > (ERX space handed out before the existance of the RIRs and then transferred > > to the RIPE NCC as part of documentation cleanup does *not* fall under > > RIPE address policy) > > If this is the case, then why does > https://www.ripe.net/ripe/policies/proposals/2012-02 say: > > > "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 > address space that were previously allocated to them by either the > RIPE NCC or the IANA." > > ? Well, to be precise, that's not something 2012-02 adds, but is in the policy text since transfers have been added. (2012-02 rephrases the first sentence of the second paragraph of 5.5, which this is not) I can only speculate on the original author's motives, but I think it's not wrong to *permit* something which might become relevant eventually, should an ERX holder decide to bring their address space "under the umbrella of the RIPE NCC", however the specifics might look like, 10 years later... (ncc-services is working on a proposal for interaction between the early address holders and the RIPE NCC). 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Sun Mar 24 21:35:53 2013 From: gert at space.net (Gert Doering) Date: Sun, 24 Mar 2013 21:35:53 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA2672C@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <514BF935.4040003@fud.no> <8DA1853CE466B041B104C1CAEE00B3748FA0F382@CHAXCH01.corp.arin.net> <20130324162735.GS51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA2672C@CHAXCH01.corp.arin.net> Message-ID: <20130324203553.GV51699@Space.Net> Hi, On Sun, Mar 24, 2013 at 04:36:00PM +0000, John Curran wrote: > > Do these fall under ARIN policy? > All address space in the ARIN region falls under ARIN policy. How did you get address space holders that never had a contract with ARIN to agree to ARIN policy? (Genuinely interested, as we have some slight issues with that topic over here :-) ) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From jcurran at arin.net Sun Mar 24 21:57:31 2013 From: jcurran at arin.net (John Curran) Date: Sun, 24 Mar 2013 20:57:31 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130324203553.GV51699@Space.Net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <514BF935.4040003@fud.no> <8DA1853CE466B041B104C1CAEE00B3748FA0F382@CHAXCH01.corp.arin.net> <20130324162735.GS51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA2672C@CHAXCH01.corp.arin.net> <20130324203553.GV51699@Space.Net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA27BD7@CHAXCH01.corp.arin.net> On Mar 24, 2013, at 4:35 PM, Gert Doering wrote: > On Sun, Mar 24, 2013 at 04:36:00PM +0000, John Curran wrote: >> >> All address space in the ARIN region falls under ARIN policy. > > How did you get address space holders that never had a contract with > ARIN to agree to ARIN policy? Gert - IP address holders, regardless of their history, do not "agree to" specific policies developed in any region... What they do is agree to participate in the Registry System and be subject to the policies developed by each community as a result. In more recent years, this has been through formal contracts where possible, but even a party that does not have a formal contract can chose to participate or not. You can use any numbers you want in your routers, but if you wish to use numbers which are unique per the Internet Registry system, then you are participating in the Internet Registry system, gaining the benefits thereof, and therefore are subject to the policies used in its coordination & operation. Hope this helps! /John John Curran President and CEO ARIN From sylvain.vallerot at opdop.net Fri Mar 22 21:08:16 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Fri, 22 Mar 2013 21:08:16 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514B1A18.2080608@fud.no> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> Message-ID: <514CBA30.7060604@opdop.net> On 21/03/2013 15:32, Tore Anderson wrote: > This was not the case prior to the "last /8" policy - if it wasn't for > the need principle, an LIR would have been able to repeatedly go to the > NCC and receive space that it could in turn delegate further in an > wasteful manner. With the "last /8" policy in effect, however, this > safety mechanism is no longer necessary - because no matter how > excessively an LIR makes delegations to its end users, it can only > receive a single /22 from the space covered by the "last /8" policy, ever. But they can also reveive much bigger spaces from buying them. Then they will no be constrained anymore by the fair use policy. So what could happen is that large IP spaces get sold and used thus exceeding very much the simple /22 spaces you mention. Maybe sometimes "fair use" users could even be moved away to make spaces available for selling in the worst cases (I know this is a very pessimistic example but I'm pretty sure it will happen). Less dramatically never decreasing cases of "for money" or simply "bad" assignments will occur, just like entropy does (quantity of mess in a natural system). I believe a good policy should ensure free space returns to available pool for fair use needs, but since allocation transfer is allowed it should not be an allowed bypass of such a fair policy. With time, users and LIRs will just stop using IPv4, but until this happens I believe we need fair use and conservation principle. NB: "private" space does not exist for me : internet *is* public, all of it, and ressources are delegated to LIRs, then users, but not owned by them. From tore at fud.no Mon Mar 25 10:22:06 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 25 Mar 2013 10:22:06 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514CBA30.7060604@opdop.net> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514CBA30.7060604@opdop.net> Message-ID: <5150173E.8080809@fud.no> Hi Sylvain, * Sylvain Vallerot > But they can also reveive much bigger spaces from buying them. Then > they will no be constrained anymore by the fair use policy. > > So what could happen is that large IP spaces get sold and used thus > exceeding very much the simple /22 spaces you mention. Maybe sometimes > "fair use" users could even be moved away to make spaces available > for selling in the worst cases (I know this is a very pessimistic > example but I'm pretty sure it will happen). Less dramatically never > decreasing cases of "for money" or simply "bad" assignments will > occur, just like entropy does (quantity of mess in a natural system). Yes, under the proposed policy it would be technically possible for an LIR to obtain (through transfers) a larger amount of address space than they have an operational need for. However, is this going to be a problem? Realistically? With pretty much anything here in life, it is possible for an individual or an organisation to buy more of something than he need. I can go to the store and buy all the bread there is, even though I'd be full after a couple of slices. My employer could rent all the office space in the building I'm sitting in, even though everyone fits comfortably in two floors. And so on, and so on... In the same vein, yes indeed - an LIR could, in theory, obtain more address space than they have an operational need for. There's a perfectly logical reason why this doesn't happen, though. Individuals and organisations simply have better things to spend their money on than stuff they don't need. Not wasting money on useless crap is economy 101 - money is a scarce recourse, and there's always going to be something useful you can spend it on instead. (This is much like IPv4 addresses nowadays, by the way, which is why I expect 2013-03 will not cause LIRs to instantly assign away all their remaining space.) So to be honest, I don't find the argument that some LIRs will just go and buy lots of IPv4 address space they don't need "just because they can" particularly sound. Common sense tells me that if they have no actual need for IPv4 addresses, they won't be spending money on them either. However, let's for the sake of the argument assume that such LIRs do exist. The space they're obtaining from another LIR is necessarily unused to begin with (that's a current precondition for a transfer to be approved which is kept by 2013-03). So instead of having LIR "A" (the seller) sit on the space and not using it, the only actual change is that now LIR "B" (the buyer) is doing the exact same thing. The space is still just as unused as it was before the transfer. So. What is the damage done to you, I, and the rest of the RIPE community and membership? I honestly don't see any. > I believe a good policy should ensure free space returns to available > pool for fair use needs, but since allocation transfer is allowed it > should not be an allowed bypass of such a fair policy. I understand you have this point of view, however please realise: It is not germane to the discussion of 2013-03, because the status *today* is: - LIRs are not obligated to return free space to the available pool. - LIRs may to transfer allocations directly to other LIRs. Proposal 2013-03 *does not change these facts in any way whatsoever*. Like I said earlier, if you want to see the policy changed so that direct LIR-to-LIR transfers become prohibited, then you are free to submit a policy proposal that does this. It should be relatively easy, I think (start by deleting the entire ?Transfers of Allocations? section). Then we can discuss that proposal on its own merits, in a separate thread. Please leave it out of the 2013-03 discussion though, as it is irrelevant here. > With time, users and LIRs will just stop using IPv4, but until this > happens I believe we need fair use and conservation principle. > > NB: "private" space does not exist for me : internet *is* public, all > of it, and ressources are delegated to LIRs, then users, but not owned > by them. There is a major difference between public (IANA, RIR) and private (LIRs) pools. The public ones are available for all to allocate from in an equal and fair manner. The NCC is simply not at liberty to refuse to make an allocation that was valid according to the policy. The LIRs, on the other hand, are under no obligation to assign address space to anyone. So while you are of course free to call the LIR pools "public" if you want, know that the public have no access to them. Best regards, -- Tore Anderson From jan at go6.si Mon Mar 25 10:38:19 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 25 Mar 2013 10:38:19 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: <51501B0B.3000701@go6.si> On 3/19/13 5:00 PM, Emilio Madaio wrote: > Dear Colleagues > > A proposed change to RIPE Document ripe-582, "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/2013-03 Support. Way too much energy is currently wasted in battling for nickels on the bottom of the barrel. Cheers, Jan From jim at rfc1035.com Mon Mar 25 11:12:32 2013 From: jim at rfc1035.com (Jim Reid) Date: Mon, 25 Mar 2013 10:12:32 +0000 Subject: [address-policy-wg] common sense and 2013-03 In-Reply-To: <5150173E.8080809@fud.no> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514CBA30.7060604@opdop.net> <5150173E.8080809@fud.no> Message-ID: On 25 Mar 2013, at 09:22, Tore Anderson wrote: > So to be honest, I don't find the argument that some LIRs will just go > and buy lots of IPv4 address space they don't need "just because they > can" particularly sound. Common sense tells me that if they have no > actual need for IPv4 addresses, they won't be spending money on them either. +1. Though as my gran used to say "common sense: it isn't so common". I fear we're in danger of rat-holing and trying to over-engineer 2013-03. It's all very well for the proposal to enumerate every hypothetical scenario and threat. But what good does that actually do? An in-depth discussion of this proposal is like having a debate on the Titanic some time after the ship has hit the iceberg about which wines would be the best match for our dinner choices. The whole point is our policy-making machinery should be responsive and quick. So if 2013-03 later turns out to be unsatisfactory -- for some definition of unsatisfactory -- we change or replace it in light of the information available at that time. BTW, common sense flies out the window whenever there is a (perceived) market scarcity. [Back in the 1970s there was panic buying of salt in the UK because of a word of mouth rumour about "the workers going on strike in the Siberian salt mines".] If there's the equivalent of panic buying of the last dregs of v4, so what? Once it's gone, it's gone and then we can all get on with what we should be doing: deploying IPv6. No amount of policy making today is going to prevent panic buying or other irrational behaviour by those who see (or think they see) empty IPv4 shelves in the shops. From tore at fud.no Mon Mar 25 12:48:56 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 25 Mar 2013 12:48:56 +0100 Subject: [address-policy-wg] common sense and 2013-03 In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514CBA30.7060604@opdop.net> <5150173E.8080809@fud.no> Message-ID: <515039A8.1060909@fud.no> * Jim Reid > I fear we're in danger of rat-holing and trying to over-engineer > 2013-03. It's all very well for the proposal to enumerate every > hypothetical scenario and threat. But what good does that actually > do? An in-depth discussion of this proposal is like having a debate > on the Titanic some time after the ship has hit the iceberg about > which wines would be the best match for our dinner choices. Indeed. My goal with 2013-03 to reduce the amount of bureaucracy needed to operate an LIR (and by extension, the RIR), and reduce the amount of defunct policy text. To make it neat, relevant, and concise. If I had tried to instead close every tiny loophole and theoretical potential for abuse, however unlikely, the opposite would have been the result. I might as well have asked a law firm to write it. > The whole point is our policy-making machinery should be responsive > and quick. So if 2013-03 later turns out to be unsatisfactory -- for > some definition of unsatisfactory -- we change or replace it in > light of the information available at that time. Yes. And with regards to the particular concern over an LIR without operational need attempting to corner the market by buying everything there is, I'd like to ask the WG to keep in mind that there is a 24 month cooling off period for transfers which is retained by 2013-03: ?LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation.? If it does turn out to be an attempt to corner the market after 2013-03 passes, we do have sufficient time to take corrective action (through new policy) against the "cornerer" before he has a chance to cash out. This in itself is a deterrence for anyone seriously considering an attempt to corner the market. So is the possibility that IPv6 deployment will increase during those 24 months and lower our LIRs' interest in, and willingness to pay for, IPv4. > BTW, common sense flies out the window whenever there is a > (perceived) market scarcity. [Back in the 1970s there was panic > buying of salt in the UK because of a word of mouth rumour about "the > workers going on strike in the Siberian salt mines".] If there's the > equivalent of panic buying of the last dregs of v4, so what? Once > it's gone, it's gone and then we can all get on with what we should > be doing: deploying IPv6. No amount of policy making today is going > to prevent panic buying or other irrational behaviour by those who > see (or think they see) empty IPv4 shelves in the shops. If LIRs have operational need, they can engage in panic buying under the current policy too. Presumably, those that participated in the panic buying of salt you refer to were folks that actually needed and used salt... I don't see why anyone who has no need for X would get panicky about a scarcity of X, to be honest. Whether X equals IPv4 allocations, or salt. But that's just me and my (not so) common sense, I guess. ;-) Best regards, -- Tore Anderson From js at dacor.de Mon Mar 25 13:09:13 2013 From: js at dacor.de (Julian Seifert) Date: Mon, 25 Mar 2013 12:09:13 +0000 Subject: [address-policy-wg] [policy-announce] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: <71875FE4961EEE40BA4AACF7168091DE1CD1E54B@exchange.suecdacor.local> I support 2013-03 Kind Regards, Julian Seifert ________________________________________ Von: policy-announce-bounces at ripe.net [policy-announce-bounces at ripe.net]" im Auftrag von "Emilio Madaio [emadaio at ripe.net] Gesendet: Dienstag, 19. M?rz 2013 17:00 An: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Betreff: [policy-announce] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) Dear Colleagues A proposed change to RIPE Document ripe-582, "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/2013-03 We encourage you to review this proposal and send your comments to before 16 April 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC From jcurran at arin.net Mon Mar 25 13:19:26 2013 From: jcurran at arin.net (John Curran) Date: Mon, 25 Mar 2013 12:19:26 +0000 Subject: [address-policy-wg] common sense and 2013-03 In-Reply-To: <515039A8.1060909@fud.no> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514CBA30.7060604@opdop.net> <5150173E.8080809@fud.no> <515039A8.1060909@fud.no> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA2C627@CHAXCH01.corp.arin.net> On Mar 25, 2013, at 7:48 AM, Tore Anderson wrote: > And with regards to the particular concern over an LIR without > operational need attempting to corner the market by buying everything > there is, I'd like to ask the WG to keep in mind that there is a 24 > month cooling off period for transfers which is retained by 2013-03: > > ?LIRs that receive a re-allocation from another LIR cannot re-allocate > complete or partial blocks of the same address space to another LIR > within 24 months of receiving the re-allocation.? Tore - ARIN has similar provisions - "The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request." This is an effective control presuming that there is a relatively fixed number of LIRs (i.e. parties that can receive address blocks) It should be noted that such provisions are more difficult to meaningfully maintain in the absence of any operational need, as one can simply create multiple new entities as fast as desired to receive blocks via transfer, an approach which is much harder to do when the recipient needs to show an actual operational network which survives a reasonable degree of due diligence. Again, the RIPE community should decide what policy is best for it based on overall consideration of all factors; my point above is not in favor or opposition to the policy proposal but simply an observation that may not be otherwise apparent. FYI, /John John Curran President and CEO ARIN From andrea at ripe.net Mon Mar 25 13:53:26 2013 From: andrea at ripe.net (Andrea Cima) Date: Mon, 25 Mar 2013 13:53:26 +0100 Subject: [address-policy-wg] Policy Proposal 2012-05, "Transparency in Address Block Transfers" Implemented Message-ID: [Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2012-05, "Transparency in Address Block Transfers", has been implemented. The RIPE NCC is now publishing the required statistics at: https://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of-transfers This page will be updated weekly. The data is also available in JSON format here: https://www-static.ripe.net/dynamic/table-of-transfers/transfers.json The full policy proposal can be found at: http://www.ripe.net/ripe/policies/archived-policy-proposals/proposals/2012-05 The updated RIPE Document 582, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", can be found at: http://www.ripe.net/ripe/docs/ripe-582 If you have any questions, please contact . Regards, Andrea Cima RIPE NCC Registration Services -------------- next part -------------- An HTML attachment was scrubbed... URL: From stolpe at resilans.se Mon Mar 25 13:57:20 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 25 Mar 2013 13:57:20 +0100 (CET) Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> Message-ID: On Wed, 20 Mar 2013, Milton L Mueller wrote: > This seems like a very well thought-out policy proposal. Agreed. And thus I support the proposal. Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From stolpe at resilans.se Mon Mar 25 13:59:47 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 25 Mar 2013 13:59:47 +0100 (CET) Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514AB968.6090102@fud.no> References: <6A970D2A8B029E45826C95E9EEF9317F3692106D@koboexch1> <514AB968.6090102@fud.no> Message-ID: On Thu, 21 Mar 2013, Tore Anderson wrote: >> The cleanest, and most radical, solution would of course be to say >> "addresses are addresses" and do away with the difference between PI and >> PA and strip all references the "PA" and "PI" from the policy and RIPE DB. > > I've heard talk about such a ?PA/PI unification? proposal, at least for > IPv6, but I don't think anything was ever actually submitted to the PDP. > I would prefer that such a change could be proposed and discussed > independently of 2013-03, though. That said: The eventual passing of > 2013-03 would be a great benefit to such a proposal, as the amount of > policy text that needs to be changed would decrease dramatically. > > See also: > > http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-October/006496.html Yes. Mayby we have what we have with IPv4 but I support Gert in the attempts of bringing som order to the IPv6 space. Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From fredrik at resilans.se Mon Mar 25 14:02:56 2013 From: fredrik at resilans.se (Fredrik Widell) Date: Mon, 25 Mar 2013 14:02:56 +0100 (CET) Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <51501B0B.3000701@go6.si> References: <51501B0B.3000701@go6.si> Message-ID: On Mon, 25 Mar 2013, Jan Zorz @ go6.si wrote: I support this proposal. > On 3/19/13 5:00 PM, Emilio Madaio wrote: >> Dear Colleagues >> >> A proposed change to RIPE Document ripe-582, "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/2013-03 > > Support. > > Way too much energy is currently wasted in battling for nickels on the bottom > of the barrel. > > Cheers, Jan > > > > -- Mvh Fredrik Widell Resilans AB http://www.resilans.se/ mail: info at resilans.se , fredrik at resilans.se phone: +46 8 688 11 82 From frettled at gmail.com Mon Mar 25 14:13:51 2013 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 25 Mar 2013 14:13:51 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: On Tue, Mar 19, 2013 at 5:00 PM, Emilio Madaio wrote: > https://www.ripe.net/ripe/policies/proposals/2013-03 I support this proposal. -- Jan From lists-ripe at c4inet.net Mon Mar 25 14:22:38 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 25 Mar 2013 13:22:38 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: <20130325132238.GA88304@cilantro.c4inet.net> On Tue, Mar 19, 2013 at 05:00:56PM +0100, Emilio Madaio wrote: > https://www.ripe.net/ripe/policies/proposals/2013-03 I support this proposal. Regards, Sascha Luck From gert at space.net Mon Mar 25 14:30:31 2013 From: gert at space.net (Gert Doering) Date: Mon, 25 Mar 2013 14:30:31 +0100 Subject: [address-policy-wg] IPv6 PA/PI unification (was: 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup)) In-Reply-To: References: <6A970D2A8B029E45826C95E9EEF9317F3692106D@koboexch1> <514AB968.6090102@fud.no> Message-ID: <20130325133031.GC51699@Space.Net> Hi, On Mon, Mar 25, 2013 at 01:59:47PM +0100, Daniel Stolpe wrote: > [ PA/PI unification ] > Yes. Mayby we have what we have with IPv4 but I support Gert in the > attempts of bringing som order to the IPv6 space. Yeah. For the record: this has not been forgotten, but again I have been a bit too busy to make a formal policy proposal (with specific text, etc) out of my ideas. I think I'll try to round up a few volunteers in Dublin to help me with this... 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 From mueller at syr.edu Mon Mar 25 19:09:27 2013 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 25 Mar 2013 18:09:27 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> Message-ID: <855077AC3D7A7147A7570370CA01ECD2381D52@SUEX10-mbx-10.ad.syr.edu> > -----Original Message----- > What is most striking to me is that we had a finite but > significant supply of resources in the past, and we doled them out > according to operational need. That made sense to me. Eliminate the > operational needs requirement during a rationing phase just doesn't > make sense to me. The problem you are overlooking, McTim, is that in this end-game phase there will be hundreds if not thousands of organizations with operational needs and it will be the high bidder that gets it in the end. For all practical purposes we can assume that anyone who bothers to bid for the resource has some kind of need for it. Do you seriously think there is a major likelihood of lots of people making winning bids for number blocks just for the heck of it? Given the incredible flexibility and even subjectivity of the concept of "operational need" we are adding massive bureaucratic costs and delays but the gain achieved is completely unclear to me. I note that the secondary market for radio spectrum resources in the U.S. and elsewhere does not require acquirers to prove to anyone that they "need" it, yet there is no big problem with the way it has worked. > I also think that if adopted, this proposal would preclude an > inter-RIR transfer market in that the "needs test" is required in the > other regions, and that would mean that the RIPE region policies would > not be "compatible" as called for in the other regions transfer > policies. This can change... From mueller at syr.edu Mon Mar 25 19:19:09 2013 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 25 Mar 2013 18:19:09 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> Scott In my opinion (as a fellow ARIN AC member) the best way to provide impetus for the needed policy changes in all regions is for RIPE to pass this policy and to demonstrate to the rest of the world that the sky does not fall once needs assessment is put to rest. Since RIPE is in the last /8 policy and thus for its tiny remaining free pool needs assessment is already gone, there is nothing "intermediate" about its status. Further, I do not understand your argument about "uncomfortable intermediate states" below. How does the absence of needs assessment in the RIPE region have any effect on AFRINIC and LACNIC, which still have free pools and do not allow transfers? Also, how does it have any effect on ARIN, when under its current policy transfers from ARIN to the RIPE region would not be possible ? In short, your suggested sequence for liberalization seems to me to get it backwards. None of the larger scale reforms you propose are likely to happen if RIPE doesn't take this first, catalytic step. If it does, the other reforms are far more likely to happen. From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Scott Leibrand Sent: Thursday, March 21, 2013 1:52 PM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) While I support the goals of 2013-03 in a post-IPv4-depletion world, we are currently in an uncomfortable intermediate state where IPv4 depletion has occurred in some regions (RIPE and APNIC) but not in others (ARIN, LACNIC, and AfriNIC). I think it will be wise to wait until IPv4 depletion to remove of (at least some) needs requirements in those regions that still have an IPv4 free pool. As a result of the fact of remaining RIR free pools, and the current policy and sentiment in the ARIN region that inter-RIR IPv4 transfers should occur only to organizations/regions that justify need for the addresses (to avoid a run on said free pool), I think it would be wise to do something like this: - First, pass an inter-RIR transfer policy in the RIPE region that is compatible with both the APNIC and ARIN inter-RIR transfer policies (i.e. has some form of needs justification). - Second, make sure that RIPE's transfer policy serves all organizations in the RIPE region, including those who in the past got PI space from RIPE. - Third, relax the ARIN region's inter-RIR transfer policy such that after IPv4 depletion in the ARIN region, transfers are allowed to regions with policies like 2013-03. - Fourth, pass something along the lines of 2013-03 in the RIPE region (to take effect) after IPv4 depletion has occurred in the ARIN region. - Fifth, update policy in other regions as well to align policy with the needs of a post-IPv4-depletion world. I'm more than happy to help drive #3 and eventually #5 in the ARIN region. -Scott On Thu, Mar 21, 2013 at 10:33 AM, > wrote: > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-03 > > We encourage you to review this proposal and send your comments to > > before 16 April 2013. Support. This goal of 2012-03 was to align the justification period with the other RIR's who allow inter-RIR transfers. Tore's proposal 2013-03 will remove justification altogether, which is what all the RIR's need to do. The reason I went with a 24 month justification period in 2012-03 was because that was the period APNIC and ARIN use. I was hopeful that this would align the RIPE such that when transfers to and from those RIR's were considered, they would be allowed, because the RIPE would have a "like" policy. Tore's policy may have the impact of bringing ALL the RIR's into the current market reality: that when an entity is paying for IP's, that is needs justification enough. There is no hoarding in an unencumbered market. RIPE is demonstrating true world leadership here. Sandra Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Mon Mar 25 19:26:00 2013 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 25 Mar 2013 18:26:00 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <98FA51E9-C8A6-4AD0-B2B2-CB6BC7C1A61F@steffann.nl> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514B9F28.3020001@umn.edu> <98FA51E9-C8A6-4AD0-B2B2-CB6BC7C1A61F@steffann.nl> Message-ID: <855077AC3D7A7147A7570370CA01ECD2381DB2@SUEX10-mbx-10.ad.syr.edu> > > In other words: if you sell address space you obviously don't need it. False, as a blanket assumption. Obvious counter-scenario: You need a /16 but hold a /8. You sell the entire /8 due to the premium it commends as a contiguous block but then buy a /16. > > If this WG wants 2013-03 and transfers from ARIN are the only argument > against 2013-03 then it might be a solution to add this bit of (IMHO) common > sense for those who want to transfer addresses from the ARIN region. > > But I am just suggesting options for the WG. I'll stay out of the discussion and > let the community (to all who are reading this: that includes you!) decide :-) > > Cheers, > Sander > From scottleibrand at gmail.com Mon Mar 25 20:13:00 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 25 Mar 2013 12:13:00 -0700 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <514BF935.4040003@fud.no> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <514BF935.4040003@fud.no> Message-ID: On Thu, Mar 21, 2013 at 11:24 PM, Tore Anderson wrote: > Hello Scott, > > * Scott Leibrand > > > While I support the goals of 2013-03 in a post-IPv4-depletion world, we > > are currently in an uncomfortable intermediate state where IPv4 > > depletion has occurred in some regions (RIPE and APNIC) but not in > > others (ARIN, LACNIC, and AfriNIC). I think it will be wise to wait > > until IPv4 depletion to remove of (at least some) needs requirements in > > those regions that still have an IPv4 free pool. > > Geoff Huston's http://www.potaroo.net/tools/ipv4/index.html projects > that global IPv4 depletion won't happen until July 2020, when AfriNIC is > set to deplete as the last of the five RIRs. That is a *long* time to > keep around a bureaucracy that no longer serves any purpose. > I was not very clear. I was just making the (obvious and possibly irrelevant) point that LACNIC and AfriNIC won't want to do something like 2013-03 until their free pools are exhausted. > > > As a result of the fact of remaining RIR free pools, and the current > > policy and sentiment in the ARIN region that inter-RIR IPv4 transfers > > should occur only to organizations/regions that justify need for the > > addresses (to avoid a run on said free pool), I think it would be wise > > to do something like this: > > > > - First, pass an inter-RIR transfer policy in the RIPE region that is > > compatible with both the APNIC and ARIN inter-RIR transfer policies > > (i.e. has some form of needs justification). > > - Second, make sure that RIPE's transfer policy serves all > > organizations in the RIPE region, including those who in the past got PI > > space from RIPE. > > - Third, relax the ARIN region's inter-RIR transfer policy such that > > after IPv4 depletion in the ARIN region, transfers are allowed to > > regions with policies like 2013-03. > > - Fourth, pass something along the lines of 2013-03 in the RIPE region > > (to take effect) after IPv4 depletion has occurred in the ARIN region. > > - Fifth, update policy in other regions as well to align policy with > > the needs of a post-IPv4-depletion world. > > > > I'm more than happy to help drive #3 and eventually #5 in the ARIN > region. > > While I see and acknowledge that 2013-03 conflicts with ARIN's need > requirement for inter-region transfers, and that this is a valid > argument against the proposed policy, I do feel that this argument alone > is not strong enough to to stop 2013-03, for the following reasons: > > 1) It is entirely dependent on proposal 2012-02 passing, which is far > from a certainty. 2012-02 has received at best a lukewarm response from > the community - according to the chairs, it has, quote, ?far from > consensus?. Should 2012-02 not pass, 2013-03's conflict with ARIN's need > requirement is completely irrelevant. > > 2) According to Ingrid Wijte's MENOG12 presentation > ( > http://www.menog.org/presentations/menog-12/127-IPv4_Transfers-RIPE_NCC_Update.pdf > ), > there have been only a measly 17 permanent transfers in the RIPE region > in the last three months. It would surprise me greatly if the amount of > assignments having been made by the LIRs in the same period is not at > least two orders of magnitude more. > I am somewhat baffled by this. Do you (or does anyone) have a good idea as to what ISPs are doing instead? Are they improving utilization efficiency within their network? Still using up space they got before the free pool was exhausted? Or (I doubt this) putting new users on IPv6? I know that the RIPE intra-RIR transfer policy is somewhat strict compared to those in APNIC and ARIN (not allowing transfers to end users, for example): is that likely playing a part as well? > > Choosing to uphold the need justification and documentation bureaucracy > for all those assignments that we LIRs perform on a frequent basis, for > the sole purpose of allowing only one specific flavour of the very > rarely used allocation transfer mechanism to work, seems to me to fail a > very basic cost-benefit analysis. > > 3) The RIPE community's benefit of allowing transfers from the ARIN > region into the RIPE region is only obvious due to the fact that ARIN > still has remaining free space in their address pool. ?They've still got > more space, let's go grab as much of it as we can before it's all gone!? > > It is not certain that it is a net benefit to the RIPE community to > allow transfers with depleted regions. The result may very well be that > more address space is being transferred *out* of our region, than what > is coming in - further exacerbating our depletion ordeal. This > uncertainty makes the cost-benefit analysis I mentioned in #2 even more > clear in favour of 2013-03. > > According to Geoff Huston, ARIN looks set to deplete exactly one year > from now. Keeping in mind that 2012-02 appears to still have a long way > to go in the PDP, the time period during which the benefit of allowing > free trade with ARIN is obvious is only going to be a few months at > most. Quite possibly, ARIN will deplete before 2012-02 gets implemented, > if so the obvious beneficial period will not exist at all. > The inter-RIR transfer policies were specifically designed to prevent the free pool of one region from being drained via transfers to another region. Rather, the benefit of inter-RIR transfers comes from getting existing underutilized space back into use. As it happens, the ARIN region has a lot of large legacy allocations, many of which are underutilized. That source of supply, IMO, is what the RIPE region will be getting access to if/when a compatible inter-RIR transfer policy is passed. It is worth noting that prices in the transfer market to date are significantly higher in the RIPE region than the ARIN region. I believe this reflects the relative scarcity of supply in the RIPE region (which is likely also related to the reason there have been so few transactions). In the ARIN region, I believe prices already reflect sellers' expectations of the post-exhaustion supply/demand balance (non-bankrupt sellers are mostly holding out for free pool exhaustion rather than selling at a lower price). As a result, I don't expect transfer prices in the ARIN region to rise significantly when that demand materializes. > > 4) Again, ARIN is soon depleting. As I mentioned in the proposal itself, > this might cause the ARIN community to do a reality adjustment similar > to 2013-03, and rescind the need requirement for inter-region transfers. > After all, there is little point in trying to prevent other regions from > "bleeding them dry" if they have nothing left anyway. So that's your > item #3, essentially. If you're willing to suggest that to the ARIN > community now, I'm all for it. > > We will undoubtedly discuss this (at least informally with interested parties) at next month's ARIN meeting. I suspect that if the discussion gets any traction, any resulting proposal will be to relax needs assessment requirements on transfers and reassignments only after the ARIN free pool is exhausted. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Mon Mar 25 20:13:08 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 25 Mar 2013 12:13:08 -0700 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> Message-ID: >From a political economy perspective (I think that's the term) you may be correct. But I don't think the catalysis of 2013-03 will be sufficient on its own: I suspect the ARIN community will only be willing to liberalize its needs-based inter-RIR transfer policy after the ARIN free pool is exhausted. My point about AfriNIC and LACNIC was poorly stated, and somewhat unrelated to this discussion. (Just that they probably wouldn't pass something like 2013-03 *in their region* while they still have a free pool. But, duh.) The more important point is indeed the interaction between ARIN and RIPE. It is the combination of RIPE being empty and ARIN still having a free pool that makes for an "intermediate" state, and makes it difficult to reconcile the goals of 2013-03 with the desire to make sure all inter-RIR transfers out of the ARIN region continue to be needs-based. If the RIPE community thinks that eliminating needs justification bureaucracy is a higher priority than getting access to transfers of less-expensive legacy address space from the ARIN region (due to greater supply of underutilized addresses there), then I agree that passing 2013-03 would be appropriate. But I would predict that doing so will prevent any implementation of inter-RIR transfers from the ARIN region to the RIPE region until after (possibly well after) ARIN's free pool is exhausted. -Scott On Mon, Mar 25, 2013 at 11:19 AM, Milton L Mueller wrote: > Scott**** > > In my opinion (as a fellow ARIN AC member) the best way to provide impetus > for the needed policy changes in all regions is for RIPE to pass this > policy and to demonstrate to the rest of the world that the sky does not > fall once needs assessment is put to rest. Since RIPE is in the last /8 > policy and thus for its tiny remaining free pool needs assessment is > already gone, there is nothing "intermediate" about its status.**** > > ** ** > > Further, I do not understand your argument about "uncomfortable > intermediate states" below. How does the absence of needs assessment in the > RIPE region have any effect on AFRINIC and LACNIC, which still have free > pools and do not allow transfers? Also, how does it have any effect on > ARIN, when under its current policy transfers from ARIN to the RIPE region > would not be possible ? **** > > ** ** > > In short, your suggested sequence for liberalization seems to me to get it > backwards. None of the larger scale reforms you propose are likely to > happen if RIPE doesn't take this first, catalytic step. If it does, the > other reforms are far more likely to happen.**** > > ** ** > > *From:* address-policy-wg-bounces at ripe.net [mailto: > address-policy-wg-bounces at ripe.net] *On Behalf Of *Scott Leibrand > *Sent:* Thursday, March 21, 2013 1:52 PM > *To:* address-policy-wg at ripe.net > *Subject:* Re: [address-policy-wg] 2013-03 New Policy Proposal (No Need - > Post-Depletion Reality Adjustment and Cleanup)**** > > ** ** > > While I support the goals of 2013-03 in a post-IPv4-depletion world, we > are currently in an uncomfortable intermediate state where IPv4 depletion > has occurred in some regions (RIPE and APNIC) but not in others (ARIN, > LACNIC, and AfriNIC). I think it will be wise to wait until IPv4 depletion > to remove of (at least some) needs requirements in those regions that still > have an IPv4 free pool.**** > > ** ** > > As a result of the fact of remaining RIR free pools, and the current > policy and sentiment in the ARIN region that inter-RIR IPv4 transfers > should occur only to organizations/regions that justify need for the > addresses (to avoid a run on said free pool), I think it would be wise to > do something like this:**** > > ** ** > > - First, pass an inter-RIR transfer policy in the RIPE region that is > compatible with both the APNIC and ARIN inter-RIR transfer policies (i.e. > has some form of needs justification).**** > > - Second, make sure that RIPE's transfer policy serves all organizations > in the RIPE region, including those who in the past got PI space from RIPE. > **** > > - Third, relax the ARIN region's inter-RIR transfer policy such that > after IPv4 depletion in the ARIN region, transfers are allowed to regions > with policies like 2013-03.**** > > - Fourth, pass something along the lines of 2013-03 in the RIPE region > (to take effect) after IPv4 depletion has occurred in the ARIN region.**** > > - Fifth, update policy in other regions as well to align policy with the > needs of a post-IPv4-depletion world.**** > > ** ** > > I'm more than happy to help drive #3 and eventually #5 in the ARIN region. > **** > > ** ** > > -Scott**** > > ** ** > > ** ** > > On Thu, Mar 21, 2013 at 10:33 AM, wrote: > **** > > > You can find the full proposal at: > > > > https://www.ripe.net/ripe/policies/proposals/2013-03 > > > > We encourage you to review this proposal and send your comments to > > before 16 April 2013.**** > > Support. > > This goal of 2012-03 was to align the justification period with the > other RIR's who allow inter-RIR transfers. Tore's proposal 2013-03 will > remove justification altogether, which is what all the RIR's need to do. > The reason I went with a 24 month justification period in 2012-03 was > because that was the period APNIC and ARIN use. I was hopeful that this > would align the RIPE such that when transfers to and from those RIR's > were considered, they would be allowed, because the RIPE would have a > "like" policy. > > Tore's policy may have the impact of bringing ALL the RIR's into the > current market reality: that when an entity is paying for IP's, that is > needs justification enough. There is no hoarding in an unencumbered > market. RIPE is demonstrating true world leadership here. > > Sandra Brown > > > **** > > ** ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.vallerot at opdop.net Mon Mar 25 21:16:32 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Mon, 25 Mar 2013 21:16:32 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5150173E.8080809@fud.no> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514CBA30.7060604@opdop.net> <5150173E.8080809@fud.no> Message-ID: <5150B0A0.7040705@opdop.net> On 25/03/2013 10:22, Tore Anderson wrote: > Yes, under the proposed policy it would be technically possible for an > LIR to obtain (through transfers) a larger amount of address space than > they have an operational need for. And assign it without any control nor fair use because of the removal of the conservation goal and means (documentation, Ripe control). Of course LIRs won't just buy to waste money. But some would to sell rare ressource (a lot already do). > With pretty much anything here in life, it is possible for an individual > or an organisation to buy more of something than he need. I can go to > the store and buy all the bread there is, even though I'd be full after > a couple of slices. It is possible but not necessarily worth it. It is not worth buying all bread if everybody can get it for low price and it is available. It is not worth buying it all either if you cannot resell it to whom you want. IPv4 ressource is rare so first condition is met. Selling to richest first is possible with 2013-3 deregulation. What happens when a vital ressource becomes rare usually ? Free market is regulated, rationing is set in place for everyone to get a chance to survive. Cheaters make black market that restores "free market" logic, where richest buy first and poors starve. Allocation transfer allows the black market to I does not lead to abuse since regulation of final step selling is in place. Deregulation makes money oriented reselling allowed. This is black market made legal, rationing screwing. I think you got my point. Best regards, Sylvain From scottleibrand at gmail.com Mon Mar 25 21:35:23 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 25 Mar 2013 13:35:23 -0700 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <514BFFF1.1050007@fud.no> References: <514BFFF1.1050007@fud.no> Message-ID: On Thu, Mar 21, 2013 at 11:53 PM, Tore Anderson 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.html > > 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.html One point I think is worth mentioning in this thread: you referenced http://www.menog.org/presentations/menog-12/127-IPv4_Transfers-RIPE_NCC_Update.pdfand 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Mon Mar 25 22:16:06 2013 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 25 Mar 2013 21:16:06 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> Message-ID: <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> OK. Your point is clearer now. But my understanding is that ARIN has no authority over transfers from a truly "legacy" (i.e., non-contracted) holder. If such a legacy holder wants to transfer to RIPE region without ARIN needs assessment, they can if RIPE allows it. ARIN will fuss and bluster about it, but so what? The more important point is indeed the interaction between ARIN and RIPE. It is the combination of RIPE being empty and ARIN still having a free pool that makes for an "intermediate" state, and makes it difficult to reconcile the goals of 2013-03 with the desire to make sure all inter-RIR transfers out of the ARIN region continue to be needs-based. If the RIPE community thinks that eliminating needs justification bureaucracy is a higher priority than getting access to transfers of less-expensive legacy address space from the ARIN region (due to greater supply of underutilized addresses there), then I agree that passing 2013-03 would be appropriate. But I would predict that doing so will prevent any implementation of inter-RIR transfers from the ARIN region to the RIPE region until after (possibly well after) ARIN's free pool is exhausted. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Mar 25 22:29:03 2013 From: jcurran at arin.net (John Curran) Date: Mon, 25 Mar 2013 21:29:03 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2381D52@SUEX10-mbx-10.ad.syr.edu> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <855077AC3D7A7147A7570370CA01ECD2381D52@SUEX10-mbx-10.ad.syr.edu> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA369CE@CHAXCH01.corp.arin.net> On Mar 25, 2013, at 2:09 PM, Milton L Mueller wrote: > ... Do you seriously think there is a major likelihood of lots of people making winning bids for number blocks just for the heck of it? Given the incredible flexibility and even subjectivity of the concept of "operational need" we are adding massive bureaucratic costs and delays but the gain achieved is completely unclear to me. > > I note that the secondary market for radio spectrum resources in the U.S. and elsewhere does not require acquirers to prove to anyone that they "need" it, yet there is no big problem with the way it has worked. Just to complete your analogy... If RIPE were to operate with policies similar to the US radio spectrum market, it is possible that the absence of needs-assessment would not automatically lead to rampant speculation. Of course, this is also because to perform a transfer in the US spectrum market, you're likely going to hire lawyers, complete a 40 page form (FCC Form 603) and "certify that the proposed transaction meets specific criteria indicating the absence of potential pubic interest concerns relating to eligibility, use restrictions, foreign ownership, designated entity policies, and competition." Postulating what might or might not happen with a transfer market in the RIPE region (in the absence of needs-assessment) based on history with the US radio spectrum market is disingenuous without also noting the fact that the US radio spectrum market has its own "bureaucratic costs and delays" of a completely different nature which may easily impact the resulting dynamics. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Mon Mar 25 22:34:39 2013 From: jcurran at arin.net (John Curran) Date: Mon, 25 Mar 2013 21:34:39 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA36B56@CHAXCH01.corp.arin.net> On Mar 25, 2013, at 5:16 PM, Milton L Mueller > wrote: OK. Your point is clearer now. But my understanding is that ARIN has no authority over transfers from a truly "legacy" (i.e., non-contracted) holder. If such a legacy holder wants to transfer to RIPE region without ARIN needs assessment, they can if RIPE allows it. ARIN will fuss and bluster about it, but so what? Milton - Your understanding is incorrect. ARIN operates the registry in accordance with the policy developed by ARIN region, and resources in the registry are therefore completely subject to those policies. As I noted earlier, we'd prefer contracts where possible, but even a party that does not have a formal contract can chose to participate or not. You can use any numbers you want in your routers, but if you wish to use numbers which are unique per the Internet Registry system, then you are participating in the Internet Registry system, gaining the benefits thereof, and therefore are subject to the policies used in its coordination & operation. Feel free to read , question #18 and related answer for more background. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Mon Mar 25 22:49:11 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 25 Mar 2013 14:49:11 -0700 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> Message-ID: Would existing RIPE policy and practice allow the transfer of non-RSA legacy space currently registered in the ARIN database to a recipient in the RIPE region? The policy text would seem to allow it: "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA." I guess it might require an ERX-style transfer of the original IANA assignment to RIPE's administrative control first? Has anyone attempted such a transfer yet, I wonder? -Scott On Mon, Mar 25, 2013 at 2:16 PM, Milton L Mueller wrote: > OK. Your point is clearer now. But my understanding is that ARIN has no > authority over transfers from a truly "legacy" (i.e., non-contracted) > holder. If such a legacy holder wants to transfer to RIPE region without > ARIN needs assessment, they can if RIPE allows it. ARIN will fuss and > bluster about it, but so what?**** > > ** ** > > The more important point is indeed the interaction between ARIN and RIPE. > It is the combination of RIPE being empty and ARIN still having a free > pool that makes for an "intermediate" state, and makes it difficult to > reconcile the goals of 2013-03 with the desire to make sure all inter-RIR > transfers out of the ARIN region continue to be needs-based.**** > > ** ** > > If the RIPE community thinks that eliminating needs justification > bureaucracy is a higher priority than getting access to transfers of > less-expensive legacy address space from the ARIN region (due to greater > supply of underutilized addresses there), then I agree that passing 2013-03 > would be appropriate. But I would predict that doing so will prevent any > implementation of inter-RIR transfers from the ARIN region to the RIPE > region until after (possibly well after) ARIN's free pool is exhausted.*** > * > > ** ** > > -Scott**** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From undefine at aramin.net Mon Mar 25 23:21:08 2013 From: undefine at aramin.net (=?UTF-8?B?QW5kcnplaiBEb3BpZXJhxYJh?=) Date: Mon, 25 Mar 2013 23:21:08 +0100 Subject: [address-policy-wg] minimum allocation size in case of transform addresses Message-ID: <5150CDD4.8040002@aramin.net> Hi! I found today out, that there is planed possibility to convert PI assignments to PA allocation. But - i'ts planed only for /22 and bigger assignments, due to minimum allocation size, and doesn't apply for example /23 or /22 assignemnts. I think it's a bit pointless. AFAIK sense of minimum allocation is suppression of unnecessary fragmentation. But - in this case - this pool is already in use, and is already visible in bgp table. Allowing or disallowing conversion doesn't have any relation with growing address space. What's more - allowing conversion of any assignment can save some of address space. Most of PI assignemts (known to me) is partialy unused. After years from assignemnts part of the plans has been withdrawn (but another parts are citical - dns servers etc - so whole assignemnt can't be returned). Allowing conversion would allow use it back, for example for customers... (sorry for my english - i hope that sense is understandable) -- Regards, Andrzej 'The Undefined' Dopiera?a http://andrzej.dopierala.name/ From jcurran at arin.net Mon Mar 25 23:47:35 2013 From: jcurran at arin.net (John Curran) Date: Mon, 25 Mar 2013 22:47:35 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> Message-ID: <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> On Mar 25, 2013, at 5:49 PM, Scott Leibrand wrote: > Would existing RIPE policy and practice allow the transfer of non-RSA legacy space currently registered in the ARIN database to a recipient in the RIPE region? The policy text would seem to allow it: "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA." I guess it might require an ERX-style transfer of the original IANA assignment to RIPE's administrative control first? > > Has anyone attempted such a transfer yet, I wonder? Not likely to succeed, as it would be contrary to policy in the ARIN region. /John John Curran President and CEO ARIN From farmer at umn.edu Tue Mar 26 00:06:35 2013 From: farmer at umn.edu (David Farmer) Date: Mon, 25 Mar 2013 18:06:35 -0500 Subject: [address-policy-wg] minimum allocation size in case of transform addresses In-Reply-To: <5150CDD4.8040002@aramin.net> References: <5150CDD4.8040002@aramin.net> Message-ID: <5150D87B.6000008@umn.edu> On 3/25/13 17:21 , Andrzej Dopiera?a wrote: > Hi! > I found today out, that there is planed possibility to convert PI > assignments to PA allocation. > But - i'ts planed only for /22 and bigger assignments, due to minimum > allocation size, and doesn't apply for example /23 or /22 assignemnts. > > I think it's a bit pointless. > > AFAIK sense of minimum allocation is suppression of unnecessary > fragmentation. But - in this case - this pool is already in use, and is > already visible in bgp table. Allowing or disallowing conversion doesn't > have any relation with growing address space. > > What's more - allowing conversion of any assignment can save some of > address space. Most of PI assignemts (known to me) is partialy unused. > After years from assignemnts part of the plans has been withdrawn (but > another parts are citical - dns servers etc - so whole assignemnt can't > be returned). Allowing conversion would allow use it back, for example > for customers... > > (sorry for my english - i hope that sense is understandable) You probably still want to prevent the fragmentation of larger blocks into smaller blocks than the applicable minimum allocation size. However, if the block in question is already smaller then it should be transferable at its current size, you just can't fragment the block. Legacy /24s or PI blocks are easy examples of block that exist that you might want to all an LIR to receive. Language like the following should work; "The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy." This is one reason to not completely eliminate all the existing IPv4 policies with 2013-03. They can still be useful, and may be useful in the future. Otherwise, you have to revisit the consensus for issues like what the appropriate minimum allocations size should be in what situations. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From scottleibrand at gmail.com Tue Mar 26 00:23:07 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 25 Mar 2013 16:23:07 -0700 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: <514BFFF1.1050007@fud.no> Message-ID: On Mon, Mar 25, 2013 at 1:35 PM, Scott Leibrand wrote: > On Thu, Mar 21, 2013 at 11:53 PM, Tore Anderson 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Mar 26 01:06:12 2013 From: randy at psg.com (Randy Bush) Date: Tue, 26 Mar 2013 09:06:12 +0900 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) Message-ID: this proposal seems sensible. randy From tore at fud.no Tue Mar 26 02:23:37 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 26 Mar 2013 02:23:37 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <514BF935.4040003@fud.no> Message-ID: <5150F899.1070501@fud.no> * Scott Leibrand > I was not very clear. I was just making the (obvious and possibly > irrelevant) point that LACNIC and AfriNIC won't want to do something > like 2013-03 until their free pools are exhausted. Indeed (this goes for the ARIN region too actually). Something like 2013-03 in a region with an unexhausted free pool would lead to the Tragedy of the Commons pretty quickly, I'd expect. > 2) According to Ingrid Wijte's MENOG12 presentation > (http://www.menog.org/presentations/menog-12/127-IPv4_Transfers-RIPE_NCC_Update.pdf), > there have been only a measly 17 permanent transfers in the RIPE region > in the last three months. It would surprise me greatly if the amount of > assignments having been made by the LIRs in the same period is not at > least two orders of magnitude more. > > > I am somewhat baffled by this. Do you (or does anyone) have a good idea > as to what ISPs are doing instead? Are they improving utilization > efficiency within their network? Still using up space they got before > the free pool was exhausted? Or (I doubt this) putting new users on IPv6? > > I know that the RIPE intra-RIR transfer policy is somewhat strict > compared to those in APNIC and ARIN (not allowing transfers to end > users, for example): is that likely playing a part as well? I can only answer for myself and the LIR I represent, and we're going for the "improving utilization efficiency" approach. We do absolutely not want to end up being dependent on transfers for business continuity. FWIW (and shameless plug alert), what I've been working on to this end you can read about at http://goo.gl/zVF3O. > The inter-RIR transfer policies were specifically designed to prevent > the free pool of one region from being drained via transfers to another > region. [...] > 4) Again, ARIN is soon depleting. As I mentioned in the proposal itself, > this might cause the ARIN community to do a reality adjustment similar > to 2013-03, and rescind the need requirement for inter-region transfers. > After all, there is little point in trying to prevent other regions from > "bleeding them dry" if they have nothing left anyway. So that's your > item #3, essentially. If you're willing to suggest that to the ARIN > community now, I'm all for it. > > > We will undoubtedly discuss this (at least informally with interested > parties) at next month's ARIN meeting. I suspect that if the discussion > gets any traction, any resulting proposal will be to relax needs > assessment requirements on transfers and reassignments only after the > ARIN free pool is exhausted. Good luck! :-) If indeed the goal of the need requirements of ARIN's inter-region transfer policy is only there to prevent the draining of ARIN's free pool, I'd think that the actual (and inevitable) exhaustion of the free pool should make it rather obvious that the requirement has outlived its utility, and can be safely removed. If that happens, especially if you get the ARIN PDP started in advance so that the requirement is ready to be rescinded immediately when the pool depletes, the amount of time with a "uncomfortable intermediate state" isn't likely to be more than a few months at most (both 2012-02 and 2013-03 must first pass the RIPE PDP, and ARIN must still have addresses left). Making any special policy in either region to handle that short period is probably not worth the effort. Tore From tore at fud.no Tue Mar 26 02:48:07 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 26 Mar 2013 02:48:07 +0100 Subject: [address-policy-wg] 2012-02 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: References: <514BFFF1.1050007@fud.no> Message-ID: <5150FE57.9090901@fud.no> * 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_Update.pdf > 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 From tore at fud.no Tue Mar 26 03:13:09 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 26 Mar 2013 03:13:09 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5150B0A0.7040705@opdop.net> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514CBA30.7060604@opdop.net> <5150173E.8080809@fud.no> <5150B0A0.7040705@opdop.net> Message-ID: <51510435.4020902@fud.no> * Sylvain Vallerot > On 25/03/2013 10:22, Tore Anderson wrote: >> Yes, under the proposed policy it would be technically possible for an >> LIR to obtain (through transfers) a larger amount of address space than >> they have an operational need for. > > And assign it without any control nor fair use because of the removal > of the conservation goal and means (documentation, Ripe control). In theory: yes. In reality: say what? So imagine you're an LIR. You've just spent 1 million euros on a good-as-new /16. What on Earth would cause you to then go ahead and ?assign it without any control?? If there's such a LIR in existence I'm going to set up camp outside their HQ, in the hope that they will opt to throw those 1 million euros out the window instead. This actually seems more likely to happen, as there's less paperwork involved. ;-) > It is not worth buying it all either if you cannot resell it to whom > you want. If you by "resell" here mean to sell the entire allocation to another LIR, then keep in mind that both in current policy, and also under 2013-03 policy, you cannot resell the allocation until 24 months have passed. So IPv4 addresses isn't going to be a very attractive investment object for speculators. Or, if you by "resell" mean "make assignments to your customers", then you have an operational need anyway, and you're allowed to buy the allocation under today's policy too. 2013-03 makes no difference in this case. > Selling to richest first is possible with 2013-3 deregulation. It's possible today too, if the buyer has "operational need". And there's no shortage of LIRs with operational need, just look in the LIR Portal's Listing Service. So for anything to actually change from today's status quo, an LIR without any operational need would have to be willing to pay more money for the addresses being sold than all the LIRs with actual and possibly desperate operational need. This seems rather far-fetched to me. > What happens when a vital ressource becomes rare usually ? Free market > is regulated, rationing is set in place for everyone to get a chance to > survive. Cheaters make black market that restores "free market" logic, > where richest buy first and poors starve. > > Allocation transfer allows the black market to I does not lead to abuse > since regulation of final step selling is in place. Deregulation makes > money oriented reselling allowed. This is black market made legal, > rationing screwing. So if we going to have a market where LIRs trade allocations in any case, isn't it then better to make the market white, rather than black? Keep in mind that one of the stated goals of the address policy is: ?Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.? The existence of a black market runs counter to this goal, because the NCC will not be informed of the transactions and therefore won't be able to keep the registry up to date. > I think you got my point. As I understand it, you're principally opposed to direct LIR-to-LIR transfers of any sort, and would like to see the NCC instead reclaim and redistribute unused address space from the LIRs according to a need principle. Since 2013-03 is relaxing the existing rules covering LIR-to-LIR transfers to some extent, you are opposed to the proposal. Is that about the gist of it? Best regards, Tore Anderson From tore at fud.no Tue Mar 26 05:15:43 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 26 Mar 2013 05:15:43 +0100 Subject: [address-policy-wg] minimum allocation size in case of transform addresses In-Reply-To: <5150D87B.6000008@umn.edu> References: <5150CDD4.8040002@aramin.net> <5150D87B.6000008@umn.edu> Message-ID: <515120EF.10602@fud.no> * Andrzej Dopiera?a >> I found today out, that there is planed possibility to convert PI >> assignments to PA allocation. >> But - i'ts planed only for /22 and bigger assignments, due to minimum >> allocation size, and doesn't apply for example /23 or /22 assignemnts. >> >> I think it's a bit pointless. Agreed. If the assignment is smaller than the minimum allocation size to begin with, I don't see any harm in allowing one to convert to PA completely as long as it's a one-to-one swap that does not cause further deaggregation. For what it's worth, there are already several allocations smaller than the minimum allocation size in effect at the time they were made: ripencc|GB|ipv4|79.143.80.0|1024|20120810|allocated ripencc|GB|ipv4|79.143.84.0|1024|20120810|allocated ripencc|FR|ipv4|82.196.24.0|1024|20031027|allocated ripencc|FR|ipv4|82.196.28.0|1024|20031027|allocated ripencc|BG|ipv4|84.238.192.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.196.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.200.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.204.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.216.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.220.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.224.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.228.0|1024|20040810|allocated ripencc|CZ|ipv4|91.201.20.0|1024|20080123|allocated ripencc|DE|ipv4|128.0.152.0|1024|20120914|allocated ripencc|IL|ipv4|192.114.84.0|1024|19990603|allocated ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated ripencc|DE|ipv4|193.218.216.0|1024|19981110|allocated ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated ripencc|IT|ipv4|194.153.208.0|1024|20000509|allocated ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated ripencc|PL|ipv4|195.140.236.0|1024|20031001|allocated ripencc|DE|ipv4|213.153.80.0|1024|20000324|allocated ripencc|DE|ipv4|213.153.84.0|1024|20000324|allocated I don't know why and how they came about, but they're there at least. * David Farmer > This is one reason to not completely eliminate all the existing IPv4 > policies with 2013-03. They can still be useful, and may be useful in > the future. Otherwise, you have to revisit the consensus for issues > like what the appropriate minimum allocations size should be in what > situations. Please read 2013-03 more carefully. It retains the concept of a minimum allocation size. It does change it from the obsolete and incorrect /21 (which hasn't been true since the implementation of the last /8 policy) to the correct /22, though. Quoting from the proposed policy: ?The RIPE NCC's minimum allocation size is /22?. When it comes to assignments, there is currently no minimum size defined in the policy, and 2013-03 does not change this in any way. That said, ripe-555 documents that: ?The smallest prefix assigned by the RIPE NCC from any IPv4 range is a /29?. Tore From jan at go6.si Tue Mar 26 09:28:53 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 26 Mar 2013 09:28:53 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5150B0A0.7040705@opdop.net> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514CBA30.7060604@opdop.net> <5150173E.8080809@fud.no> <5150B0A0.7040705@opdop.net> Message-ID: <51515C45.5060401@go6.si> On 3/25/13 9:16 PM, Sylvain Vallerot wrote: > Selling to richest first is possible with 2013-3 deregulation. Welcome to the world of basic business rules :) Cheers, Jan P.S: Natural selection mechanism works for us for a very long time already ;) From swmike at swm.pp.se Tue Mar 26 09:47:12 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 26 Mar 2013 09:47:12 +0100 (CET) Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <51510435.4020902@fud.no> References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514CBA30.7060604@opdop.net> <5150173E.8080809@fud.no> <5150B0A0.7040705@opdop.net> <51510435.4020902@fud.no> Message-ID: On Tue, 26 Mar 2013, Tore Anderson wrote: > So imagine you're an LIR. You've just spent 1 million euros on a > good-as-new /16. What on Earth would cause you to then go ahead and > ?assign it without any control?? Exactly. There is no need to push conservation for IPv4 from the outside anymore. RIPE and other RIRs should keep the documentation up to date and let people trade their addresses and use them as they see fit. IPv4 is exhausted. The stone is bled try. Stop trying to squeeze it. Let people who want to stay in IPv4 land pay for the privilege. There is IPv6 addresses at low-low prices, let the people who go that route pay for some of the (potentially higher) investment by either selling, or not having to buy IPv4 addresses. PS. I personally believe the prices some brokers are trying to sell addresses are way too high. If the price was USD 5-20 per IPv4 address (as they seem to think), I believe there will be a lot of sellers. I have yet to hear someone wanting to *buy* at those price points, only sellers. Those price points would pay for a lot of CGN boxes and still make a hefty profit. -- Mikael Abrahamsson email: swmike at swm.pp.se From ggiannou at gmail.com Tue Mar 26 10:39:55 2013 From: ggiannou at gmail.com (George Giannousopoulos) Date: Tue, 26 Mar 2013 11:39:55 +0200 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: Hello all, +1 from me for the proposal George On Tue, Mar 19, 2013 at 6:00 PM, Emilio Madaio wrote: > > Dear Colleagues > > A proposed change to RIPE Document ripe-582, "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/2013-03 > > We encourage you to review this proposal and send your comments to > before 16 April 2013. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boggits at gmail.com Tue Mar 26 10:27:14 2013 From: boggits at gmail.com (boggits) Date: Tue, 26 Mar 2013 09:27:14 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514CBA30.7060604@opdop.net> <5150173E.8080809@fud.no> <5150B0A0.7040705@opdop.net> <51510435.4020902@fud.no> Message-ID: On 26 March 2013 08:47, Mikael Abrahamsson wrote: > On Tue, 26 Mar 2013, Tore Anderson wrote: > >> So imagine you're an LIR. You've just spent 1 million euros on a >> good-as-new /16. What on Earth would cause you to then go ahead and ?assign >> it without any control?? > > > Exactly. Because I can get 4 million by breaking it into smaller chunks at a higher per unit cost... J -- James Blessing 07989 039 476 From tore at fud.no Tue Mar 26 12:39:45 2013 From: tore at fud.no (Tore Anderson) Date: Tue, 26 Mar 2013 12:39:45 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514CBA30.7060604@opdop.net> <5150173E.8080809@fud.no> <5150B0A0.7040705@opdop.net> <51510435.4020902@fud.no> Message-ID: <51518901.90600@fud.no> * boggits > On 26 March 2013 08:47, Mikael Abrahamsson wrote: >> On Tue, 26 Mar 2013, Tore Anderson wrote: >> >>> So imagine you're an LIR. You've just spent 1 million euros on a >>> good-as-new /16. What on Earth would cause you to then go ahead and ?assign >>> it without any control?? >> >> Exactly. > > Because I can get 4 million by breaking it into smaller chunks at a > higher per unit cost... The LIR holding the original allocation could do the exact same thing, so what is the damage inflicted on the RIPE community and membership here? IMHO it would is much more likely that a original LIR would do something like this, rather than a "middleman LIR", because such a middleman LIR will need to wait 24 months before it can start selling the smaller chunks on to other LIRs. -- Tore Anderson From mueller at syr.edu Tue Mar 26 14:25:25 2013 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 26 Mar 2013 13:25:25 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA36B56@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <8DA1853CE466B041B104C1CAEE00B3748FA36B56@CHAXCH01.corp.arin.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD238FB59@SUEX10-mbx-10.ad.syr.edu> Your understanding is incorrect. ARIN operates the registry in accordance with the policy developed by ARIN region, and resources in the registry are therefore completely subject to those policies. As I noted earlier, we'd prefer contracts where possible, but even a party that does not have a formal contract can chose to participate or not. You can use any numbers you want in your routers, but if you wish to use numbers which are unique per the Internet Registry system, then you are participating in the Internet Registry system, gaining the benefits thereof, and therefore are subject to the policies used in its coordination & operation. Like I said, "fuss and bluster." This is an assertion of authority with nothing to back it up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Tue Mar 26 14:30:28 2013 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 26 Mar 2013 13:30:28 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748F9EFF31@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD237AD9A@SUEX10-mbx-10.ad.syr.edu> <514A1913.8090204@opdop.net> <514AD315.7010309@fud.no> <514AE391.8080705@opdop.net> <514B08A4.60902@fud.no> <514B1A18.2080608@fud.no> <514CBA30.7060604@opdop.net> <5150173E.8080809@fud.no> <5150B0A0.7040705@opdop.net> <51510435.4020902@fud.no> Message-ID: <855077AC3D7A7147A7570370CA01ECD2391B73@SUEX10-mbx-10.ad.syr.edu> FWIW, studies of the actual transfer market so far indicate that per unit prices fetched by numbers are the same or higher for large blocks than for small blocks > -----Original Message----- > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of boggits > Sent: Tuesday, March 26, 2013 5:27 AM > Cc: Address Policy Working Group > Subject: Re: [address-policy-wg] 2013-03 New Policy Proposal (No Need - > Post-Depletion Reality Adjustment and Cleanup) > > On 26 March 2013 08:47, Mikael Abrahamsson wrote: > > On Tue, 26 Mar 2013, Tore Anderson wrote: > > > >> So imagine you're an LIR. You've just spent 1 million euros on a > >> good-as-new /16. What on Earth would cause you to then go ahead and > >> it without any control>? > > > > > > Exactly. > > Because I can get 4 million by breaking it into smaller chunks at a > higher per unit cost... > > > J > -- > > James Blessing > 07989 039 476 From gert at space.net Tue Mar 26 14:33:58 2013 From: gert at space.net (Gert Doering) Date: Tue, 26 Mar 2013 14:33:58 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> Message-ID: <20130326133358.GZ51699@Space.Net> Hi, On Mon, Mar 25, 2013 at 10:47:35PM +0000, John Curran wrote: > Not likely to succeed, as it would be contrary to policy in the ARIN region. I can't see how stating "we are the masters of all american IP addresses!" can give you a legal claim on something assigned before ARIN existed, unless the holder either voluntarily accepts that claim, or had a contract with IANA/InterNIC that stated "should an American RIR emerge one day, these address blocks automatically fall under their policy". So - assuming no contract exists, what can you *do* if someone wants to transfer their Space to an entity in RIPE land? "Refuse to remove their database entry"? "Bully the RIPE NCC to not add a database entry?" Your stick is small... 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 From lists-ripe at c4inet.net Tue Mar 26 14:37:56 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 26 Mar 2013 13:37:56 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130326133358.GZ51699@Space.Net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> Message-ID: <20130326133756.GA93056@cilantro.c4inet.net> On Tue, Mar 26, 2013 at 02:33:58PM +0100, Gert Doering wrote: >Your stick is small... They make up for that by not speaking very softly... ;p sncr, Sascha Luck >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 > From jcurran at arin.net Tue Mar 26 14:54:07 2013 From: jcurran at arin.net (John Curran) Date: Tue, 26 Mar 2013 13:54:07 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130326133358.GZ51699@Space.Net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> On Mar 26, 2013, at 9:33 AM, Gert Doering wrote: > I can't see how stating "we are the masters of all american IP addresses!" > can give you a legal claim on something assigned before ARIN existed, > unless the holder either voluntarily accepts that claim, or had a contract > with IANA/InterNIC that stated "should an American RIR emerge one day, > these address blocks automatically fall under their policy". Actually, the US Government, at the formation of ARIN stated exactly that: "Creation of ARIN will give the users of IP numbers (mostly Internet service providers, corporations and other large institutions) a voice in the policies by which they are managed and allocated within the North American region." As I noted, ARIN operates the registry according to the policies set by the community in the region, these policies define how IP addresses are managed and allocated in the region, and this is as expected since our formation. Attempts to transfer resources contrary to policy make resource subject to reclamation per the community-develop guidelines for resource review. Recently, the lead USG agency in these matters (National Telecommunications and Information Administration, aka NTIA) affirmed the USG Internet numbering principles, including that it recognizes ARIN as the RIR for this region and is supportive of the policies agreed upon by the Internet technical community through ARIN for the region. Community-based Internet self-governance means exactly that, not that policies which are inconvenient don't apply. Feel free to let me know if you have any other questions in this matter, whether on this list or one of the ARIN lists if you prefer. Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Tue Mar 26 15:17:00 2013 From: jcurran at arin.net (John Curran) Date: Tue, 26 Mar 2013 14:17:00 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) (more) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA4044C@CHAXCH01.corp.arin.net> On Mar 26, 2013, at 9:54 AM, John Curran wrote: > > Community-based Internet self-governance means exactly that, not that policies > which are inconvenient don't apply. ... which is why I've emphasized repeatedly in the discussion that there is nothing fundamentally wrong about a mismatch in transfer policies between the regions, other than the fact that it would mean additional discussion in both regions about the value of alignment and options for getting there. RIPE should feel free set transfer policy that applies to resources in its region, but I'd recommend against developing policy based on a belief that ARIN policies don't apply to resources in its region, as the outcome will not match expectations. FYI, /John John Curran President and CEO ARIN From gert at space.net Tue Mar 26 15:25:34 2013 From: gert at space.net (Gert Doering) Date: Tue, 26 Mar 2013 15:25:34 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) (more) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA4044C@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FA4044C@CHAXCH01.corp.arin.net> Message-ID: <20130326142533.GD51699@Space.Net> Hi, On Tue, Mar 26, 2013 at 02:17:00PM +0000, John Curran wrote: > On Mar 26, 2013, at 9:54 AM, John Curran wrote: > > > > Community-based Internet self-governance means exactly that, not that policies > > which are inconvenient don't apply. > > ... which is why I've emphasized repeatedly in the discussion that there is > nothing fundamentally wrong about a mismatch in transfer policies between > the regions, other than the fact that it would mean additional discussion > in both regions about the value of alignment and options for getting there. > > RIPE should feel free set transfer policy that applies to resources in its > region, but I'd recommend against developing policy based on a belief that > ARIN policies don't apply to resources in its region, as the outcome will > not match expectations. Be assured, we don't do RIPE region policy based on ARIN beliefs. This was just a quite interesting and enlightening side-track discussion (even though I'm still missing an answer to the question what ARIN is going to do if a pre-ARIN address space holder without a contract with ARIN decides to sell their address space to a RIPE member). 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From nick at inex.ie Tue Mar 26 15:48:18 2013 From: nick at inex.ie (Nick Hilliard) Date: Tue, 26 Mar 2013 14:48:18 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> Message-ID: <5151B532.7060003@inex.ie> On 26/03/2013 13:54, John Curran wrote: > Actually, the US Government at the formation of ARIN stated exactly > that: > "Creation of ARIN will give the users of IP numbers (mostly Internet service > providers, corporations and other large institutions) a voice in the policies > by which they are managed and allocated within the North American region." > that was said by the NSF, which described itself as "an independent federal agency that supports fundamental research and education" at the bottom of that press release. Nothing particularly to do with USG, and it would be extraordinary to claim that this press release endowed any legal status. > Community-based Internet self-governance means exactly that, not that policies > which are inconvenient don't apply. My understanding is that ARIN's authority over legacy resources has not been tested in a federal district court. Until it's reached some firm conclusion, I'd be circumspect about authoritatively claiming authority. Please correct me if I'm wrong here because I don't pay too much attention to arinland numbering politics. Otherwise, I wish you well policing those legacy holders who feel that they are not inclined to sign the LRSA. Nick From jcurran at arin.net Tue Mar 26 16:06:21 2013 From: jcurran at arin.net (John Curran) Date: Tue, 26 Mar 2013 15:06:21 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5151B532.7060003@inex.ie> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> On Mar 26, 2013, at 10:48 AM, Nick Hilliard wrote: > On 26/03/2013 13:54, John Curran wrote: >> Actually, the US Government at the formation of ARIN stated exactly >> that: >> "Creation of ARIN will give the users of IP numbers (mostly Internet service >> providers, corporations and other large institutions) a voice in the policies >> by which they are managed and allocated within the North American region." >> > > that was said by the NSF, which described itself as "an independent federal > agency that supports fundamental research and education" at the bottom of > that press release. Nothing particularly to do with USG, and it would be > extraordinary to claim that this press release endowed any legal status. NSF was the USF agency which issued and provided oversight to the InterNIC award performing these exact same functions (and additional ones related to DNS) in the Internet's early years. >> Community-based Internet self-governance means exactly that, not that policies >> which are inconvenient don't apply. > > My understanding is that ARIN's authority over legacy resources has not > been tested in a federal district court. Until it's reached some firm > conclusion, I'd be circumspect about authoritatively claiming authority. I am describing clearly _ARIN's_ position and how we operate the registry. There are certainly a few courts in the US (and just a few lawyers ;-) but Gert asked what the "InterNIC" stated at ARIN's formation, and so I answered. As I've said before, it's relevance to RIPE policy development is likely questionable, and I'd be happy to address these topics on the ARIN mailing lists if that's preferred. Thanks! /John John Curran President and CEO ARIN From nick at inex.ie Tue Mar 26 16:19:12 2013 From: nick at inex.ie (Nick Hilliard) Date: Tue, 26 Mar 2013 15:19:12 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> Message-ID: <5151BC70.3000506@inex.ie> On 26/03/2013 15:06, John Curran wrote: > I am describing clearly _ARIN's_ position and how we operate the registry. I understand you have a position... > There are certainly a few courts in the US (and just a few lawyers ;-) ...but none of these courts have actually ruled in favour of your position, correct? Nick From mueller at syr.edu Tue Mar 26 17:26:14 2013 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 26 Mar 2013 16:26:14 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD2396CBA@SUEX10-mbx-10.ad.syr.edu> > -----Original Message----- > > NSF was the USF agency which issued and provided oversight to the InterNIC > award performing these exact same functions (and additional ones related to > DNS) in the Internet's early years. And here is what the General Counsel of the NSF said about this: http://www.internetgovernance.org/2012/09/22/its-official-legacy-ipv4-address-block-holders-own-their-number-blocks/ > answered. As I've said before, it's relevance to RIPE policy development > is likely questionable, and I'd be happy to address these topics on the > ARIN mailing lists if that's preferred. Apologies from me, too for sidetracking RIPE needs assessment policy based on an internal ARIN tussle. But....he started it! ;-) From jcurran at arin.net Tue Mar 26 18:13:21 2013 From: jcurran at arin.net (John Curran) Date: Tue, 26 Mar 2013 17:13:21 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2396CBA@SUEX10-mbx-10.ad.syr.edu> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD2396CBA@SUEX10-mbx-10.ad.syr.edu> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA437A5@CHAXCH01.corp.arin.net> On Mar 26, 2013, at 12:26 PM, Milton L Mueller wrote: >> -----Original Message----- >> >> NSF was the USF agency which issued and provided oversight to the InterNIC >> award performing these exact same functions (and additional ones related to >> DNS) in the Internet's early years. > > And here is what the General Counsel of the NSF said about this: > http://www.internetgovernance.org/2012/09/22/its-official-legacy-ipv4-address-block-holders-own-their-number-blocks/ Apologies to the RIPE community. Milton is referencing a letter which was followed up by the same person noting that it just his observations and not the US government position as NTIA is authoritative in these matters - NTIA subsequently issued the USG's Internet Protocol numbering principles, as I noted earlier, including that it recognizes ARIN as the RIR for its region and is supportive of ARIN's policies. Milton hasn't apparently updated his blog based on this withdrawal. The full set of letters involved (with references) may by found at the bottom of this page: FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Tue Mar 26 19:57:24 2013 From: jcurran at arin.net (John Curran) Date: Tue, 26 Mar 2013 18:57:24 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5151BC70.3000506@inex.ie> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> <5151BC70.3000506@inex.ie> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA45D78@CHAXCH01.corp.arin.net> On Mar 26, 2013, at 11:19 AM, Nick Hilliard wrote: > ...but none of these courts have actually ruled in favour of your position, > correct? Actually, that is incorrect. We have had a ruling from federal district court and it upheld our position in being able to manage number resources in accordance with the policy in the region. I would not call 100% definitive ruling because it was not based on hearing of the potential fullness of the topic but instead limited by the specific legal circumstances. We've also been heavily involved in bankruptcy courts with respect to number resource transfers, and all of these have been resolved in compliance with the number resource policy developed by the community in the ARIN region. You may find references to these cases in the following article: I will reiterate for avoidance of any doubt and to bring this back to the topic at hand: the RIPE community should feel free set any transfer policy that applies to resources in its region, but I'd recommend against developing policy based on a belief that ARIN policies don't apply to all resources in the ARIN region, as the outcome will not match expectations. FYI, /John John Curran President and CEO ARIN p.s. I expect some of the RIPE folks have now had more than their dose of legal fun for the day and would suggest followups to ARIN ppml or ARIN discuss (but obviously will remain available as a resource if folks really want to continue the discussion on the RIPE address-policy-wg list...) From mueller at syr.edu Tue Mar 26 20:33:29 2013 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 26 Mar 2013 19:33:29 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA437A5@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD2396CBA@SUEX10-mbx-10.ad.syr.edu> <8DA1853CE466B041B104C1CAEE00B3748FA437A5@CHAXCH01.corp.arin.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD2397F99@SUEX10-mbx-10.ad.syr.edu> John, you are really flirting with outright misrepresentation of the facts. The NSF letter expressed a detailed legal opinion of the counsel who represents the organization that made the legacy allocations. He did not "withdraw" his opinion, he simply stated that it was his legal opinion and not a US government position. But absent legislation, or a court ruling that contradicts the NSF Counsel's decision, the "position" of the NTIA is quite irrelevant. NTIA has no legislative authority and no judicial authority. It can express US government policy, but it cannot dictate law. You know this as well as I. So here is the real score: - We have one legal opinion that ARIN has no authority over legacy holders - We have NO legal opinions that support ARIN's claim of authority over legacy holders. - We have no court decisions that conclusively rule that ARIN does have authority over legacy holders. - We have a broad statement from NTIA which does not directly address that issue.* Those are the facts. Best to leave it at that. * The NTIA statement says only that Regional Internet Registries (RIRS) are responsible for IP address policy development (an uncontested fact); that ARIN is the RIR for North America (another fact) and that the USG "is supportive of the policies, processes, and procedures agreed upon ... through ARIN." This statement completely sidesteps the issue of whether ARIN has authority over legacy holders. See the IGP blog discussing the principles here: http://www.internetgovernance.org/2012/12/06/ntias-meaningless-numbering-principles/ > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Tuesday, March 26, 2013 1:13 PM > To: Milton L Mueller > Cc: Nick Hilliard; address-policy-wg at ripe.net Group > Subject: Re: [address-policy-wg] 2013-03 New Policy Proposal (No Need - > Post-Depletion Reality Adjustment and Cleanup) > > On Mar 26, 2013, at 12:26 PM, Milton L Mueller wrote: > > >> -----Original Message----- > >> > >> NSF was the USF agency which issued and provided oversight to the > InterNIC > >> award performing these exact same functions (and additional ones > related to > >> DNS) in the Internet's early years. > > > > And here is what the General Counsel of the NSF said about this: > > http://www.internetgovernance.org/2012/09/22/its-official-legacy-ipv4- > address-block-holders-own-their-number-blocks/ > > Apologies to the RIPE community. Milton is referencing a letter which was > followed up by the same person noting that it just his observations and > not the US government position as NTIA is authoritative in these matters - > > 7NOV2012.pdf> > > NTIA subsequently issued the USG's Internet Protocol numbering principles, > as I noted earlier, including that it recognizes ARIN as the RIR for its > region and is supportive of ARIN's policies. Milton hasn't apparently > updated his blog based on this withdrawal. > > The full set of letters involved (with references) may by found at the > bottom of this page: > > FYI, > /John > > John Curran > President and CEO > ARIN > > From jcurran at arin.net Wed Mar 27 00:36:19 2013 From: jcurran at arin.net (John Curran) Date: Tue, 26 Mar 2013 23:36:19 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD2397F99@SUEX10-mbx-10.ad.syr.edu> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD2396CBA@SUEX10-mbx-10.ad.syr.edu> <8DA1853CE466B041B104C1CAEE00B3748FA437A5@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD2397F99@SUEX10-mbx-10.ad.syr.edu> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA47410@CHAXCH01.corp.arin.net> On Mar 26, 2013, at 3:33 PM, Milton L Mueller wrote: > John, you are really flirting with outright misrepresentation of the facts. Milton - I understand that you may hold to different views (and I respect your right to do so) but it would be appreciated if you could seek to have professional level of dialogue. We definitely don't agree as to the "facts", but in the above, you seem to go beyond and imply that I am speaking to something other than that which I know to be true, which would be a rather serious accusation. If you have any doubt about my veracity at any time, please feel free to contact the ARIN Board with your concerns for prompt attention regarding my removal To best of my knowledge, everything I've stated is correct; I stand willing to swear to it (and likely will have an opportunity to do exactly that some point...) > The NSF letter expressed a detailed legal opinion of the counsel who represents the organization that made the legacy allocations. > He did not "withdraw" his opinion, he simply stated that it was his legal opinion and not a US government position. Incorrect, as a "legal opinion" has a well-known meaning, that being the explanation of a ruling issued by a court or agency, and by its very definition is indeed a US Government position if issued by an agency. The "observations" (the term Mr. Rudolph's uses to describe his USG disavowed letter) of an individual attorney do not constitute a "legal opinion", and particularly not when they are not the position of his agency. Note - this probably a good thing considering the quality of the work involved... I'd recommend folks review ARIN's response here which notes the failure to consider NSF's own statement of work for the InterNIC at the time, its facile treatment of rights and policies per existing RFCs which predated ARIN, and related oversights in the logic from the NSF GC's letter of "observations" and "beliefs" > But absent legislation, or a court ruling that contradicts the NSF Counsel's > decision, the "position" of the NTIA is quite irrelevant. "Decision"? His views did not constitute a decision (or even a position) of any part of the US Government, whereas the NTIA statement is most certainly an official position. I concur that its not a legal opinion, but it was not intended to be one. It simply states it is the official US Government position to be supportive of ARIN and its policies. > So here is the real score: > - We have one legal opinion that ARIN has no authority over legacy holders > - We have NO legal opinions that support ARIN's claim of authority over legacy holders. We'll need to agree to disagree on the above "facts", as you call them, since there is real disagreement over whether a letter issued by a US agency General Counsel that expresses no ruling (and then once contested then gets clarified to be simply his observations and beliefs) somehow constitutes a letter of "legal opinion", by any known use of the term. > - We have no court decisions that conclusively rule that ARIN does have authority over legacy holders. We have multiple courts who have ordered that ARIN is not required to take any action in violation of ARIN?s Policies nor is it required to apply a different standard to the transfer of legacy versus non-legacy Internet Protocol numbers. (In re Borders Group, Inc., 11-10614 (Bankr. S.D.N.Y.), In re Teknowledge Corporation; 10-60457 (Bankr. N.D. Cal.) and Global NAPS, Inc. v. Verizon New England, Inc., etc.) Whether those orders are conclusive to a judge remains to be determined; I am neither lawyer nor judge and don't presume to know that outcome. > - We have a broad statement from NTIA which does not directly address that issue.* Agreement on this one - as you noted, a statement of US Government position from an agency are not law, so it should not be surprising that the statement cannot directly address what you may perceive to be a potential legal issue. It is simply a statement of official US Government position to be supportive of ARIN and its policies in management for number resources in the region (that was issued after the clarification by the NSF GC that his letter suggesting otherwise was simply his "observations" and "beliefs" and definitely not any position of the US Government.) Based on the full set of facts above, ARIN has no concern operating the registry according to the policies set by the community in our region; actually, our most likely risk would come from failing to apply the policies to all number resources consistently. Thanks! /John John Curran President and CEO ARIN p.s. Apologies again to those in the RIPE region; tl;dr is that ARIN will apply policies to all resources in the region, and that point may be relevant when considering inter-RIR implications of policies developed on this mailing list. From randy at psg.com Wed Mar 27 02:15:50 2013 From: randy at psg.com (Randy Bush) Date: Wed, 27 Mar 2013 10:15:50 +0900 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> Message-ID: > Actually, the US Government, at the formation of ARIN stated exactly > that: "Creation of ARIN will give the users of IP numbers (mostly > Internet service providers, corporations and other large institutions) > a voice in the policies by which they are managed and allocated within > the North American region." to paraphrase others, yes, you certainly have a voice. to those who are not facile english speakers, this does not imply that john's assertion has actual legal weight. it is a tragedy that arin places power above the good of the internet. randy From jcurran at arin.net Wed Mar 27 02:37:06 2013 From: jcurran at arin.net (John Curran) Date: Wed, 27 Mar 2013 01:37:06 +0000 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA48146@CHAXCH01.corp.arin.net> On Mar 26, 2013, at 9:15 PM, Randy Bush wrote: >> Actually, the US Government, at the formation of ARIN stated exactly >> that: "Creation of ARIN will give the users of IP numbers (mostly >> Internet service providers, corporations and other large institutions) >> a voice in the policies by which they are managed and allocated within >> the North American region." > > to those who are not facile english speakers, this does not imply that > john's assertion has actual legal weight. Actually, it was NSF's statement, but your point holds true. In the end, the legal weight of such statements will likely be determined though judges making case law. /John John Curran President and CEO ARIN From tore at fud.no Wed Mar 27 09:02:11 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 27 Mar 2013 09:02:11 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA45D78@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> <5151BC70.3000506@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA45D78@CHAXCH01.corp.arin.net> Message-ID: <5152A783.8090700@fud.no> * John Curran > I will reiterate for avoidance of any doubt and to bring this back to > the topic at hand: the RIPE community should feel free set any > transfer policy that applies to resources in its region, but I'd > recommend against developing policy based on a belief that ARIN > policies don't apply to all resources in the ARIN region, as the > outcome will not match expectations. Hi John, Let me reassure you that 2013-03 was not written with any particular understanding of ARIN's "jurisdiction" in mind, one way or the other. 2013-03 doesn't really concern itself with extra-region matters. The "legal" status of legacy space and how the RIRs should deal with it is certainly an interesting topic, and not only in the ARIN region; such a discussion is ongoing in the RIPE region too, cf. proposal 2012-07. However, I consider that this topic is not really germane to the discussion of 2013-03. Fortunately, I have not seen anyone making arguments in favour of, or in opposition to, 2013-03 based on an opinion of the status of legacy space in the ARIN region. So I don't think we have anything to worry about in this regard - the PDP can handle the discussion of a proposal side-tracking into off-topic topics once in a while. After all, this is a public mailing list, so I don't think we can expect anything else. :-) Best regards, -- Tore Anderson From nick at inex.ie Wed Mar 27 12:58:22 2013 From: nick at inex.ie (Nick Hilliard) Date: Wed, 27 Mar 2013 11:58:22 +0000 Subject: [address-policy-wg] ARIN position on other RIR resources (was: Re: 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup)) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA45D78@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> <5151BC70.3000506@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA45D78@CHAXCH01.corp.arin.net> Message-ID: <5152DEDE.7020805@inex.ie> On 26/03/2013 18:57, John Curran wrote: > I will reiterate for avoidance of any doubt and to bring this back to the topic > at hand: the RIPE community should feel free set any transfer policy that applies > to resources in its region, but I'd recommend against developing policy based on > a belief that ARIN policies don't apply to all resources in the ARIN region, as > the outcome will not match expectations. [...] > p.s. I expect some of the RIPE folks have now had more than their dose of legal fun > for the day and would suggest followups to ARIN ppml or ARIN discuss (but obviously > will remain available as a resource if folks really want to continue the discussion > on the RIPE address-policy-wg list...) John, I think this is very much germane to apwg even though it doesn't relate to 2013-03. Are you talking here about RIR resources which are formally transferred to ARIN, or resources from other RIRs which are transferred or deployed somewhere in the ARIN service region, but still administered by those other RIRs? Nick From jcurran at arin.net Wed Mar 27 13:11:55 2013 From: jcurran at arin.net (John Curran) Date: Wed, 27 Mar 2013 12:11:55 +0000 Subject: [address-policy-wg] ARIN position on other RIR resources (was: Re: 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup)) In-Reply-To: <5152DEDE.7020805@inex.ie> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> <5151BC70.3000506@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA45D78@CHAXCH01.corp.arin.net> <5152DEDE.7020805@inex.ie> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA49645@CHAXCH01.corp.arin.net> > On Mar 27, 2013, at 7:58 AM, Nick Hilliard wrote: >> ... I'd recommend against developing policy based on a belief that >> ARIN policies don't apply to all resources in the ARIN region, as >> the outcome will not match expectations. > > John, I think this is very much germane to apwg even though it doesn't > relate to 2013-03. Are you talking here about RIR resources which are > formally transferred to ARIN, or resources from other RIRs which are > transferred or deployed somewhere in the ARIN service region, but still > administered by those other RIRs? By "in the ARIN region", I meant resources _in the ARIN registry_ This is common practice, i.e., I believe that each RIR administers resources in their registry per the policies which are developed by their community's processes. FYI, /John John Curran President and CEO ARIN From nick at inex.ie Wed Mar 27 13:31:13 2013 From: nick at inex.ie (Nick Hilliard) Date: Wed, 27 Mar 2013 12:31:13 +0000 Subject: [address-policy-wg] ARIN position on other RIR resources In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA49645@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> <5151BC70.3000506@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA45D78@CHAXCH01.corp.arin.net> <5152DEDE.7020805@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA49645@CHAXCH01.corp.arin.net> Message-ID: <5152E691.2060609@inex.ie> On 27/03/2013 12:11, John Curran wrote: > By "in the ARIN region", I meant resources _in the ARIN registry_ > > This is common practice, i.e., I believe that each RIR administers > resources in their registry per the policies which are developed > by their community's processes. ah, ok. What you said initially could have been interpreted differently. Just wanted to clarify. Nick From jcurran at arin.net Wed Mar 27 13:34:10 2013 From: jcurran at arin.net (John Curran) Date: Wed, 27 Mar 2013 12:34:10 +0000 Subject: [address-policy-wg] ARIN position on other RIR resources In-Reply-To: <5152E691.2060609@inex.ie> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> <5151BC70.3000506@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA45D78@CHAXCH01.corp.arin.net> <5152DEDE.7020805@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA49645@CHAXCH01.corp.arin.net> <5152E691.2060609@inex.ie> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA49FAF@CHAXCH01.corp.arin.net> On Mar 27, 2013, at 8:31 AM, Nick Hilliard wrote: > On 27/03/2013 12:11, John Curran wrote: >> By "in the ARIN region", I meant resources _in the ARIN registry_ >> >> This is common practice, i.e., I believe that each RIR administers >> resources in their registry per the policies which are developed >> by their community's processes. > > ah, ok. What you said initially could have been interpreted differently. > Just wanted to clarify. Agreed (and good to clarify...) Thanks! /John John Curran President and CEO ARIN From rogerj at gmail.com Wed Mar 27 15:26:55 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Wed, 27 Mar 2013 15:26:55 +0100 Subject: [address-policy-wg] ARIN position on other RIR resources In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA49FAF@CHAXCH01.corp.arin.net> References: <20130321103352.ec289651d84890fcbef5f195936e1217.1d57b3c601.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD2381D9A@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD2381F88@SUEX10-mbx-10.ad.syr.edu> <45EBE1AC-017B-4DF9-A1B8-6D0A3BF50F2C@corp.arin.net> <20130326133358.GZ51699@Space.Net> <8DA1853CE466B041B104C1CAEE00B3748FA3FC0B@CHAXCH01.corp.arin.net> <5151B532.7060003@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA41933@CHAXCH01.corp.arin.net> <5151BC70.3000506@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA45D78@CHAXCH01.corp.arin.net> <5152DEDE.7020805@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA49645@CHAXCH01.corp.arin.net> <5152E691.2060609@inex.ie> <8DA1853CE466B041B104C1CAEE00B3748FA49FAF@CHAXCH01.corp.arin.net> Message-ID: On Wed, Mar 27, 2013 at 1:34 PM, John Curran wrote: > On Mar 27, 2013, at 8:31 AM, Nick Hilliard wrote: >> On 27/03/2013 12:11, John Curran wrote: >>> By "in the ARIN region", I meant resources _in the ARIN registry_ >>> >>> This is common practice, i.e., I believe that each RIR administers >>> resources in their registry per the policies which are developed >>> by their community's processes. >> >> ah, ok. What you said initially could have been interpreted differently. >> Just wanted to clarify. > > Agreed (and good to clarify...) > Thanks! > /John > > John Curran > President and CEO > ARIN I must say this has been a very interesting discussion to follow. Good to get a feel and see how other RIRs are thinking so to speak. thanks for being part of the discussion and adding another view to the table:-) -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From richih.mailinglist at gmail.com Sat Mar 30 01:39:16 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 30 Mar 2013 01:39:16 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: On Tue, Mar 19, 2013 at 5:00 PM, Emilio Madaio wrote: > A proposed change to RIPE Document ripe-582, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region", is now > available for discussion. I support this proposal. Three cosmetic comments; it would be nice if they could be incorporated. If not, they should _not_ hold up this process in any way. * "In the event that this /16 remains unused at the time the remaining addresses covered by this policy has been distributed, it returns to the pool to be distributed as per section 5.1, and this section is to be automatically deleted from the policy document." should read "have been distributed", instead. * "IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), must return their old peering LAN resources back to this pool within 180 days of assignment." uses IXP once and Internet Exchange [Pp]oint otherwise. Might clean that up just as well. Similarly, "Internet Exchange point" should be replaced with "Internet Exchange Point" * "Clear contractual arrangements are recommended and are mandatory for PA space." This could be worded more clearly. Are they recommended generally, but mandatory for PA? If yes, PI have contractual requirements as well so this could be mentioned here as well. An alternative interpretation would be that contracts are both mandatory and recommended for PA space which would be somewhat nonsensical. Richard From tore at fud.no Sat Mar 30 13:28:00 2013 From: tore at fud.no (Tore Anderson) Date: Sat, 30 Mar 2013 13:28:00 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: Message-ID: <5156DA50.8030108@fud.no> * Richard Hartmann > I support this proposal. Thank you! > Three cosmetic comments; it would be nice if they could be > incorporated. If not, they should _not_ hold up this process in any > way. > > * "In the event that this /16 remains unused at the time the remaining > addresses covered by this policy has been distributed, it returns to > the pool to be distributed as per section 5.1, and this section is to > be automatically deleted from the policy document." should read "have > been distributed", instead. No-brainer. Will incorporate, thanks. > * "IXPs holding other PI IPv4 space for their peering LAN (i.e. they > are seeking a larger assignment), must return their old peering LAN > resources back to this pool within 180 days of assignment." uses IXP > once and Internet Exchange [Pp]oint otherwise. Might clean that up > just as well. Similarly, "Internet Exchange point" should be replaced > with "Internet Exchange Point" I suggest abbreviating all references except for the first one (where the abbreviation is defined in the first place). Sounds good? > * "Clear contractual arrangements are recommended and are mandatory > for PA space." This could be worded more clearly. Are they recommended > generally, but mandatory for PA? If yes, PI have contractual > requirements as well so this could be mentioned here as well. An > alternative interpretation would be that contracts are both mandatory > and recommended for PA space which would be somewhat nonsensical. The original statement read: ?LIRs must make it clear to End Users which type of address space [PI vs PA] is assigned. Clear contractual arrangements are recommended and are mandatory for PA space.? I removed the first sentence as part of "cleanup", since PI is a thing of the past. Agreed that the remaining statement looks awkward on its own. Suggested new replacement: ?Clear contractual arrangements are mandatory for PA space.? In any case, contractual arrangements have been mandatory for both PI and PA space since 2007-01 was implemented, so the suggestion that it was "only" recommended for PI was in any case obsolete and incorrect policy. Good catch, thanks! Tore From richih.mailinglist at gmail.com Sat Mar 30 14:20:23 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 30 Mar 2013 14:20:23 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5156DA50.8030108@fud.no> References: <5156DA50.8030108@fud.no> Message-ID: On Sat, Mar 30, 2013 at 1:28 PM, Tore Anderson wrote: > I suggest abbreviating all references except for the first one (where > the abbreviation is defined in the first place). Sounds good? Yes. I almost suggested that, myself :) > I removed the first sentence as part of "cleanup", since PI is a thing > of the past. Agreed that the remaining statement looks awkward on its > own. Suggested new replacement: I still hope that IPv4 PI will come back, but that's for another day. > ?Clear contractual arrangements are mandatory for PA space.? How about simply extending it to cover everything: Clear contractual arrangements between LIRs and end users are mandatory for all RIPE resources (IP space and AS numbers). > Good catch, thanks! Good proposal, thanks. Richard From tore at fud.no Sat Mar 30 15:01:18 2013 From: tore at fud.no (Tore Anderson) Date: Sat, 30 Mar 2013 15:01:18 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <5156DA50.8030108@fud.no> Message-ID: <5156F02E.8000101@fud.no> * Richard Hartmann > I still hope that IPv4 PI will come back, but that's for another day. Yep, that's 2012-04. While 2013-03 will remove lots of *currently* obsolete text regarding PI, there's no reason why 2012-04 can't add the now-relevant-again bits back in. >> ?Clear contractual arrangements are mandatory for PA space.? > > How about simply extending it to cover everything: > > Clear contractual arrangements between LIRs and end users are > mandatory for all RIPE resources (IP space and AS numbers). No. This policy document changed by 2013-03 covers IPv4 address space only, so ASNs, IPv6, etc. is out of scope. Also, I don't want to have the proposal "accidentally" change the effective policy wrt. what kind of contractual arrangements are mandatory at what time, and since there's many types of legacy delegation types in existence there's a non-zero chance that removing the explicit reference to PA space in the above sentence will cause "jurisdiction creep", which in turn may be controversial in its own right, and require me to spin another version, and so on. I'd rather avoid taking that chance at this point. In a nutshell: 2013-03 amputates the dead policy limbs. Cosmetic surgery can follow later. :-) Tore From richih.mailinglist at gmail.com Sat Mar 30 15:33:55 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 30 Mar 2013 15:33:55 +0100 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <5156F02E.8000101@fud.no> References: <5156DA50.8030108@fud.no> <5156F02E.8000101@fud.no> Message-ID: On Sat, Mar 30, 2013 at 3:01 PM, Tore Anderson wrote: > Also, I don't want to have the proposal "accidentally" change the > effective policy wrt. what kind of contractual arrangements are > mandatory at what time, and since there's many types of legacy > delegation types in existence there's a non-zero chance that removing > the explicit reference to PA space in the above sentence will cause > "jurisdiction creep", which in turn may be controversial in its own > right, and require me to spin another version, and so on. I'd rather > avoid taking that chance at this point. In a nutshell: 2013-03 amputates > the dead policy limbs. Cosmetic surgery can follow later. :-) Very good point. Richard From gert at space.net Sun Mar 31 16:27:03 2013 From: gert at space.net (Gert Doering) Date: Sun, 31 Mar 2013 16:27:03 +0200 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: References: <5156DA50.8030108@fud.no> Message-ID: <20130331142703.GU51699@Space.Net> Hi, On Sat, Mar 30, 2013 at 02:20:23PM +0100, Richard Hartmann wrote: > > ?Clear contractual arrangements are mandatory for PA space.? > > How about simply extending it to cover everything: > > Clear contractual arrangements between LIRs and end users are > mandatory for all RIPE resources (IP space and AS numbers). Actually, for *PA*, they have always been "recommended" - mostly to ensure that customers are aware that they can't normally take the PA space away to other providers. For PI and AS numbers, they are mandatory since 2007-01. So changing this to "mandatory" for PA space would, in my reading, be a change of policy (... and opens up a new opportunity for bureaucracy, as in "being required to display the contract to the RIPE NCC upon an audit" or such). 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 From tore at fud.no Sun Mar 31 16:52:09 2013 From: tore at fud.no (Tore Anderson) Date: Sun, 31 Mar 2013 16:52:09 +0200 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <20130331142703.GU51699@Space.Net> References: <5156DA50.8030108@fud.no> <20130331142703.GU51699@Space.Net> Message-ID: <51584D99.2000606@fud.no> * Gert Doering > Actually, for *PA*, they have always been "recommended" - mostly to > ensure that customers are aware that they can't normally take the PA > space away to other providers. > > For PI and AS numbers, they are mandatory since 2007-01. > > So changing this to "mandatory" for PA space would, in my reading, be a > change of policy (... and opens up a new opportunity for bureaucracy, > as in "being required to display the contract to the RIPE NCC upon an > audit" or such). Hi Gert, The currently active policy document (ripe-582) says: ?LIRs must make it clear to End Users which type of address space is assigned. Clear contractual arrangements are recommended and are mandatory for PA space.? While I'm not a native English speaker, I have severe difficulties interpreting the above statement as anything but: * PA space -> clear contractual arrangements are *mandatory*. * Non-PA space -> clear contractual arrangements are *recommended*. This is from a section titled ?PA vs. PI Address Space?, so the way I interpret it it, you may substitute "Non-PA" with "PI" above, ergo we're left with: * PA space -> clear contractual arrangements are *mandatory*. * PI space -> clear contractual arrangements are *recommended*. Clearly, the last point is in conflict with 2007-01, but I'd assume that is just an oversight - 2007-01 should have updated it, but did not. Assuming 2007-01 takes precedence, then, the actual policy is: * PA space -> clear contractual arrangements are *mandatory*. * PI space -> clear contractual arrangements are *mandatory*. I hope you can follow my interpretation, or if not at least can point out where my mistake is. It it definitively *not* a goal of 2013-03 to add any contractual requirements where there was previously none, but it seems to me that in the PA case, they are already there. In this regard it we might consider it a goal of 2013-03 to not change anything, one way or the other (because that'd be "scope creep" which I really want to avoid). Tore From gert at space.net Sun Mar 31 21:49:45 2013 From: gert at space.net (Gert Doering) Date: Sun, 31 Mar 2013 21:49:45 +0200 Subject: [address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup) In-Reply-To: <51584D99.2000606@fud.no> References: <5156DA50.8030108@fud.no> <20130331142703.GU51699@Space.Net> <51584D99.2000606@fud.no> Message-ID: <20130331194945.GV51699@Space.Net> Hi, On Sun, Mar 31, 2013 at 04:52:09PM +0200, Tore Anderson wrote: > The currently active policy document (ripe-582) says: > > ?LIRs must make it clear to End Users which type of address space is > assigned. Clear contractual arrangements are recommended and are > mandatory for PA space.? Yeah. It would be good to know where this one sneaked in. The wording is indeed at least confusing, if not contradictory to 2007-01. But that one is out of 2013-03, so my recommendation would be to leave it at that (what you intended to do anyway) for the moment - and mark it for "this needs fixing" later on. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: