From gert at space.net Tue Mar 3 13:13:40 2015 From: gert at space.net (Gert Doering) Date: Tue, 3 Mar 2015 13:13:40 +0100 Subject: [address-policy-wg] 2014-04 Proposal Accepted - "Removing IPv6 Requirements for Receiving Space from the Final /8" In-Reply-To: <20150113135037.GA28837@Space.Net> References: <20150113135037.GA28837@Space.Net> Message-ID: <20150303121340.GW3147@Space.Net> Dear Address Policy WG, On Tue, Jan 13, 2015 at 02:50:37PM +0100, Gert Doering wrote: > The review phase for 2014-04 has ended. > > Given the amount of support over the lifetime of this proposal, and the > nature of the opposition, I have decided that we have reached rough > consensus (Sander as co-chair has abstained, because he has officially > taken an opionion). > > The main counterargument brought up was that this would lower the incentive > for LIRs to adopt IPv6 and would create the impression that IPv6 is no > longer important to the RIPE community. To counter that, the chairs will > ask the RIPE NCC to continue their good work in raising IPv6 awareness > and to continue to mention it on IPv4 /22 requests. > > So, I consider the counterarguments addressed, and see enough support to > declare rough consensus and move the proposal forward. The "last call" phase has now ended. Unlike most proposals, there was quite a bit of discussion in Last Call. After reviewing the messages sent, the chairs have decided that no new arguments have been brought up - and repetition of arguments that have been discussed and addressed before does not stop consensus, if strong support exists otherwise. It might be a bit more rough than for other proposals, but "rough consensus" is good enough. Thus, the chairs hereby declare consensus on 2014-04. If you disagree with this decision please contact the working group chairs (preferably on this public mailing list and otherwise by sending mail to apwg-chairs at ripe.net). Should that not resolve the problem then you can appeal to the WG chairs collective (as per section 4 of ripe-614). Marco will send the formal announcement from the NCC soon. regards, Gert Doering and Sander Steffann -- 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From gert at space.net Tue Mar 3 13:39:30 2015 From: gert at space.net (Gert Doering) Date: Tue, 3 Mar 2015 13:39:30 +0100 Subject: [address-policy-wg] 2014-05 - end of review phase (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: Message-ID: <20150303123930.GA98671@Space.Net> Dear AP WG, the review phase for 2014-05 has ended. While this proposal has taken quite a while to come to a conclusion, we seem to have quite strong support and no opposition now - nine persons spoke up in support of the proposal, and no other comments of any sort have been received. So, I declare we have consensus, and move 2014-05 to Last Call. Marco will send the formal announcement for that in the next days. For reference, a list of people that voiced support or opposition (or something else) in the previous review phase is appended below. This is what I have based my decision on. If you disagree with my interpretation of what has been said and the conclusion I have drawn from it, please let us know. Gert Doering, Address Policy WG Chair Review Phase for V3.0, starting Jan 16, 2015 Support: Mick O'Donovan Steve Wright (3 times!) Tore Anderson (some editorial gripes, but postponed addressing them in the unified transfer policy document showing on the horizon) Elvis Daniel Velea Mike Burns Guy Chilton Duncan Scotland Juan P. Cerezo Hamed Shafaghi Comments, Opposition: - -- 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From mschmidt at ripe.net Wed Mar 4 14:35:16 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 04 Mar 2015 14:35:16 +0100 Subject: [address-policy-wg] 2014-04 Proposal Accepted (Removing IPv6 Requirement for Receiving Space from the Final /8) Message-ID: Dear colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-623, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-04 The new RIPE Document is called ripe-632 and is available at: https://www.ripe.net/ripe/docs/ripe-632 The RIPE NCC has already begun preparations to implement this policy proposal. We estimate it may take a few weeks to make these changes and fully implement the policy proposal. Details of the implementation status are available at: https://www.ripe.net/lir-services/resource-management/policy-implementation-status We will send another announcement once the implementation is complete and the new procedures are in place. Thank you to everyone who provided their input. Regards, Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Thu Mar 5 13:37:31 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 05 Mar 2015 13:37:31 +0100 Subject: [address-policy-wg] 2014-05 Last Call for Comments (Policy for Inter-RIR Transfers of Internet Resources) Message-ID: Dear colleagues, The proposal described in 2014-05, "Policy for Inter-RIR Transfers of Internet Resources", 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 3 April 2015 and must be supported by an explanation. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-05 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 3 April 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From sander at steffann.nl Mon Mar 9 16:52:23 2015 From: sander at steffann.nl (Sander Steffann) Date: Mon, 9 Mar 2015 16:52:23 +0100 Subject: [address-policy-wg] Policy proposal 2014-03 "Remove Multihoming Requirement for AS Number Assignments" Message-ID: <0A98CCCC-A210-4145-BBD1-54A3A8CAB44F@steffann.nl> Hello working group, There has been a lot of discussion regarding policy proposal 2014-03 "Remove Multihoming Requirement for AS Number Assignments". There has been discussion on the the content of the proposal, the impact that the RIPE NCC charging scheme has and on the 'garbage collection' effects of the different ideas people have. We clearly don't have consensus on how to proceed. The working group chairs (Gert D?ring and myself) have therefore decided to extend the review phase. Because of the potential impact of the RIPE NCC charging scheme and because the ideas on this policy proposal seem to be diverging at the moment we have decided to extend it to after the RIPE meeting in Amsterdam. We realise this is a relatively long time but we feel that having a live discussion on this policy proposal is the best way forward. Marco will send the formal announcement shortly. Cheers, Sander Steffann Gert D?ring APWG chairs From mschmidt at ripe.net Mon Mar 9 16:57:20 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 09 Mar 2015 16:57:20 +0100 Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) Message-ID: Dear colleagues, The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has been extended until 19 May 2015. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-03 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt Policy Development Officer RIPE NCC From elvis at v4escrow.net Mon Mar 9 17:31:56 2015 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 09 Mar 2015 17:31:56 +0100 Subject: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations) In-Reply-To: <7E14378381A64697AF4E9DE754E6A4BE@Saeed> References: <5EC17651-C59E-4929-98C3-8D5A91D89720@nosignal.org> <1424370405.4066.10.camel@gmail.com> <54E74038.10204@v4escrow.net> <1424453215.5143.463.camel@galileo.millnert.se> <54E78E65.2030306@v4escrow.net> <20150220202216.GS1012@cilantro.c4inet.net> <841D1B24-2A44-4936-9079-D1F2588BE7A6@danrl.de> <222FCDA0232D441F922D87DE0A1F0024@Saeed> <7E14378381A64697AF4E9DE754E6A4BE@Saeed> Message-ID: <54FDCAFC.7020005@v4escrow.net> Hi everyone, I have thinking at what to answer regarding the comments on this proposal. Firstly, the /22 from the last /8 policy proposal aimed to create a method for anyone to receive at least a few (1024) IPv4 addresses by becoming a member of the RIPE NCC. Even then, the proposers had noted that anyone can open multiple LIRs and receive from the RIPE NCC more than 1024 IP addresses and asked the RIPE NCC to be vigilant. [1] What happens now is not in the spirit of that policy proposal as the /22 from the RIPE NCC does not have the two years holding period so a few found a way to make a business using this loophole. This policy proposal is just trying to add the same holding period for a transfer of the /22 as it is already for the rest of the allocations made by the RIPE NCC. While I do agree that if the RIPE NCC free pool would be depleted, the market would takeover and normalize the price, the community has decided to have IPv4 addresses available for anyone that wants to become a member of the RIPE NCC and therefore request & receive a /22. I think that a separate proposal could tackle this issue, there were some discussions last year (if I remember correctly) and some members of this community suggested the increasing the limit from /22 to /21. That may deplete the free pool faster, but it will still slowly bleed out in a few years. If we do not agree that this policy proposal is fair and needed, I predict that we will see more and more companies opening LIRs just to make use of this loophole and make a profit from selling one or more /22s from the last /8. Actually, this policy proposal may have already harmed the free pool because if it does not get approved, more people have found out of the loophole and nothing will stop them from using it, they will have the endorsement of the community to just go ahead and open multiple LIRs. I would not be surprised to see a very large ISP or (content) hosting company setting up 1.000 LIRs to get 1million IP addresses.. and if they setup 1024 LIRs in the same 'day' they may even get a /12 as a contiguous block. In that case, would you find it fair that if someone wants to use a loophole (1024 times) they can get a /12 from the RIPE NCC while others need to use the market? Considering these, Martin (and whoever else does not like this policy proposal), please let me know if you oppose to to this proposal as it is written and if you have any suggestion on what would be acceptable. regards, Elvis [1] https://www.ripe.net/ripe/policies/proposals/2010-02 "Some organisations may set up multiple LIR registrations in an effort to get more address space than proposed. The RIPE NCC must be vigilant regarding these, but the authors accept that it is hard to ensure complete compliance." -- Elvis Daniel Velea Chief Executive Officer Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +31 (0) 61458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 11971 bytes Desc: not available URL: From doi at bva.bund.de Tue Mar 10 09:13:49 2015 From: doi at bva.bund.de (DOI (BIT I 5)) Date: Tue, 10 Mar 2015 08:13:49 +0000 Subject: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations) In-Reply-To: <54FDCAFC.7020005@v4escrow.net> References: <5EC17651-C59E-4929-98C3-8D5A91D89720@nosignal.org> <1424370405.4066.10.camel@gmail.com> <54E74038.10204@v4escrow.net> <1424453215.5143.463.camel@galileo.millnert.se> <54E78E65.2030306@v4escrow.net> <20150220202216.GS1012@cilantro.c4inet.net> <841D1B24-2A44-4936-9079-D1F2588BE7A6@danrl.de> <222FCDA0232D441F922D87DE0A1F0024@Saeed> <7E14378381A64697AF4E9DE754E6A4BE@Saeed> <54FDCAFC.7020005@v4escrow.net> Message-ID: Hi Elvis, I agree with your proposal. I'm interested in the fact: Are there such "loophole" cases right now or is it a theoretical problem, that could be happen if 2015-01 would not be accepted? Regards, Carsten Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Elvis Daniel Velea Gesendet: Montag, 9. M?rz 2015 17:32 An: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations) Hi everyone, I have thinking at what to answer regarding the comments on this proposal. Firstly, the /22 from the last /8 policy proposal aimed to create a method for anyone to receive at least a few (1024) IPv4 addresses by becoming a member of the RIPE NCC. Even then, the proposers had noted that anyone can open multiple LIRs and receive from the RIPE NCC more than 1024 IP addresses and asked the RIPE NCC to be vigilant. [1] What happens now is not in the spirit of that policy proposal as the /22 from the RIPE NCC does not have the two years holding period so a few found a way to make a business using this loophole. This policy proposal is just trying to add the same holding period for a transfer of the /22 as it is already for the rest of the allocations made by the RIPE NCC. While I do agree that if the RIPE NCC free pool would be depleted, the market would takeover and normalize the price, the community has decided to have IPv4 addresses available for anyone that wants to become a member of the RIPE NCC and therefore request & receive a /22. I think that a separate proposal could tackle this issue, there were some discussions last year (if I remember correctly) and some members of this community suggested the increasing the limit from /22 to /21. That may deplete the free pool faster, but it will still slowly bleed out in a few years. If we do not agree that this policy proposal is fair and needed, I predict that we will see more and more companies opening LIRs just to make use of this loophole and make a profit from selling one or more /22s from the last /8. Actually, this policy proposal may have already harmed the free pool because if it does not get approved, more people have found out of the loophole and nothing will stop them from using it, they will have the endorsement of the community to just go ahead and open multiple LIRs. I would not be surprised to see a very large ISP or (content) hosting company setting up 1.000 LIRs to get 1million IP addresses.. and if they setup 1024 LIRs in the same 'day' they may even get a /12 as a contiguous block. In that case, would you find it fair that if someone wants to use a loophole (1024 times) they can get a /12 from the RIPE NCC while others need to use the market? Considering these, Martin (and whoever else does not like this policy proposal), please let me know if you oppose to to this proposal as it is written and if you have any suggestion on what would be acceptable. regards, Elvis [1] https://www.ripe.net/ripe/policies/proposals/2010-02 "Some organisations may set up multiple LIR registrations in an effort to get more address space than proposed. The RIPE NCC must be vigilant regarding these, but the authors accept that it is hard to ensure complete compliance." -- [cid:image001.png at 01D05B11.E2664830] Elvis Daniel Velea Chief Executive Officer Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +31 (0) 61458 1914 Recognised IPv4 Broker/Facilitator in: [cid:image002.png at 01D05B11.E2664830][cid:image003.png at 01D05B11.E2664830] This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5043 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 193 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 11971 bytes Desc: image003.png URL: From elvis at v4escrow.net Tue Mar 10 13:20:02 2015 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Tue, 10 Mar 2015 13:20:02 +0100 Subject: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations) In-Reply-To: References: <5EC17651-C59E-4929-98C3-8D5A91D89720@nosignal.org> <1424370405.4066.10.camel@gmail.com> <54E74038.10204@v4escrow.net> <1424453215.5143.463.camel@galileo.millnert.se> <54E78E65.2030306@v4escrow.net> <20150220202216.GS1012@cilantro.c4inet.net> <841D1B24-2A44-4936-9079-D1F2588BE7A6@danrl.de> <222FCDA0232D441F922D87DE0A1F0024@Saeed> <7E14378381A64697AF4E9DE754E6A4BE@Saeed> <54FDCAFC.7020005@v4escrow.net> Message-ID: <54FEE172.205@v4escrow.net> Hi Carsten, not only that the loophole exists, but the RIPE NCC has even pointed it out in an RIPE Labs article (and several previous RIPE Meetings): https://labs.ripe.net/Members/wilhelm/ripe-ncc-membership-statistics-2014 I think that the more we talk about it, the more this loophole will be (ab)used. The part that was just theoretical was estimating how long it will take a company to decide that instead of going to the market, they could actually go to the RIPE NCC and get a /16 or maybe a /12 at ?2.3 - ?3.4 per IP (depending in which quarter you decide to do it). - this policy proposal will still not fix this issue, will just raise even more awareness.. this policy proposal is just trying to patch the transfer policy. we still need to discuss whether we want to touch the mergers and acquisitions process. regards, elvis On 10/03/15 09:13, DOI (BIT I 5) wrote: > > Hi Elvis, > > I agree with your proposal. I?m interested in the fact: Are there such > ?loophole? cases right now or is it a theoretical problem, that could > be happen if 2015-01 would not be accepted? > > Regards, > > Carsten > > *Von:*address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] > *Im Auftrag von *Elvis Daniel Velea > *Gese**ndet:*Montag, 9. M?rz 2015 17:32 > *An:* address-policy-wg at ripe.net > *Betreff:* Re: [address-policy-wg] 2015-01 New Policy Proposal > (Alignment ofTransfer Requirements for IPv4 Allocations) > > Hi everyone, > > I have thinking at what to answer regarding the comments on this proposal. > > Firstly, the /22 from the last /8 policy proposal aimed to create a > method for anyone to receive at least a few (1024) IPv4 addresses by > becoming a member of the RIPE NCC. > Even then, the proposers had noted that anyone can open multiple LIRs > and receive from the RIPE NCC more than 1024 IP addresses and asked > the RIPE NCC to be vigilant. [1] > > What happens now is not in the spirit of that policy proposal as the > /22 from the RIPE NCC does not have the two years holding period so a > few found a way to make a business using this loophole. > This policy proposal is just trying to add the same holding period for > a transfer of the /22 as it is already for the rest of the allocations > made by the RIPE NCC. > > > While I do agree that if the RIPE NCC free pool would be depleted, the > market would takeover and normalize the price, the community has > decided to have IPv4 addresses available for anyone that > wants to become a member of the RIPE NCC and therefore request & > receive a /22. > I think that a separate proposal could tackle this issue, there were > some discussions last year (if I remember correctly) and some members > of this community suggested the increasing the limit from /22 to /21. > That may deplete the free pool faster, but it will still slowly bleed > out in a few years. > > If we do not agree that this policy proposal is fair and needed, I > predict that we will see more and more companies opening LIRs just to > make use of this loophole and make a profit from selling one or more > /22s from the last /8. > Actually, this policy proposal may have already harmed the free pool > because if it does not get approved, more people have found out of the > loophole and nothing will stop them from using it, they will have the > endorsement of the community to just go ahead and open multiple LIRs. > I would not be surprised to see a very large ISP or (content) hosting > company setting up 1.000 LIRs to get 1million IP addresses.. and if > they setup 1024 LIRs in the same 'day' they may even get a /12 as a > contiguous block. > In that case, would you find it fair that if someone wants to use a > loophole (1024 times) they can get a /12 from the RIPE NCC while > others need to use the market? > > Considering these, Martin (and whoever else does not like this policy > proposal), please let me know if you oppose to to this proposal as it > is written and if you have any suggestion on what would be acceptable. > > regards, > Elvis > > > [1] https://www.ripe.net/ripe/policies/proposals/2010-02 > "Some organisations may set up multiple LIR registrations in an effort > to get more address space than proposed. The RIPE NCC must be vigilant > regarding these, but the authors accept that it is hard to ensure > complete compliance." > > -- > > > > > > > Elvis Daniel Velea > > > Chief Executive Officer > > Email:elvis at V4Escrow.net > US Phone: +1 (702) 475 5914 > EU Phone: +31 (0) 61458 1914 > > Recognised IPv4 Broker/Facilitator in: > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you have > received this email in error, please notify the sender immediately and > delete the original.Any other use of this email is strictly prohibited. > -- Elvis Daniel Velea Chief Executive Officer Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +31 (0) 61458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 193 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 11971 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From gert at space.net Tue Mar 10 15:16:49 2015 From: gert at space.net (Gert Doering) Date: Tue, 10 Mar 2015 15:16:49 +0100 Subject: [address-policy-wg] 2014-07, 2014-08, 2014-10, 2014-11 Proposals Accepted (Language Clarification Proposals) In-Reply-To: References: Message-ID: <20150310141649.GA62164@Space.Net> Dear AP WG, On Fri, Feb 06, 2015 at 10:27:19AM +0100, Marco Schmidt wrote: > The proposals described in > > - 2014-07, Language Clarification in "IPv4 Address Allocation and Assignment > Policies for the RIPE NCC Service Region" > - 2014-08, Language Clarification in "Contractual Requirements for Provider > Independent Resource Holders in the RIPE NCC Service Region" > - 2014-10, Language Clarification in "IPv6 Addresses for Internet Root Servers > In The RIPE Region" > - 2014-11, Language Clarification for "Allocating/Assigning Resources to the > RIPE NCC", > > are now in the Concluding Phase. The "last call" phase has now ended. The only comment in the Last Call phase was one statement of support, which is nice, but not actually needed - in Last Call "no comments at all" is good enough. Thus, the chairs hereby declare consensus on 2014-07, 2014-08, 2014-10 and 2014-11 (the four remaining Language Clarification proposals). If you disagree with this decision please contact the working group chairs (preferably on this public mailing list and otherwise by sending mail to apwg-chairs at ripe.net). Should that not resolve the problem then you can appeal to the WG chairs collective (as per section 4 of ripe-614). Marco will send the formal announcement from the NCC soon. regards, Gert Doering and Sander Steffann -- 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From gert at space.net Tue Mar 10 15:20:36 2015 From: gert at space.net (Gert Doering) Date: Tue, 10 Mar 2015 15:20:36 +0100 Subject: [address-policy-wg] 2014-13 Proposal Accepted (Allow AS Number Transfers) In-Reply-To: References: Message-ID: <20150310142036.GA62751@Space.Net> Dear Address Policy WG, On Mon, Feb 09, 2015 at 02:06:08PM +0100, Marco Schmidt wrote: > The proposal described in 2014-13, "Allow AS Number Transfers", is now in its > Concluding Phase. [..] > Please e-mail any final comments about this proposal to address-policy-wg at ripe.net > before 10 March 2015. The "last call" phase has now ended. Two comments were received (confirmation of the chairs' assessment of consensus and a thank-you from the proposer), but no objections. Thus, the chairs hereby declare consensus on 2014-13. If you disagree with this decision please contact the working group chairs (preferably on this public mailing list and otherwise by sending mail to apwg-chairs at ripe.net). Should that not resolve the problem then you can appeal to the WG chairs collective (as per section 4 of ripe-614). Marco will send the formal announcement from the NCC soon. regards, Gert Doering and Sander Steffann -- 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nick at inex.ie Tue Mar 10 16:36:41 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 10 Mar 2015 15:36:41 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? Message-ID: <54FF0F89.4070606@inex.ie> thanks to Tore for pointing this out, but page 6 of: > http://www.apnic.net/__data/assets/pdf_file/0011/80786/apnic-ec-minutes-20141126.pdf contains the following: > 21. Inter-RIR transfer policy discussion > > The EC considered the Inter-RIR transfer policy discussions (attached). > > The EC unanimously resolved to place a temporary moratorium on inter RIR > transfer with RIPE NCC, pending discussions and confirmation with APNIC, > ARIN and RIPE communities that such transfers will not change APNIC?s > status as sharing reciprocal, compatible, needs-based policy with ARIN. > > Motion proposed by Paul Wilson, seconded by Akinori Maemura. Could someone from APNIC, ARIN or both explain the background to this decision? I haven't seen any discussions in the RIPE community about this, and without knowing the background it seems peculiar that APNIC feels it necessary to consult ARIN about APNIC->RIPE NCC resource transfers. Nick From marty at akamai.com Tue Mar 10 16:54:14 2015 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 10 Mar 2015 15:54:14 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <54FF0F89.4070606@inex.ie> References: <54FF0F89.4070606@inex.ie> Message-ID: <1A6882A2-4571-49A3-A58F-127654790625@akamai.com> On Mar 10, 2015, at 11:36 AM, Nick Hilliard wrote: > thanks to Tore for pointing this out, but page 6 of: > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apnic.net_-5F-5Fdata_assets_pdf-5Ffile_0011_80786_apnic-2Dec-2Dminutes-2D20141126.pdf&d=AwIFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=XDN_BIPGnpb6V0w5M9FADw&m=qREGu1kpzJCBMNBo8Rla_1KJXMuy8S5K-jNZnq6vnr0&s=9FMPKbELj5vBOjS9qlYVT1DANtfXa4ne68ofKVS_fD4&e= > > contains the following: > >> 21. Inter-RIR transfer policy discussion >> >> The EC considered the Inter-RIR transfer policy discussions (attached). >> >> The EC unanimously resolved to place a temporary moratorium on inter RIR >> transfer with RIPE NCC, pending discussions and confirmation with APNIC, >> ARIN and RIPE communities that such transfers will not change APNIC?s >> status as sharing reciprocal, compatible, needs-based policy with ARIN. >> >> Motion proposed by Paul Wilson, seconded by Akinori Maemura. > > Could someone from APNIC, ARIN or both explain the background to this > decision? I haven't seen any discussions in the RIPE community about this, > and without knowing the background it seems peculiar that APNIC feels it > necessary to consult ARIN about APNIC->RIPE NCC resource transfers. > > Nick > > +1, does this also include transfers to CNNIC? The ARIN->RIPE direction seems like an odd one to be concerned about. Best, -M< -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From apwg at c4inet.net Tue Mar 10 16:59:14 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 10 Mar 2015 15:59:14 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <54FF0F89.4070606@inex.ie> References: <54FF0F89.4070606@inex.ie> Message-ID: <20150310155914.GT1012@cilantro.c4inet.net> On Tue, Mar 10, 2015 at 03:36:41PM +0000, Nick Hilliard wrote: >and without knowing the background it seems peculiar that APNIC feels it >necessary to consult ARIN about APNIC->RIPE NCC resource transfers. I reckon APNIC is afraid they will not get transfers from ARIN if there is a possibility that those may subsequently be transferred to RIPE. rgds, Sascha Luck From andrea at ripe.net Tue Mar 10 17:05:51 2015 From: andrea at ripe.net (Andrea Cima) Date: Tue, 10 Mar 2015 17:05:51 +0100 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <54FF0F89.4070606@inex.ie> References: <54FF0F89.4070606@inex.ie> Message-ID: <54FF165F.1090108@ripe.net> Hi Nick, On 10/3/15 16:36, Nick Hilliard wrote: > thanks to Tore for pointing this out, but page 6 of: > >> http://www.apnic.net/__data/assets/pdf_file/0011/80786/apnic-ec-minutes-20141126.pdf > > contains the following: > >> 21. Inter-RIR transfer policy discussion >> >> The EC considered the Inter-RIR transfer policy discussions (attached). >> >> The EC unanimously resolved to place a temporary moratorium on inter RIR >> transfer with RIPE NCC, pending discussions and confirmation with APNIC, >> ARIN and RIPE communities that such transfers will not change APNIC?s >> status as sharing reciprocal, compatible, needs-based policy with ARIN. >> >> Motion proposed by Paul Wilson, seconded by Akinori Maemura. > > Could someone from APNIC, ARIN or both explain the background to this > decision? While I cannot answer on behalf of the other RIRs, we have given an update about the inter-RIR transfer policy proposal last week, during APNIC 39. I hope the video and transcripts will provide you with the clarification requested (please see session Policy SIG-3) https://2015.apricot.net/program#agenda/day10 Best regards, Andrea Cima RIPE NCC > I haven't seen any discussions in the RIPE community about this, > and without knowing the background it seems peculiar that APNIC feels it > necessary to consult ARIN about APNIC->RIPE NCC resource transfers. > > Nick > > From gert at space.net Tue Mar 10 17:12:28 2015 From: gert at space.net (Gert Doering) Date: Tue, 10 Mar 2015 17:12:28 +0100 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <54FF0F89.4070606@inex.ie> References: <54FF0F89.4070606@inex.ie> Message-ID: <20150310161228.GK54385@Space.Net> Hi Nick, Tore, thanks indeed for pointing that out. On Tue, Mar 10, 2015 at 03:36:41PM +0000, Nick Hilliard wrote: > > The EC unanimously resolved to place a temporary moratorium on inter RIR > > transfer with RIPE NCC, pending discussions and confirmation with APNIC, > > ARIN and RIPE communities that such transfers will not change APNIC???s > > status as sharing reciprocal, compatible, needs-based policy with ARIN. > > > > Motion proposed by Paul Wilson, seconded by Akinori Maemura. > > Could someone from APNIC, ARIN or both explain the background to this > decision? I haven't seen any discussions in the RIPE community about this, > and without knowing the background it seems peculiar that APNIC feels it > necessary to consult ARIN about APNIC->RIPE NCC resource transfers. This is interesting on so many aspects, like - put a moratorium on what? There are no transfers APNIC->RIPE NCC yet, because we do not have a policy to receive them (it is in last call, true, but not policy yet) - even if we had a policy, we have clear statements that the way we have phrased our text is compatible with ARIN's requirement for needs-based on the receiving side - so very curious indeed... Gert Doering -- puzzled net.citizen -- 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ebais at a2b-internet.com Tue Mar 10 17:29:59 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 10 Mar 2015 17:29:59 +0100 Subject: [address-policy-wg] 2014-13 Proposal Accepted (Allow AS Number Transfers) In-Reply-To: <20150310142036.GA62751@Space.Net> References: <20150310142036.GA62751@Space.Net> Message-ID: <007001d05b4f$79ab2e30$6d018a90$@a2b-internet.com> Hi Gert, > Thus, the chairs hereby declare consensus on 2014-13. Thanks for the assistance on the list and the announcement. Looking forward to the RIPE NCC implementation in the next months. I hope that I can propose the draft text for the new transfer document text before the next RIPE meeting in Amsterdam. Regards, Erik Bais From gert at space.net Tue Mar 10 17:35:51 2015 From: gert at space.net (Gert Doering) Date: Tue, 10 Mar 2015 17:35:51 +0100 Subject: [address-policy-wg] 2014-13 Proposal Accepted (Allow AS Number Transfers) In-Reply-To: <007001d05b4f$79ab2e30$6d018a90$@a2b-internet.com> References: <20150310142036.GA62751@Space.Net> <007001d05b4f$79ab2e30$6d018a90$@a2b-internet.com> Message-ID: <20150310163551.GM54385@Space.Net> Hi Erik, On Tue, Mar 10, 2015 at 05:29:59PM +0100, Erik Bais wrote: > I hope that I can propose the draft text for the new transfer document text > before the next RIPE meeting in Amsterdam. Thanks. This would indeed be great to have, preferrably a week or so before the meeting on the list - so we can have a somewhat educated discussion in Amsterdam :-) Gert Doering -- 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nick at inex.ie Tue Mar 10 18:03:03 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 10 Mar 2015 17:03:03 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <54FF165F.1090108@ripe.net> References: <54FF0F89.4070606@inex.ie> <54FF165F.1090108@ripe.net> Message-ID: <54FF23C7.4020403@inex.ie> Hi Andrea, On 10/03/2015 16:05, Andrea Cima wrote: > While I cannot answer on behalf of the other RIRs, we have given an > update about the inter-RIR transfer policy proposal last week, during > APNIC 39. I hope the video and transcripts will provide you with the > clarification requested (please see session Policy SIG-3) thanks for the reference. The context is located at pages 35-49 of: https://conference.apnic.net/data/39/5-March-Policy-SIG-3.txt and at: https://www.youtube.com/watch?v=2iKK_8iJU6E#t=1h09m11s Nick From tore at fud.no Wed Mar 11 10:05:08 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 11 Mar 2015 10:05:08 +0100 Subject: [address-policy-wg] 2014-13 Proposal Accepted (Allow AS Number Transfers) In-Reply-To: <007001d05b4f$79ab2e30$6d018a90$@a2b-internet.com> References: <20150310142036.GA62751@Space.Net> <007001d05b4f$79ab2e30$6d018a90$@a2b-internet.com> Message-ID: <20150311100508.4409c35a@echo.ms.redpill-linpro.com> * "Erik Bais" > I hope that I can propose the draft text for the new transfer > document text before the next RIPE meeting in Amsterdam. I look forward to seeing it (even though I unfortunately won't make it to RIPE70). Just in case you're looking for inspiration, I thought I'd point out that I found APNIC's old transfer policy very clean and readable: http://www.apnic.net/policy/drafts/draft-transfer-policy-20140110 Tore From tore at fud.no Wed Mar 11 10:38:32 2015 From: tore at fud.no (Tore Anderson) Date: Wed, 11 Mar 2015 10:38:32 +0100 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <20150310155914.GT1012@cilantro.c4inet.net> References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> Message-ID: <20150311103832.67e47754@echo.ms.redpill-linpro.com> * "Sascha Luck [ml]" > On Tue, Mar 10, 2015 at 03:36:41PM +0000, Nick Hilliard wrote: > >and without knowing the background it seems peculiar that APNIC > >feels it necessary to consult ARIN about APNIC->RIPE NCC resource > >transfers. > > I reckon APNIC is afraid they will not get transfers from ARIN if > there is a possibility that those may subsequently be transferred > to RIPE. Indeed, that's how I understood Paul Wilson's mic comments after Andrea's APRICOT 2015 presentation, i.e., even though ARIN and APNIC transfer policies are compatible to begin with, the worry is that if transfers between the APNIC and RIPE regions commence without demonstrated need, than this fact would somehow ?infect? the APNIC policy such that ARIN would no longer consider it to be sufficiently ?needs based? and thus incompatible (even though the APNIC policy text would not change at all). As I understand it, transfers between the APNIC and RIPE regions without demonstrated need is exactly what would happen with the current APNIC policy + 2015-05, since current APNIC policy doesn't ?require the receiving region to have needs-based policies?. However, the transcript quotes Andrea as saying ?Both RIRs that have an inter-RIR transfer policy in place, meaning ARIN and APNIC, confirmed that their policy requires a needs base in order to do inter-RIR transfers?. After reading APNIC's policy document, I do not think this is accurate. I wonder how this understanding of APNIC's inter-RIR transfer policy requiring needs basis came to be. In any case, ARIN staff has confirmed on multiple occasions now that 1) 2014-05 is compatible with ARIN's transfer policy, and even if it wasn't 2) that any policy adopted by a third-party RIR community cannot alter the compatibility state between the ARIN and APNIC policies. Thus it seems very clear that there is absolutely no cause for concern; after the passage of 2014-05, all three RIRs in question will be compatible with the other two. I guess that the APNIC EC meeting might have happened before these assurances from ARIN staff was made public, and that would help explain why they decided to temporarily override their own community policies. Now that it is known that their worries were unfounded, I'd expect the them to lift the freeze at the next EC meeting. Tore From nick at inex.ie Wed Mar 11 11:22:46 2015 From: nick at inex.ie (Nick Hilliard) Date: Wed, 11 Mar 2015 10:22:46 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <20150311103832.67e47754@echo.ms.redpill-linpro.com> References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> <20150311103832.67e47754@echo.ms.redpill-linpro.com> Message-ID: <55001776.6070002@inex.ie> On 11/03/2015 09:38, Tore Anderson wrote: > Indeed, that's how I understood Paul Wilson's mic comments after > Andrea's APRICOT 2015 presentation, i.e., even though ARIN and APNIC > transfer policies are compatible to begin with, the worry is that if > transfers between the APNIC and RIPE regions commence without > demonstrated need, than this fact would somehow ?infect? the APNIC > policy such that ARIN would no longer consider it to be sufficiently > ?needs based? and thus incompatible (even though the APNIC policy text > would not change at all). that is also my understanding - this should be fixed with the current transfer proposal. Although I found the statement from Einar Bohlin (policy analyst at ARIN) disturbing: > ARIN does not have policy regarding the relationship between RIPE and > APNIC. So we don't have -- there is no policy text in our policy manual > regarding that relationship. There could be in the future but there is > no such thing at this time. The RIPE policy operates on the principal that once address space is transferred in or out of a RIR, that for the duration of the transfer (whether temporary or permanent), the receiving RIR policy applies and that the sending RIR has no input on the resources. Unfortunately, this is not respected in the ARIN inter-rir transfer policy: https://www.arin.net/policy/nrpm.html#eight4 which includes the text: "Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received." In other words, multinational organisations headquartered in the ARIN region who receive resources transferred to another RIR will be subject to ARIN policies. This is potentially a serious problem because transferring policy encumbrances is likely to cause policy problems in future, if RIR policy differences crop up. So the question is: can the RIPE NCC accept transfers from ARIN if the receiver organisation has signed the ARIN RSA for these resources? And if transfers are accepted within these terms and there's a conflict between RIPE NCC policy and ARIN policy, whose policies takes precedence? RIPE's or ARIN's? Nick From mschmidt at ripe.net Wed Mar 11 14:24:52 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 11 Mar 2015 14:24:52 +0100 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <55001776.6070002@inex.ie> References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> <20150311103832.67e47754@echo.ms.redpill-linpro.com> <55001776.6070002@inex.ie> Message-ID: <55004224.5050009@ripe.net> Hello Nick, On 11/03/15 11:22, Nick Hilliard wrote: > Unfortunately, this is not respected in the ARIN inter-rir transfer policy: > > https://www.arin.net/policy/nrpm.html#eight4 > > which includes the text: > > "Recipients within the ARIN region will be subject to current ARIN policies > and sign an RSA for the resources being received." > > In other words, multinational organisations headquartered in the ARIN > region who receive resources transferred to another RIR will be subject to > ARIN policies. > > This is potentially a serious problem because transferring policy > encumbrances is likely to cause policy problems in future, if RIR policy > differences crop up. > > So the question is: can the RIPE NCC accept transfers from ARIN if the > receiver organisation has signed the ARIN RSA for these resources? And if > transfers are accepted within these terms and there's a conflict between > RIPE NCC policy and ARIN policy, whose policies takes precedence? RIPE's > or ARIN's? The proposed RIPE Policy for Inter-RIR Transfers of Internet Resources includes the statement: "While the transfer is in process, during the time the internet number resources are registered in the RIPE NCC service region, then RIPE policies will apply." https://www.ripe.net/ripe/policies/proposals/2014-05 And the RIPE NCC impact analysis states: "For transfers to the RIPE NCC service region, the resources will only be registered in the RIPE Registry when the transfer is completed. It is the RIPE NCC?s understanding that resources being transferred are subject to the policies of an RIR as long their are registered in its registry. " ARIN has confirmed that the proposed policy text is compatible with its own inter-RIR transfer policy. No potential issues have been indicated. Further, the complete paragraph 8.4 of the ARIN Number Resource Policy Manual says: "Conditions on recipient of the transfer: - The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR. - Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received. - Recipients within the ARIN region must demonstrate the need for up to a 24-month supply of IPv4 address space. - The minimum transfer size is a /24." https://www.arin.net/policy/nrpm.html#eight4 Regards, Marco Schmidt Policy Development Officer RIPE NCC From nick at inex.ie Wed Mar 11 14:40:44 2015 From: nick at inex.ie (Nick Hilliard) Date: Wed, 11 Mar 2015 13:40:44 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <55004224.5050009@ripe.net> References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> <20150311103832.67e47754@echo.ms.redpill-linpro.com> <55001776.6070002@inex.ie> <55004224.5050009@ripe.net> Message-ID: <550045DC.8090604@inex.ie> Hi Marco, There are two fundamental problems here, one operational- and one policy-related. On 11/03/2015 13:24, Marco Schmidt wrote: [...] > ARIN has confirmed that the proposed policy text is compatible with its own > inter-RIR transfer policy. No potential issues have been indicated. 1. If there is a future incompatibility between RIPE policy and ARIN policy which concerns resources transferred under this category: > - Recipients within the ARIN region will be subject to current ARIN > policies and sign an RSA for the resources being received. ... whose policy applies? RIPE's or ARIN's? 2. As a separate but related issue, I am struggling to understand why the RIPE community should accept that that if ARIN resources are transferred to RIPE, that ARIN will retain a policy encumbrance on those resources in some situations. Nick From sandrabrown at ipv4marketgroup.com Wed Mar 11 16:01:39 2015 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Wed, 11 Mar 2015 08:01:39 -0700 Subject: [address-policy-wg] =?utf-8?q?APNIC_temporarily_freezing_v4_trans?= =?utf-8?q?fers_to_RIPE_NCC=3F?= Message-ID: <20150311080139.ec289651d84890fcbef5f195936e1217.f29caae5fe.wbe@email17.secureserver.net> Hi Andrea, At APNIC39 in Fukuoka, I spoke with Adam Gosling of APNIC. He suggested that the APNIC EC would wait for an interpretation and implementation of the new RIPE inter-RIR policy before making a decision. But, as reflected in the discussion already made, he did feel that an APNIC to RIPE transfer would not be subjected to needs justification because he (and APNIC in general) do not interpret APNIC policy as requiring needs justification if the receiving RIR does not. Two comments on this: Why would APNIC to RIPE not require needs justification when APNIC to APNIC does? Secondly, there are so few IPs within APNIC, how often will there ever be IPs transferred from APNIC to RIPE region under the inter-RIR policy? I would not think this is a big transfer path. The reality is that the huge supply of IPs for transfer to RIPE is in ARIN region and this supply is the target of the new RIPE inter-RIR policy. If APNIC never allows transfer to RIPE region, this would be ok from the perspective of supply to RIPE region. In fact this would be preferable to APNIC allowing transfers with no needs justification, such that ARIN then flipped its position to block transfers to APNIC because they could subsequently to transferred to RIPE. A more tangible flaw is that APNIC has no time delay on re-transfers. While ARIN would not allow a transferred block to be re-transferred for 12 months and RIPE would not allow a transferred block to be re-transferred for 24 months, APNIC has no limitation. But this problem exists today for IPs transferred to APNIC; they can immediately be re-transferred within APNIC. No change just because they could now be transferred to RIPE region, so I can't see ARIN complaining about this now. ARIN being concerned with APNIC allowing transfers to APNIC being subsequently transferred to RIPE should not influence the implementation of direct transfers from ARIN to RIPE using the new needs justification criteria of 50% use over 5 years that ARIN had agreed was compatible with its policy. Based on this analysis, I don't see the initial buy-in or non-buy-in by APNIC as a concern. It is ARIN as a supply that is needed. Sandra Brown Message: 3 Date: Tue, 10 Mar 2015 17:03:03 +0000 From: Nick Hilliard To: Andrea Cima , Address Policy Working Group Subject: Re: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? Message-ID: <54FF23C7.4020403 at inex.ie> Content-Type: text/plain; charset=utf-8 Hi Andrea, On 10/03/2015 16:05, Andrea Cima wrote: > While I cannot answer on behalf of the other RIRs, we have given an > update about the inter-RIR transfer policy proposal last week, during > APNIC 39. I hope the video and transcripts will provide you with the > clarification requested (please see session Policy SIG-3) thanks for the reference. The context is located at pages 35-49 of: https://conference.apnic.net/data/39/5-March-Policy-SIG-3.txt and at: https://www.youtube.com/watch?v=2iKK_8iJU6E#t=1h09m11s Nick From mschmidt at ripe.net Wed Mar 11 16:54:09 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 11 Mar 2015 16:54:09 +0100 Subject: [address-policy-wg] 2014-07, 2014-08, 2014-10, 2014-11 Proposals Accepted (Language Clarification Proposals) Message-ID: Dear colleagues, Consensus has been reached, and the proposals for changes to the following RIPE Documents have been accepted by the RIPE community: ripe-632, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" ripe-452, "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" ripe-233, "IPv6 Addresses for Internet Root Servers In The RIPE Region" ripe-476, "Allocating/Assigning Resources to the RIPE NCC" These policy changes replace the term "should" with "must" in cases where the previous wording created unwanted ambiguity in policy documents. You can find the full proposals at: http://www.ripe.net/ripe/policies/proposals/2014-07 http://www.ripe.net/ripe/policies/proposals/2014-08 http://www.ripe.net/ripe/policies/proposals/2014-10 http://www.ripe.net/ripe/policies/proposals/2014-11 The new RIPE Documents are called ripe-634, ripe-635, ripe-636 and ripe-637 and are available at: https://www.ripe.net/ripe/docs/ripe-634 https://www.ripe.net/ripe/docs/ripe-637 https://www.ripe.net/ripe/docs/ripe-636 https://www.ripe.net/ripe/docs/ripe-635 Note: the order of the original documents, proposals and new RIPE Documents in the lists above all correspond to one another. These proposals are implemented with immediate effect, as the RIPE NCC's procedures, tools and documentation are already in line with the policy understanding that these updates reflect. Thank you to everyone who provided their input. Regards, Marco Schmidt Policy Development Officer RIPE NCC From scottleibrand at gmail.com Wed Mar 11 20:28:24 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 11 Mar 2015 12:28:24 -0700 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <55001776.6070002@inex.ie> References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> <20150311103832.67e47754@echo.ms.redpill-linpro.com> <55001776.6070002@inex.ie> Message-ID: On Wed, Mar 11, 2015 at 3:22 AM, Nick Hilliard wrote: > On 11/03/2015 09:38, Tore Anderson wrote: > > Indeed, that's how I understood Paul Wilson's mic comments after > > Andrea's APRICOT 2015 presentation, i.e., even though ARIN and APNIC > > transfer policies are compatible to begin with, the worry is that if > > transfers between the APNIC and RIPE regions commence without > > demonstrated need, than this fact would somehow ?infect? the APNIC > > policy such that ARIN would no longer consider it to be sufficiently > > ?needs based? and thus incompatible (even though the APNIC policy text > > would not change at all). > > that is also my understanding - this should be fixed with the current > transfer proposal. Although I found the statement from Einar Bohlin > (policy analyst at ARIN) disturbing: > > > ARIN does not have policy regarding the relationship between RIPE and > > APNIC. So we don't have -- there is no policy text in our policy manual > > regarding that relationship. There could be in the future but there is > > no such thing at this time. > > The RIPE policy operates on the principal that once address space is > transferred in or out of a RIR, that for the duration of the transfer > (whether temporary or permanent), the receiving RIR policy applies and that > the sending RIR has no input on the resources. > > Unfortunately, this is not respected in the ARIN inter-rir transfer policy: > > https://www.arin.net/policy/nrpm.html#eight4 > > which includes the text: > > "Recipients within the ARIN region will be subject to current ARIN policies > and sign an RSA for the resources being received." > > In other words, multinational organisations headquartered in the ARIN > region who receive resources transferred to another RIR will be subject to > ARIN policies. > That was not the intent of the policy language as drafted. Rather, than clause was meant to apply to 8.4 inter-RIR transfers inbound to the ARIN region from a source outside the ARIN region. So if someone in the RIPE region decides for some reason to transfer resources to someone in the ARIN region, and the addresses end up registered in the ARIN database, then the recipient must sign an RSA and will be subject to current ARIN policies. This was *not* intended to apply to a transfer from the ARIN region to an organization in the RIPE region, where the addresses will end up registered in the RIPE NCC database. So it shouldn't matter whether the recipient also has a presence in the ARIN region, or has an ARIN account. The actual recipient should be considered to be in the RIPE region (not the ARIN region) if the addresses are going to end up registered in the RIPE NCC database. ARIN staff can comment on their interpretation of the language, but hopefull it matches our original intent as summarized above. -Scott (speaking for myself, as someone involved in passing the ARIN draft policy that became NRPM 8.4) > > This is potentially a serious problem because transferring policy > encumbrances is likely to cause policy problems in future, if RIR policy > differences crop up. > > So the question is: can the RIPE NCC accept transfers from ARIN if the > receiver organisation has signed the ARIN RSA for these resources? And if > transfers are accepted within these terms and there's a conflict between > RIPE NCC policy and ARIN policy, whose policies takes precedence? RIPE's > or ARIN's? > > Nick > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Wed Mar 11 22:08:24 2015 From: nick at inex.ie (Nick Hilliard) Date: Wed, 11 Mar 2015 21:08:24 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> <20150311103832.67e47754@echo.ms.redpill-linpro.com> <55001776.6070002@inex.ie> Message-ID: <5500AEC8.1080006@inex.ie> Hi Scott, On 11/03/2015 19:28, Scott Leibrand wrote: > That was not the intent of the policy language as drafted. Rather, than > clause was meant to apply to 8.4 inter-RIR transfers inbound to the ARIN > region from a source outside the ARIN region. So if someone in the RIPE > region decides for some reason to transfer resources to someone in the ARIN > region, and the addresses end up registered in the ARIN database, then the > recipient must sign an RSA and will be subject to current ARIN policies. Right, ok. > This was *not* intended to apply to a transfer from the ARIN region to an > organization in the RIPE region, where the addresses will end up registered > in the RIPE NCC database. So it shouldn't matter whether the recipient > also has a presence in the ARIN region, or has an ARIN account. The actual > recipient should be considered to be in the RIPE region (not the ARIN > region) if the addresses are going to end up registered in the RIPE NCC > database. > > ARIN staff can comment on their interpretation of the language, but > hopefull it matches our original intent as summarized above. It would be helpful if we had a clear statement of interpretation from ARIN. As it stands, the language is ambiguous enough to allow misinterpretation of the original intent. Nick From jcurran at arin.net Thu Mar 12 13:45:41 2015 From: jcurran at arin.net (John Curran) Date: Thu, 12 Mar 2015 12:45:41 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <550045DC.8090604@inex.ie> References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> <20150311103832.67e47754@echo.ms.redpill-linpro.com> <55001776.6070002@inex.ie> <55004224.5050009@ripe.net> <550045DC.8090604@inex.ie> Message-ID: <89677BF6-271B-4B93-AEFE-C28905FFD292@arin.net> On Mar 11, 2015, at 9:40 AM, Nick Hilliard wrote: > > Hi Marco, > > There are two fundamental problems here, one operational- and one > policy-related. > > On 11/03/2015 13:24, Marco Schmidt wrote: > [...] >> ARIN has confirmed that the proposed policy text is compatible with its own >> inter-RIR transfer policy. No potential issues have been indicated. > > 1. If there is a future incompatibility between RIPE policy and ARIN policy > which concerns resources transferred under this category: > >> - Recipients within the ARIN region will be subject to current ARIN >> policies and sign an RSA for the resources being received. > > ... whose policy applies? RIPE's or ARIN's? Nick - ARIN's policies only apply to number resources that are contained within in the ARIN registry. To the best of my knowledge, number resources which have been transferred to another regional registry would be subject to that regional Internet registry's policies. ARIN's policies most certainly apply to all resources in the ARIN registry database, and could easily have implications for ability to transfer to another party in the ARIN region or party in another region, but once transferred to another region, I am unaware of any ARIN policy that would be applicable to transferred number resources. I hope this helps clarify matters. Thanks! /John John Curran President and CEO ARIN p.s. Note also that the ARIN Policy Development Process (PDP) allows for development of policies for administration of number resources "in the ARIN region" (and IANA-applicable global number resource policies per the ASO MOU); it is questionable if a policy proposal for administration of number resources in another regional registry would even be within the scope for the ARIN PDP... From jcurran at arin.net Thu Mar 12 14:17:07 2015 From: jcurran at arin.net (John Curran) Date: Thu, 12 Mar 2015 13:17:07 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <20150311103832.67e47754@echo.ms.redpill-linpro.com> References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> <20150311103832.67e47754@echo.ms.redpill-linpro.com> Message-ID: <11A73971-9897-478D-9E30-50B43B58B09E@arin.net> On Mar 11, 2015, at 5:38 AM, Tore Anderson wrote: > ... > In any case, ARIN staff has confirmed on multiple occasions now that 1) > 2014-05 is compatible with ARIN's transfer policy, and even if it > wasn't 2) that any policy adopted by a third-party RIR community cannot > alter the compatibility state between the ARIN and APNIC policies. That is correct, specifically, we assess the compatibility of an RIR's policies with our Inter-RIR transfer policy, and reassess if an RIR should change policies, i.e. RIPE adoption of policy text does not have any impact on ARIN transfers to/from APNIC. > Thus it seems very clear that there is absolutely no cause for concern; > after the passage of 2014-05, all three RIRs in question will be > compatible with the other two. I believe that to be correct, although nothing precludes the community in any region from deciding that outcome does not meet their needs, and changing inter-RIR transfer policy in their region. Such would be a rather surprising development, but I have long since given up attempting to predict the outcomes of the various RIR policy development processes... Thanks! /John John Curran President and CEO ARIN From nick at inex.ie Thu Mar 12 14:16:13 2015 From: nick at inex.ie (Nick Hilliard) Date: Thu, 12 Mar 2015 13:16:13 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <89677BF6-271B-4B93-AEFE-C28905FFD292@arin.net> References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> <20150311103832.67e47754@echo.ms.redpill-linpro.com> <55001776.6070002@inex.ie> <55004224.5050009@ripe.net> <550045DC.8090604@inex.ie> <89677BF6-271B-4B93-AEFE-C28905FFD292@arin.net> Message-ID: <5501919D.3020700@inex.ie> On 12/03/2015 12:45, John Curran wrote: > ARIN's policies only apply to number resources that are contained > within in the ARIN registry. To the best of my knowledge, number > resources which have been transferred to another regional registry > would be subject to that regional Internet registry's policies. > > ARIN's policies most certainly apply to all resources in the ARIN > registry database, and could easily have implications for ability > to transfer to another party in the ARIN region or party in another > region, but once transferred to another region, I am unaware of any > ARIN policy that would be applicable to transferred number resources. > > I hope this helps clarify matters. Hi John, It clarifies the intent, but "to the best of my knowledge" is an expression of opinion rather than a formal statement of policy. If we're going to have a working transfer mechanism, given that there is a level of ambiguity in the text in the ARIN transfer policy, it would be good if this could be clarified formally so that we can remove any doubt. Nick > Thanks! > /John > > John Curran > President and CEO > ARIN > > p.s. Note also that the ARIN Policy Development Process (PDP) allows for > development of policies for administration of number resources > "in the ARIN region" (and IANA-applicable global number resource > policies per the ASO MOU); it is questionable if a policy proposal > for administration of number resources in another regional registry > would even be within the scope for the ARIN PDP... > > > > > From jcurran at istaff.org Thu Mar 12 14:16:36 2015 From: jcurran at istaff.org (John Curran) Date: Thu, 12 Mar 2015 09:16:36 -0400 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <20150311103832.67e47754@echo.ms.redpill-linpro.com> References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> <20150311103832.67e47754@echo.ms.redpill-linpro.com> Message-ID: On Mar 11, 2015, at 5:38 AM, Tore Anderson wrote: > ... > In any case, ARIN staff has confirmed on multiple occasions now that 1) > 2014-05 is compatible with ARIN's transfer policy, and even if it > wasn't 2) that any policy adopted by a third-party RIR community cannot > alter the compatibility state between the ARIN and APNIC policies. That is correct, specifically, we assess the compatibility of an RIR's policies with our Inter-RIR transfer policy, and reassess if an RIR should change policies, i.e. RIPE adoption of policy text does not have any impact on ARIN transfers to/from APNIC. > Thus it seems very clear that there is absolutely no cause for concern; > after the passage of 2014-05, all three RIRs in question will be > compatible with the other two. I believe that to be correct, although nothing precludes the community in any region from deciding that outcome does not meet their needs, and changing inter-RIR transfer policy in their region. Such would be a rather surprising development, but I have long since given up attempting to predict the outcomes of the various RIR policy development processes... Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Thu Mar 12 14:50:38 2015 From: jcurran at arin.net (John Curran) Date: Thu, 12 Mar 2015 13:50:38 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: <5501919D.3020700@inex.ie> References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> <20150311103832.67e47754@echo.ms.redpill-linpro.com> <55001776.6070002@inex.ie> <55004224.5050009@ripe.net> <550045DC.8090604@inex.ie> <89677BF6-271B-4B93-AEFE-C28905FFD292@arin.net> <5501919D.3020700@inex.ie> Message-ID: On Mar 12, 2015, at 9:16 AM, Nick Hilliard wrote: > On 12/03/2015 12:45, John Curran wrote: >> ARIN's policies only apply to number resources that are contained >> within in the ARIN registry. To the best of my knowledge, number >> resources which have been transferred to another regional registry >> would be subject to that regional Internet registry's policies. > ... > It clarifies the intent, but "to the best of my knowledge" is an expression > of opinion rather than a formal statement of policy. If we're going to > have a working transfer mechanism, given that there is a level of ambiguity > in the text in the ARIN transfer policy, it would be good if this could be > clarified formally so that we can remove any doubt. Nick - Actually, it is unclear if there is indeed any ambiguity in the ARIN inter-RIR transfer policy, but regardless, the following statement that I made above _is_ a formal clarification - "ARIN's policies only apply to number resources that are contained within in the ARIN registry." What follows is prefaced by "To the best of my knowledge" simply because it reflects my belief that other RIRs also do apply their policies to resources within their registry (something over which neither ARIN nor I have any control...) I hope this helps; please let me know if any further clarification is needed. Thanks! /John John Curran President and CEO ARIN From mschmidt at ripe.net Thu Mar 12 16:11:24 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 12 Mar 2015 16:11:24 +0100 Subject: [address-policy-wg] 2014-13 Proposal Accepted (Allow AS Number Transfers) Message-ID: Dear colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-525, "Autonomous System (AS) Number Assignment Policies", has been accepted by the RIPE community. This policy change allows the transfer of Autonomous System (AS) numbers within the RIPE NCC service region. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-13 The new RIPE Document is called ripe-638 and is available at: https://www.ripe.net/ripe/docs/ripe-638 We estimate that this proposal will take about three months to fully implement. Details of the implementation status are available at: https://www.ripe.net/lir-services/resource-management/policy-implementation-status We will send another announcement once the implementation is complete and the new procedures are in place. Thank you to everyone who provided their input. Regards, Marco Schmidt Policy Development Officer RIPE NCC From nick at inex.ie Thu Mar 12 23:59:08 2015 From: nick at inex.ie (Nick Hilliard) Date: Thu, 12 Mar 2015 22:59:08 +0000 Subject: [address-policy-wg] APNIC temporarily freezing v4 transfers to RIPE NCC? In-Reply-To: References: <54FF0F89.4070606@inex.ie> <20150310155914.GT1012@cilantro.c4inet.net> <20150311103832.67e47754@echo.ms.redpill-linpro.com> <55001776.6070002@inex.ie> <55004224.5050009@ripe.net> <550045DC.8090604@inex.ie> <89677BF6-271B-4B93-AEFE-C28905FFD292@arin.net> <5501919D.3020700@inex.ie> Message-ID: <55021A3C.1030809@inex.ie> John, On 12/03/2015 13:50, John Curran wrote: > Actually, it is unclear if there is indeed any ambiguity in the ARIN inter-RIR > transfer policy, but regardless, the following statement that I made above _is_ > a formal clarification - > > "ARIN's policies only apply to number resources that are contained > within in the ARIN registry." > > What follows is prefaced by "To the best of my knowledge" simply because > it reflects my belief that other RIRs also do apply their policies to > resources within their registry (something over which neither ARIN nor > I have any control...) > > I hope this helps; please let me know if any further clarification is needed. thanks for the clarification. This very helpful and useful. Nick From nick at inex.ie Wed Mar 18 16:46:17 2015 From: nick at inex.ie (Nick Hilliard) Date: Wed, 18 Mar 2015 15:46:17 +0000 Subject: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations) Message-ID: <55099DC9.7080009@inex.ie> > I think that the more we talk about it, the more this loophole will be > (ab)used. The part that was just theoretical was estimating how long it > will take a company to decide that instead of going to the market, they > could actually go to the RIPE NCC and get a /16 or maybe a /12 at ?2.3 - > ?3.4 per IP (depending in which quarter you decide to do it). from what I understand, the procedures clarified in RIPE-640 mean that the price of a /22 obtained by LIR churn will remain at startup fee + 1Y membership, and that it doesn't make any difference to the overall cost whether this is done in Q1 or Q4 because when you open a LIR, you are liable for a full year's membership fees. I.e. cost of doing this in 2015 is 1600+2000 = 3600, or ?3.51 per ip address. Nick From ripe-wgs at radu-adrian.feurdean.net Wed Mar 18 18:03:47 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 18 Mar 2015 18:03:47 +0100 Subject: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations) In-Reply-To: <55099DC9.7080009@inex.ie> References: <55099DC9.7080009@inex.ie> Message-ID: <1426698227.2244192.242110453.31A7DF63@webmail.messagingengine.com> On Wed, Mar 18, 2015, at 16:46, Nick Hilliard wrote: > the price of a /22 obtained by LIR churn will remain at startup fee + 1Y > membership, and that it doesn't make any difference to the overall cost > whether this is done in Q1 or Q4 because when you open a LIR, you are > liable for a full year's membership fees. I.e. cost of doing this in Hi, When you open a LIR you are liable for the opening fee corresponding to the remaining period of the year ("the service fee, calculated pro rata at the time of requesting membership"). Is someone opens a LIR in Q3, transfers the newly obtained space and send the closing letter also in Q3, the closing will be effective in Q4 and the fee due only corresponds to half a year = 2800 EUR = 2.74 EUR/IP. In Q4, it will roll-over to the next year (=4000 EUR = 3.9 EUR/IP). From gert at space.net Wed Mar 18 18:04:07 2015 From: gert at space.net (Gert Doering) Date: Wed, 18 Mar 2015 18:04:07 +0100 Subject: [address-policy-wg] 2014-12 Proposal Accepted (Allow IPv6 Transfers) In-Reply-To: References: Message-ID: <20150318170407.GA72524@Space.Net> Dear Address Policy WG, On Tue, Feb 17, 2015 at 11:17:07AM +0100, Marco Schmidt wrote: > The proposal described in 2014-12, "Allow IPv6 Transfers", is now in its > Concluding Phase. [..] > Please e-mail any final comments about this proposal to address-policy-wg at ripe.net > before 18 March 2015. The "last call" phase has now ended. No comments were received, which formally is consent in this phase. Thus, the chairs hereby declare consensus on 2014-12. If you disagree with this decision please contact the working group chairs (preferably on this public mailing list and otherwise by sending mail to apwg-chairs at ripe.net). Should that not resolve the problem then you can appeal to the WG chairs collective (as per section 4 of ripe-614). Marco will send the formal announcement from the NCC soon. regards, Gert Doering and Sander Steffann -- 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From elvis at v4escrow.net Wed Mar 18 18:50:52 2015 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Wed, 18 Mar 2015 18:50:52 +0100 Subject: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations) In-Reply-To: <1426698227.2244192.242110453.31A7DF63@webmail.messagingengine.com> References: <55099DC9.7080009@inex.ie> <1426698227.2244192.242110453.31A7DF63@webmail.messagingengine.com> Message-ID: <5509BAFC.5010004@v4escrow.net> Hi, On 18/03/15 18:03, Radu-Adrian FEURDEAN wrote: > On Wed, Mar 18, 2015, at 16:46, Nick Hilliard wrote: > >> the price of a /22 obtained by LIR churn will remain at startup fee + 1Y >> membership, and that it doesn't make any difference to the overall cost >> whether this is done in Q1 or Q4 because when you open a LIR, you are >> liable for a full year's membership fees. I.e. cost of doing this in > Hi, > > When you open a LIR you are liable for the opening fee corresponding to > the remaining period of the year ("the service fee, calculated pro rata > at the time of requesting membership"). > Is someone opens a LIR in Q3, transfers the newly obtained space and > send the closing letter also in Q3, the closing will be effective in Q4 > and the fee due only corresponds to half a year = 2800 EUR = 2.74 > EUR/IP. > In Q4, it will roll-over to the next year (=4000 EUR = 3.9 EUR/IP). > looks someone has done it's homework.. hehe :) I am sure the RIPE NCC can clarify the procedures. How much one pays if you open an LIR in Q3 vs Q4 vs Q1 and whether they can force an LIR to stay open or pay for the one year fee before or after the transfer of the /22. The cost of opening an LIR in 2015 is, indeed ?3600 (if the member will pay the full membership fee for that year), I was under the impression that the fee has been lowered to ?1500 but I was wrong. However, if someone registers in Sept-2015 and chooses to pay quarterly, once they have received the /22 and transferred it, what forces them to pay for 2016? They can just announce the RIPE NCC in Oct-2015 that they no longer want to be a member in 2016 and close the LIR before December.. And even if the RIPE NCC continues to issue invoices, they may just close the company or ignore the messages from the RIPE NCC and then NCC's costs to chase the non-payer may be bigger than the gain. I do not think that the RIPE NCC can force a member to pay one year in advance for the membership services before transferring the /22. I also do not think that the RIPE NCC can force anyone to keep an LIR open in 2016 or pay for the membership fee in 2016 if they announce the RIPE NCC that they want to close before December of 2015. Regards, Elvis -- Elvis Daniel Velea Chief Executive Officer Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +31 (0) 61458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From alioumis at noc.grnet.gr Thu Mar 19 09:54:29 2015 From: alioumis at noc.grnet.gr (Antonis Lioumis) Date: Thu, 19 Mar 2015 10:54:29 +0200 Subject: [address-policy-wg] aggregating unused allocations Message-ID: Hello Recently my company got a /22 allocation through the well known transfer procedure between LIR's. In the past we also got the /22 we qualify from RIPE NCC's last /8. This /22 was put aside for future use. For aggregation purposes we asked RIPE NCC to return both /22 and get back a /21 but according to current policies this is forbidden. Since global routing table has exceeded 500000 prefixes and expected to grow more maybe RIPE community should rethink permitting the exchange of smaller IPv4 blocks with contiguous one. Regards Antonis Lioumis From sonia at ripe.net Thu Mar 19 10:02:33 2015 From: sonia at ripe.net (Sonia Garbi Gomez) Date: Thu, 19 Mar 2015 10:02:33 +0100 Subject: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations) Message-ID: <550A90A9.8080900@ripe.net> Dear all For 2015, all RIPE NCC members are charged an annual service fee of ? 1,600 for each LIR account they hold. For New LIRs that are established during the year, the service fee is applied pro rata, meaning thus that new LIRs established during the course of 2015, are charged as follow: New LIR established: Total fee: How the fee is made up: * during first quarter ? 3,600 Sign up fee (? 2,000) + service fee (? 1,600) * during second quarter ? 3,200 Sign up fee (? 2,000) + service fee (? 1,200) * during third quarter ? 2,800 Sign up fee (? 2,000) + service fee (? 800) * during fourth quarter ? 2,400 Sign up fee (? 2,000) + service fee (? 400) I hope this clarifies the question. best regards Sonia Garbi Gomez Finance Manager RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikolas.pediaditis at ripe.net Thu Mar 19 10:53:12 2015 From: nikolas.pediaditis at ripe.net (Nikolas Pediaditis) Date: Thu, 19 Mar 2015 10:53:12 +0100 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-04, "Removing IPv6 Requirement for Receiving Space from the Final /8" Message-ID: <228FD667-D22D-4FFF-BD7F-638D472CF45C@ripe.net> Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2014-04, "Removing IPv6 Requirement for Receiving Space from the Final /8". In accordance with the new policy, RIPE NCC members can now request to receive a one time /22 IPv4 allocation from the last /8 without the requirement to already have an IPv6 allocation. The archived policy proposal can be found at: https://www.ripe.net/ripe/policies/proposals/2014-04 The updated RIPE Document, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is available at: https://www.ripe.net/ripe/docs/ripe-634 Kind regards, Nikolas Pediaditis RIPE NCC Registration Services From elvis at v4escrow.net Thu Mar 19 11:13:18 2015 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Thu, 19 Mar 2015 11:13:18 +0100 Subject: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations) In-Reply-To: <550A90A9.8080900@ripe.net> References: <550A90A9.8080900@ripe.net> Message-ID: <550AA13E.5080408@v4escrow.net> Hi Sonia, those numbers were quite clear. What we were wondering is whether it is possible to register an LIR in Q4 2015, pay the ?2400, receive the /22, transfer the /22, close the LIR within the same quarter. Or, does the LIR need to pay the fee for a whole year (4 quarters) when they close (or transfer the /22) - regardless on which Q they were opened? Regards, Elvis On 19/03/15 10:02, Sonia Garbi Gomez wrote: > Dear all > > For 2015, all RIPE NCC members are charged an annual service fee of ? 1,600 for each LIR account they hold. > For New LIRs that are established during the year, the service fee is applied pro rata, meaning thus that new LIRs established during the course of 2015, are charged as follow: > > New LIR established: Total fee: How the fee is made up: > * during first quarter ? 3,600 Sign up fee (? 2,000) + service fee (? 1,600) > * during second quarter ? 3,200 Sign up fee (? 2,000) + service fee (? 1,200) > * during third quarter ? 2,800 Sign up fee (? 2,000) + service fee (? 800) > * during fourth quarter ? 2,400 Sign up fee (? 2,000) + service fee (? 400) > I hope this clarifies the question. > best regards > > Sonia Garbi Gomez > Finance Manager > RIPE NCC -- Elvis Daniel Velea Chief Executive Officer Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +31 (0) 61458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Thu Mar 19 11:51:12 2015 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Thu, 19 Mar 2015 11:51:12 +0100 Subject: [address-policy-wg] aggregating unused allocations In-Reply-To: References: Message-ID: <550AAA20.10101@schiefner.de> Hi Antonis - On 19.03.2015 09:54, Antonis Lioumis wrote: > Recently my company got a /22 allocation through the well known transfer > procedure between LIR's. > In the past we also got the /22 we qualify from RIPE NCC's last /8. This > /22 was put aside for future use. > For aggregation purposes we asked RIPE NCC to return both /22 and get > back a /21 but according to current policies this is forbidden. > Since global routing table has exceeded 500000 prefixes and expected to > grow more maybe RIPE community should rethink permitting the exchange of > smaller IPv4 blocks with contiguous one. how about sending text for a policy (change) in this respect? :-) Cheers, Carsten From scottleibrand at gmail.com Thu Mar 19 18:29:52 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 19 Mar 2015 17:29:52 +0000 Subject: [address-policy-wg] aggregating unused allocations In-Reply-To: <550AAA20.10101@schiefner.de> References: <550AAA20.10101@schiefner.de> Message-ID: For reference, in the ARIN region we just got rid of our aggregation policy because it was almost never used, and staff had identified a loophole where a large address holder could have requested a large aggregation block, exhausted the free pool, and then taken their time about returning the smaller blocks. If you want to implement an aggregation policy in RIPE, it's probably worth taking the ARIN experience into account and drafting the policy to deal with those issues. -Scott On Thu, Mar 19, 2015 at 4:07 AM Carsten Schiefner wrote: > Hi Antonis - > > On 19.03.2015 09:54, Antonis Lioumis wrote: > > Recently my company got a /22 allocation through the well known transfer > > procedure between LIR's. > > In the past we also got the /22 we qualify from RIPE NCC's last /8. This > > /22 was put aside for future use. > > For aggregation purposes we asked RIPE NCC to return both /22 and get > > back a /21 but according to current policies this is forbidden. > > Since global routing table has exceeded 500000 prefixes and expected to > > grow more maybe RIPE community should rethink permitting the exchange of > > smaller IPv4 blocks with contiguous one. > > how about sending text for a policy (change) in this respect? :-) > > Cheers, > > Carsten > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Thu Mar 19 23:49:04 2015 From: sander at steffann.nl (Sander Steffann) Date: Thu, 19 Mar 2015 23:49:04 +0100 Subject: [address-policy-wg] Working group chair selection process Message-ID: <7EC90FC5-40CD-4604-8025-F3E253C64D43@steffann.nl> Hi Working Group, We finally have a final draft for the working group chair selection process. Sorry for taking so long. Here is the text we propose to use: --- The RIPE Address Policy Working Group aims to maintain a team of two Chairpersons whenever possible. # Electing a chairperson Once a year one of the chairs will step down, allowing new candidates the opportunity to become chair. The chairs take turns stepping down, and this is announced to the working group mailing list at least one month before the start of a RIPE meeting. The working group will select new chair(s) at the RIPE Address Policy Working Group session. Those present at the session, either in person or remotely, will determine by consensus among themselves who takes the available position(s). The remaining chair will determine whether consensus has been reached. If the working group finds itself without a chair the RIPE chair will determine consensus. If no consensus can be reached then a secret ballot to elect the new chair(s) will be held at the working group session. Everyone physically present at the session can participate in the secret ballot. Votes will be counted by RIPE NCC Staff, and the result will be determined using proportional representation through the single transferable vote, otherwise known as PR-STV. The winner(s) of the secret ballot will become the new chair(s). # Running for chairperson Anybody is allowed to volunteer for a vacant chair position, including former chairs. Those who volunteer to chair the RIPE Address Policy Working Group should be aware of the responsibilities and work this involves. A description of the responsibilities of a RIPE working group chair can be found in "Working Group Chair Job Description and Procedures" (http://www.ripe.net/ripe/docs/ripe-542). # Removing a chairperson When a significant number of participants in the working group are unsatisfied with a particular chair, and this cannot be resolved by discussion within the working group, they can call for a vote of no confidence. The vote must be requested on the mailing list at least one week before a RIPE meeting. The vote will be resolved using a secret ballot, which will be held at the working group session. Everyone physically present at the meeting can participate. The votes will be counted by RIPE NCC Staff and the result is determined by simple majority. If the vote is passed the chair who is the subject of the vote will step down immediately. --- We're doing a two-week last-call on this (ending on Friday 3 April) and if there are no objections we will use this process starting at RIPE70 in Amsterdam. Cheers, Sander & Gert The current APWG chairs From sonia at ripe.net Fri Mar 20 12:37:12 2015 From: sonia at ripe.net (Sonia Garbi Gomez) Date: Fri, 20 Mar 2015 12:37:12 +0100 Subject: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations) In-Reply-To: <7EC145E2-5E3F-423D-9B50-B02E3A68DEA4@ripe.net> References: <7EC145E2-5E3F-423D-9B50-B02E3A68DEA4@ripe.net> Message-ID: <550C0668.9050101@ripe.net> Hi Elvis, see my reply inline > *From: *Elvis Daniel Velea > > *Subject: **Re: [address-policy-wg] 2015-01 New Policy Proposal > (Alignment ofTransfer Requirements for IPv4 Allocations)* > *Date: *19 Mar 2015 11:13:18 GMT+1 > *To: *address-policy-wg at ripe.net > > Hi Sonia, > > those numbers were quite clear. What we were wondering is whether it > is possible to register an LIR in Q4 2015, pay the ?2400, receive the > /22, transfer the /22, close the LIR within the same quarter. > This was correct. If a new LIR was joined at the end of the year, the LIR had to pay only for the last quarter as well as the sign-up fee. However, the RIPE NCC Executive Board held it latest meeting on 20 March 2015. The Board made a resolution that LIRs that join the RIPE NCC and close within 12 months, have to pay the full annual service fee before commencement of a merger, transfer or a closure procedure. This means that from now on, an LIR that joins the RIPE NCC in the course of the year (for example in June 2015) and wishes to close before the end of the year, will have to pay the full service fee for 2015 (rather than the last two quarters as was previously the case) before a merger, transfer or closure procedure can commence. An official announcement will follow shortly along with the minutes of the Executive Board Meeting. Have a lovely weekend. Sonia > Or, does the LIR need to pay the fee for a whole year (4 quarters) > when they close (or transfer the /22) - regardless on which Q they > were opened? > > Regards, > Elvis > > On 19/03/15 10:02, Sonia Garbi Gomez wrote: >> Dear all >> >> For 2015, all RIPE NCC members are charged an annual service fee of ? 1,600 for each LIR account they hold. >> For New LIRs that are established during the year, the service fee is applied pro rata, meaning thus that new LIRs established during the course of 2015, are charged as follow: >> >> New LIR established: Total fee: How the fee is made up: >> * during first quarter ? 3,600 Sign up fee (? 2,000) + service fee (? 1,600) >> * during second quarter ? 3,200 Sign up fee (? 2,000) + service fee (? 1,200) >> * during third quarter ? 2,800 Sign up fee (? 2,000) + service fee (? 800) >> * during fourth quarter ? 2,400 Sign up fee (? 2,000) + service fee (? 400) >> I hope this clarifies the question. >> best regards >> >> Sonia Garbi Gomez >> Finance Manager >> RIPE NCC > > > -- > > > > Elvis Daniel Velea > > > Chief Executive Officer > > Email: elvis at V4Escrow.net > US Phone: +1 (702) 475 5914 > EU Phone: +31 (0) 61458 1914 > > Recognised IPv4 Broker/Facilitator in: > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you have > received this email in error, please notify the sender immediately and > delete the original.Any other use of this email is strictly prohibited. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 11971 bytes Desc: not available URL: From james.blessing at despres.co.uk Fri Mar 20 14:38:51 2015 From: james.blessing at despres.co.uk (James Blessing) Date: Fri, 20 Mar 2015 13:38:51 +0000 Subject: [address-policy-wg] Working group chair selection process In-Reply-To: <7EC90FC5-40CD-4604-8025-F3E253C64D43@steffann.nl> References: <7EC90FC5-40CD-4604-8025-F3E253C64D43@steffann.nl> Message-ID: On 19 March 2015 at 22:49, Sander Steffann wrote: > Hi Working Group, > > We finally have a final draft for the working group chair selection process. Sorry for taking so long. Here is the text we propose to use: > Some "thoughts"... > > Once a year one of the chairs will step down, allowing new candidates the opportunity to become chair. The chairs take turns stepping down, and this is announced to the working group mailing list at least one month before the start of a RIPE meeting. Wording should probably be "longest serving chair steps down" rather than "taking turns" What happens the year after two chairs are elected? > The working group will select new chair(s) at the RIPE Address Policy Working Group session. Those present at the session, either in person or remotely, will determine by consensus among themselves who takes the available position(s). The remaining chair will determine whether consensus has been reached. If the working group finds itself without a chair the RIPE chair will determine consensus. > For the avoidance of accusations of bias it might be better to appoint a member of the arbitration panel to fulfil this role in all cases? > If no consensus can be reached then a secret ballot to elect the new chair(s) will be held at the working group session. Everyone physically present at the session can participate in the secret ballot. Votes will be counted by RIPE NCC Staff, and the result will be determined using proportional representation through the single transferable vote, otherwise known as PR-STV. The winner(s) of the secret ballot will become the new chair(s). It's good practise to include the counting method used (just to stop any arguments) > # Running for chairperson > > Anybody is allowed to volunteer for a vacant chair position, including former chairs. > > Those who volunteer to chair the RIPE Address Policy Working Group should be aware of the responsibilities and work this involves. A description of the responsibilities of a RIPE working group chair can be found in "Working Group Chair Job Description and Procedures" (http://www.ripe.net/ripe/docs/ripe-542). How does one step forward as a potential chair? Doesn't there need to be a hint of the process? > # Removing a chairperson > > When a significant number of participants in the working group are unsatisfied with a particular chair, and this cannot be resolved by discussion within the working group, they can call for a vote of no confidence. The vote must be requested on the mailing list at least one week before a RIPE meeting. The vote will be resolved using a secret ballot, which will be held at the working group session. Everyone physically present at the meeting can participate. The votes will be counted by RIPE NCC Staff and the result is determined by simple majority. If the vote is passed the chair who is the subject of the vote will step down immediately. This should then clarify what happens next. See previous comment about the "nomination" process Whats the process where both chairs are objected too? Shouldn't the first selection be for both chair positions to cement their "validity" as chairs /me wanders off into a corner J -- James Blessing 07989 039 476 From sander at steffann.nl Fri Mar 20 15:43:02 2015 From: sander at steffann.nl (Sander Steffann) Date: Fri, 20 Mar 2015 15:43:02 +0100 Subject: [address-policy-wg] Working group chair selection process In-Reply-To: References: <7EC90FC5-40CD-4604-8025-F3E253C64D43@steffann.nl> Message-ID: <47AFD58B-4D0F-4274-9457-FEEEE9EA6A14@steffann.nl> Hi, >> Once a year one of the chairs will step down, allowing new candidates the opportunity to become chair. The chairs take turns stepping down, and this is announced to the working group mailing list at least one month before the start of a RIPE meeting. > > Wording should probably be "longest serving chair steps down" rather > than "taking turns" Nope. That would mean that Gert would step down first, and then when he stays as chair he'll be the one stepping down next time again etc. If we want to be specific then we'd have to say something like "the chair whose current serving term is the longest" or something like that in better English. > What happens the year after two chairs are elected? If we specify "longest" then that will be even more difficult as they will have been there equally long :) >> The working group will select new chair(s) at the RIPE Address Policy Working Group session. Those present at the session, either in person or remotely, will determine by consensus among themselves who takes the available position(s). The remaining chair will determine whether consensus has been reached. If the working group finds itself without a chair the RIPE chair will determine consensus. > > For the avoidance of accusations of bias it might be better to appoint > a member of the arbitration panel to fulfil this role in all cases? It's not the chair making a decision. It's the WG that does that and the chair will only determine consensus. He will be announcing consensus in front of the room so if he makes a bad call I'm sure it will be pointed out to him/her :) Which would mean no consensus, which would mean a ballot. I really don't feel we should make this more difficult (but open to feedback from the WG of course! :) and we should do this in such a way that as little WG session time as reasonably possible is taken up by this process. >> If no consensus can be reached then a secret ballot to elect the new chair(s) will be held at the working group session. Everyone physically present at the session can participate in the secret ballot. Votes will be counted by RIPE NCC Staff, and the result will be determined using proportional representation through the single transferable vote, otherwise known as PR-STV. The winner(s) of the secret ballot will become the new chair(s). > > It's good practise to include the counting method used (just to stop > any arguments) I'm not sure what you're asking here... >> # Running for chairperson >> >> Anybody is allowed to volunteer for a vacant chair position, including former chairs. >> >> Those who volunteer to chair the RIPE Address Policy Working Group should be aware of the responsibilities and work this involves. A description of the responsibilities of a RIPE working group chair can be found in "Working Group Chair Job Description and Procedures" (http://www.ripe.net/ripe/docs/ripe-542). > > How does one step forward as a potential chair? Doesn't there need to > be a hint of the process? Good catch! Yes: I suggest volunteers must make themselves known and introduce themselves on the mailing list. >> # Removing a chairperson >> >> When a significant number of participants in the working group are unsatisfied with a particular chair, and this cannot be resolved by discussion within the working group, they can call for a vote of no confidence. The vote must be requested on the mailing list at least one week before a RIPE meeting. The vote will be resolved using a secret ballot, which will be held at the working group session. Everyone physically present at the meeting can participate. The votes will be counted by RIPE NCC Staff and the result is determined by simple majority. If the vote is passed the chair who is the subject of the vote will step down immediately. > > This should then clarify what happens next. See previous comment about > the "nomination" process > > Whats the process where both chairs are objected too? Good point. The WG would be without chairs until the next RIPE meeting. I guess the best solution in this case would be if the WG appoints an interim chair until then. > Shouldn't the first selection be for both chair positions to cement > their "validity" as chairs No, that is also one of the reasons that chairs should take turns stepping down. Running APWG is not an easy task and (potentially) replacing both chairs at the same time should be avoided whenever possible. During the discussions on chair rotation we have also had enough feedback that the working group is ok with us chairing it for now (we explicitly asked, we don't want to be chairs when we don't have the WG's support) so I see no reason to risk the stability of the WG. If we just take turns stepping down then one will step down in May 2015 and the other one in ?May 2016 so we can transfer the responsibilities to a new team of chairs in that period should that be the outcome of the rotation process. > /me wanders off into a corner Don't forget to grab some popcorn on the way ;) I'll post an updated text to fix the obvious bugs at the end of today. Cheers! Sander From sander at steffann.nl Sat Mar 21 01:38:31 2015 From: sander at steffann.nl (Sander Steffann) Date: Sat, 21 Mar 2015 01:38:31 +0100 Subject: [address-policy-wg] Working group chair selection process In-Reply-To: <47AFD58B-4D0F-4274-9457-FEEEE9EA6A14@steffann.nl> References: <7EC90FC5-40CD-4604-8025-F3E253C64D43@steffann.nl> <47AFD58B-4D0F-4274-9457-FEEEE9EA6A14@steffann.nl> Message-ID: <224DC305-6B23-46E9-B3F9-5DBA16A70261@steffann.nl> Hi working group, As promised here is a slightly modified version of the chair selection text: --- The RIPE Address Policy Working Group aims to maintain a team of two Chairpersons whenever possible. # Selecting a chairperson Once a year one of the chairs will step down, allowing new candidates the opportunity to become chair. The chairs take turns stepping down, and this is announced to the working group mailing list at least one month before the start of a RIPE meeting. The working group will select new chair(s) at the RIPE Address Policy Working Group session. Those present at the session, either in person or remotely, will determine by consensus among themselves who takes the available position(s). The remaining chair will determine whether consensus has been reached. If the working group finds itself without a chair the RIPE chair will determine consensus. If no consensus can be reached then a secret ballot to elect the new chair(s) will be held at the working group session. Everyone physically present at the session can participate in the secret ballot. Votes will be counted by RIPE NCC Staff, and the result will be determined using proportional representation through the single transferable vote, otherwise known as PR-STV. The winner(s) of the secret ballot will become the new chair(s). # Running for chairperson Anybody is allowed to volunteer for a vacant chair position, including former chairs. Volunteers make themselves known by introducing themselves as a candidate on the working group mailing list before the start of the RIPE meeting. Those who volunteer to chair the RIPE Address Policy Working Group should be aware of the responsibilities and work this involves. A description of the responsibilities of a RIPE working group chair can be found in "Working Group Chair Job Description and Procedures" (http://www.ripe.net/ripe/docs/ripe-542). # Removing a chairperson When a significant number of participants in the working group are unsatisfied with a particular chair, and this cannot be resolved by discussion within the working group, they can call for a vote of no confidence. The vote must be requested on the mailing list at least one week before a RIPE meeting. The vote will be resolved using a secret ballot, which will be held at the working group session. Everyone physically present at the meeting can participate. The votes will be counted by RIPE NCC Staff and the result is determined by simple majority. If the vote is passed the chair who is the subject of the vote will step down immediately. # No Chairs If a working group is left with no chair then they may elect an interim chair according to the selection procedures specified above, but with candidates nominated at the working group session. An interim chair must step down at the next working group session, but may stand for re-selection. --- The only changes made are to specify that volunteers for a chair position must make themselves known on the mailing list before the meeting and to add a relaxed version for the special case when the working group finds itself without any chairs. We're continuing the two-week last-call on this (ending on Friday 3 April) and if there are no objections we will use this process starting at RIPE70 in Amsterdam. Cheers! Sander From mschmidt at ripe.net Mon Mar 23 15:04:18 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 23 Mar 2015 15:04:18 +0100 Subject: [address-policy-wg] 2014-12 Proposal Accepted (Allow IPv6 Transfers) Message-ID: Dear colleagues, Consensus has been reached, and the proposal for a change to ripe-589, "IPv6 Address Allocation and Assignment Policy", has been accepted by the RIPE community. This policy change allows the transfer of IPv6 allocations and IPv6 Provider Independent (PI) assignments within the RIPE NCC service region. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-12 The new RIPE Document is called ripe-641 and is available at: https://www.ripe.net/ripe/docs/ripe-641 Given the similarity of this policy to the recently accepted Policy Proposal 2014-13, "Allow AS Number Transfers", the RIPE NCC will implement both policy changes together. This is a more efficient execution of the policy implementation process and will lead to an extension of only two weeks to the initial estimated implementation period. We therefore estimate that to fully implement both proposals together will take three and a half months in total. Details of the implementation status are available at: https://www.ripe.net/lir-services/resource-management/policy-implementation-status We will send another announcement once the implementation is complete and the new procedures are in place. Thank you to everyone who provided their input. Regards, Marco Schmidt Policy Development Officer RIPE NCC From sander at steffann.nl Tue Mar 24 11:41:01 2015 From: sander at steffann.nl (Sander Steffann) Date: Tue, 24 Mar 2015 11:41:01 +0100 Subject: [address-policy-wg] aggregating unused allocations In-Reply-To: References: Message-ID: <8896F01B-CDE0-416B-AF84-5664E63C1C0C@steffann.nl> Hi, > Since global routing table has exceeded 500000 prefixes and expected to grow more maybe RIPE community should rethink permitting the exchange of smaller IPv4 blocks with contiguous one. One thing to keep in mind is that this would make it possible for e.g. spammers to exchange two 'dirty' /22s for a 'clean' /21. Just a thought :) Sander