From nick at inex.ie Thu Jan 1 11:59:27 2015 From: nick at inex.ie (Nick Hilliard) Date: Thu, 01 Jan 2015 10:59:27 +0000 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: References: Message-ID: <54A5288F.50002@inex.ie> On 28/12/2014 19:59, Hannigan, Martin wrote: > On Dec 23, 2014, at 3:37 PM, Randy Bush wrote: >>> "Any holder of Autonomous System (AS) Numbers is allowed to re-assign >>> AS Numbers that were previously assigned to them by the RIPE NCC or >>> otherwise through the Regional Internet Registry System." >>> >>> ?reads to me that transfer or reassignment is allowed inter-rir. >> >> yes, quite well done. > > Agreed on the policy. I support its continued move forward. +1 Nick From hamed at skydsl.ir Thu Jan 1 16:48:41 2015 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Thu, 1 Jan 2015 19:18:41 +0330 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: <54A5288F.50002@inex.ie> References: <54A5288F.50002@inex.ie> Message-ID: Strongly Support +1 -- -------------------------------------------- I Hamed Shafaghi I I Managing Director I I Skydsl? Telecom I hamed at skydsl.ir I www.skydsl.ir I -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Thu Jan 1 18:02:40 2015 From: nick at inex.ie (Nick Hilliard) Date: Thu, 01 Jan 2015 17:02:40 +0000 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20141225103945.GD40149@Vurt.local> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> <20141225103945.GD40149@Vurt.local> Message-ID: <54A57DB0.1010107@inex.ie> On 25/12/2014 10:39, Job Snijders wrote: > So you are using a terrible amount of handwaving and overbreathing to > suggest that we refrain from ASN Assignment policy changes until the AGM > decides to start charging a yearly fee for ASNs again? > > What if such a yaerly fee is never introduced? As a more general issue, we need to accept as a community that there is a crossover between RIPE Community policy and RIPE NCC membership policy, and that this is one of those intersections. The initial-idea to implementation-time for a RIPE policy proposal is rarely less than 12 months. Rather than thinking in terms of now or 6 or 12 months time, it's a better idea to formulate policy based on where the RIPE Community might want to be several years down the road. Based on this, the questions we need to ask *now* about what policy we want down the road should revolve around this: > What's absurd is that currently you cannot just get an ASN when you ask > for one. The current policy wording is a bit annoying but we're all used to the idea of providing the RIPE NCC with the correct incantation to get around its restrictions, so the net effect at the moment is that you can get an ASN if you want one. I.e. we're already running with a liberal assignment policy. All things considered, there's not a major problem living with the current policy formulation for another 12 months if that's what it takes to fix the policy properly. As a brief aside, we previously had this problem with fanciful story-telling to obtain IPv4 PI assignments. At the time the community agreed that telling porkie pies to justify assignments was probably neither clever nor compatible with good stewardship of resources. The way to fix this issue is to understand what the main underlying problems are with ASN assignment. They are: 1. no garbage collection 2. limited supply of ASN16s, causing exhaustion in the medium term The limited supply of ASN16s is only a problem because of lousy BGP Community support for ASN32s. If the IETF were to fix this problem, there would no substantial difference between 2-byte and 4-byte ASNs and we'd all be happy with a generic liberal assignment policy for all colours of ASN. In the interim, it's a question of interpretation as to whether it's worth changing the policy to slow down the run-out rate or not, given that the IETF is apparently more interested in the latest shiny baubles than fixing the BGP protocol to support this basic feature. The simplest way to implement garbage collection is to apply a small charge to each resource. The current iteration of this proposal suggests a partial garbage collection method which is IMO unworkable. It's unworkable because the RIPE NCC has never before had a policy of reclaiming resources because the initial application justification was changed, so going back on 20 years of working policy will probably be legally dubious in several of the jurisdictions that the RIPE NCC operates in. There's also a issue surrounding what level of change from the initial assignment criteria would be acceptable for reclaiming the resource. In other words, the proposal doesn't fix the problem of garbage collection; it simply shifts it to the lawyers. This is not clever. The only mechanism guaranteed to work as a garbage collection mechanism across all 76 or so jurisdictions is payment for receipt of good or services. Pretty much every legal system in the world accepts non payment of dues as a basis for breach of contract. Other than striving towards as being simple as possible (but no simpler), it's probably a good idea to align ASN assignment policy with other number resource policy. There's been no good reason suggested as to why ASN assignment policy should head towards more complicated rules when ipv4/ipv6 assignment/allocation policy has already gone in the opposite direction. Nick From luca.cicchelli at top-ix.org Thu Jan 1 19:24:05 2015 From: luca.cicchelli at top-ix.org (Luca Cicchelli) Date: Thu, 1 Jan 2015 19:24:05 +0100 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: References: Message-ID: <135980B2-128E-4284-A6F3-02F44D499E2C@top-ix.org> +1 -- Luca Sent by mobile > On 28/dic/2014, at 20:59, Hannigan, Martin wrote: > > > On Dec 23, 2014, at 3:37 PM, Randy Bush wrote: > >>> "Any holder of Autonomous System (AS) Numbers is allowed to re-assign >>> AS Numbers that were previously assigned to them by the RIPE NCC or >>> otherwise through the Regional Internet Registry System." >>> >>> ?reads to me that transfer or reassignment is allowed inter-rir. >> >> yes, quite well done. > > > Agreed on the policy. I support its continued move forward. > > > Best, > > -M< > From Lev.Cherednikov at nbn-holding.ru Fri Jan 2 10:46:05 2015 From: Lev.Cherednikov at nbn-holding.ru (=?utf-8?B?0KfQtdGA0LXQtNC90LjQutC+0LIg0JvQtdCyINCS0LjQutGC0L7RgNC+0LI=?= =?utf-8?B?0LjRhyAoTmJOLUhRKQ==?=) Date: Fri, 2 Jan 2015 09:46:05 +0000 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: <135980B2-128E-4284-A6F3-02F44D499E2C@top-ix.org> References: <135980B2-128E-4284-A6F3-02F44D499E2C@top-ix.org> Message-ID: Support absolute! -- Kind regards, Lev V. Cherednikov Net By Net Holding LLC (OJSC "MegaFon" ) www.netbynet.ru 1 ???. 2015 ?., ? 21:24, Luca Cicchelli > ???????(?): +1 -- Luca Sent by mobile On 28/dic/2014, at 20:59, Hannigan, Martin > wrote: On Dec 23, 2014, at 3:37 PM, Randy Bush > wrote: "Any holder of Autonomous System (AS) Numbers is allowed to re-assign AS Numbers that were previously assigned to them by the RIPE NCC or otherwise through the Regional Internet Registry System." ?reads to me that transfer or reassignment is allowed inter-rir. yes, quite well done. Agreed on the policy. I support its continued move forward. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From noc at ntx.ru Fri Jan 2 13:44:04 2015 From: noc at ntx.ru (NTX NOC) Date: Fri, 02 Jan 2015 15:44:04 +0300 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: References: <135980B2-128E-4284-A6F3-02F44D499E2C@top-ix.org> Message-ID: <54A69294.90601@ntx.ru> +1 On 02.01.2015 12:46, ?????????? ??? ?????????? (NbN-HQ) wrote: > Support absolute! > > -- > Kind regards, > Lev V. Cherednikov > Net By Net Holding LLC (OJSC "MegaFon" ) > www.netbynet.ru > > > >> 1 ???. 2015 ?., ? 21:24, Luca Cicchelli > > ???????(?): >> >> +1 >> >> -- >> Luca >> >> Sent by mobile >> >>> On 28/dic/2014, at 20:59, Hannigan, Martin >> > wrote: >>> >>> >>> On Dec 23, 2014, at 3:37 PM, Randy Bush >> > wrote: >>> >>>>> "Any holder of Autonomous System (AS) Numbers is allowed to re-assign >>>>> AS Numbers that were previously assigned to them by the RIPE NCC or >>>>> otherwise through the Regional Internet Registry System." >>>>> >>>>> ?reads to me that transfer or reassignment is allowed inter-rir. >>>> >>>> yes, quite well done. >>> >>> >>> Agreed on the policy. I support its continued move forward. >>> >>> >>> Best, >>> >>> -M< >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Tue Jan 6 14:31:57 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 06 Jan 2015 14:31:57 +0100 Subject: [address-policy-wg] RIPE 69 Address Policy WG Draft Minutes Message-ID: <54ABE3CD.5090108@ripe.net> Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 69 have now been published: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-69 Please let us know of any corrections or amendments. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC From hph at oslo.net Thu Jan 8 23:02:03 2015 From: hph at oslo.net (Hans Petter Holen) Date: Thu, 08 Jan 2015 23:02:03 +0100 Subject: [address-policy-wg] Internet Number Community IANA Stewardship Proposal: Final Call for Comments In-Reply-To: <4B4EB6BB-CBA5-42FD-AD66-E1638093D83E@netnod.se> References: <4B4EB6BB-CBA5-42FD-AD66-E1638093D83E@netnod.se> Message-ID: <54AEFE5B.5040002@oslo.net> I believe this is also important to this group, as it sets the framework for future implementation of global policies. Please have a look at this proposal and please let us know if you support this. Hans Petter -------- Forwarded Message -------- Subject: [cooperation-wg] Fwd: [NRO-IANAXFER] Internet Number Community IANA Stewardship Proposal: Final Call for Comments Date: Thu, 8 Jan 2015 17:27:53 +0100 From: Nurani Nimpuno To: RIPE Cooperation Working Group Dear colleagues, Today the Consolidated RIR IANA Stewardship Proposal (CRISP) team publishes the second draft of the Internet numbers community proposal on the transition of the IANA stewardship. This is intended as a final call for community feedback ahead of the submitting the finalised proposal to the IANA Stewardship Transition Coordination Group (ICG) on Thursday, 15 January. We understand that many in the RIPE community have a strong interest in this process, and feedback provided in this working group and elsewhere has been crucial in reaching the current draft. While there is still an opportunity to provide comments on the current text, we would also like to strongly encourage RIPE community members in favour of this proposal to express their support on this list or via the ianaxfer at nro.net mailing list. A quantifiable level of community support may be important in strengthening the Internet numbers community?s position later in the IANA stewardship transition process. As previously, the timeline for responding is quite tight, with a deadline of Monday, 12 January, for all comments. Best regards, Nurani Nimpuno on behalf of the RIPE CRISP team Begin forwarded message: > From: Izumi Okutani > Subject: [NRO-IANAXFER] Internet Number Community IANA Stewardship Proposal: Final Call for Comments > Date: 8 januari 2015 17:21:08 CET > To: "ianaxfer at nro.net" > > Dear colleagues, > > > Please find the second draft of the Internet numbers community's > response to the Request For Proposals issued by the IANA Stewardship > Coordination Group (ICG). > > This draft has been prepared by the Consolidated RIR IANA Stewardship > Proposal (CRISP) Team, with considerations of feedback received from the > global community on mailing list. > > We have incorporated the following key points in the second draft: > > - Additional description on contract details, review committee and > intellectual property rights > - Description revised on Section V. NITA Requirements and VI. > Community Process for more clarity > - No changes are made to key elements of the proposal > > The CRISP Team have considered all comments expressed on > mailing list before the deadline of 5th Jan 2015, and > would now like to make the final call for comments from the global > community on the draft proposal, before submitting to the ICG. > > Second Draft proposal: > ------------------------ > Clean Version : > > > Redline Version: > > > The deadline for providing feedback: Mon, 12 January 2015 23:59 UTC > Feedback should be sent to : mailing list > > Community Inputs Considered by the CRISP Team: > ------------------------------------------ > You can check the status of the issues raised by the community and > proposed the CRISP Team positions at: > > > > Key dates: > ----------- > Second draft to be published : 8 Jan 2015 > Second draft comments close : 12 Jan 2015, 23:59 UTC > Final proposal to be sent to ICG : 15 Jan 2015 > > How to Engage in Discussions: > ----------------------------- > All global discussions, for the CRISP team to consider as community > feedback, will be conducted at mailing list. > All the CRISP Team discussions are open to observers. > > Next Step: > ----------- > In developing the final draft based on further feedback, the CRISP > Team will ensure it has completed considerations of all substantial > issues raised by the global community, which are compiled in the > published issues list. The proposal will only incorporate issues that > the CRISP team believes have received consensus support from the > community. > > References: > ------------ > * Discussions by the CRISP Team > Details of all the CRISP team's work to date, including recordings, > minutes and agendas of all the CRISP Team teleconferences and a > public archive of the internal CRISP team mailing list, are > available at: > https://nro.net/crisp-team > > * Other links: > - The ICG request for proposals: > > > - The IANA Stewardship Transition Discussion in each RIR region: > > > - First Draft proposal (Edited version) > > > > _______________________________________________ > ianaxfer mailing list > ianaxfer at nro.net > https://www.nro.net/mailman/listinfo/ianaxfer -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at bais.name Fri Jan 9 12:41:01 2015 From: erik at bais.name (Erik Bais) Date: Fri, 9 Jan 2015 11:41:01 +0000 Subject: [address-policy-wg] Internet Number Community IANA Stewardship Proposal: Final Call for Comments In-Reply-To: <54AEFE5B.5040002@oslo.net> References: <4B4EB6BB-CBA5-42FD-AD66-E1638093D83E@netnod.se> <54AEFE5B.5040002@oslo.net> Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C0115435E2D@E2010-MBX03.exchange2010.nl> Hi Hans Peter, There is a discussion mailing list for this (https://www.nro.net/pipermail/ianaxfer/ ), is the idea to have questions and discussion on that particular mailing list for those that want to get a clear global reply on questions they might have ? and the more RIPE RIR point discussion in coop-wg ? Regards, Erik Bais Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Hans Petter Holen Verzonden: donderdag 8 januari 2015 23:02 Aan: address-policy-wg at ripe.net Onderwerp: [address-policy-wg] Internet Number Community IANA Stewardship Proposal: Final Call for Comments I believe this is also important to this group, as it sets the framework for future implementation of global policies. Please have a look at this proposal and please let us know if you support this. Hans Petter -------- Forwarded Message -------- Subject: [cooperation-wg] Fwd: [NRO-IANAXFER] Internet Number Community IANA Stewardship Proposal: Final Call for Comments Date: Thu, 8 Jan 2015 17:27:53 +0100 From: Nurani Nimpuno To: RIPE Cooperation Working Group Dear colleagues, Today the Consolidated RIR IANA Stewardship Proposal (CRISP) team publishes the second draft of the Internet numbers community proposal on the transition of the IANA stewardship. This is intended as a final call for community feedback ahead of the submitting the finalised proposal to the IANA Stewardship Transition Coordination Group (ICG) on Thursday, 15 January. We understand that many in the RIPE community have a strong interest in this process, and feedback provided in this working group and elsewhere has been crucial in reaching the current draft. While there is still an opportunity to provide comments on the current text, we would also like to strongly encourage RIPE community members in favour of this proposal to express their support on this list or via the ianaxfer at nro.net mailing list. A quantifiable level of community support may be important in strengthening the Internet numbers community?s position later in the IANA stewardship transition process. As previously, the timeline for responding is quite tight, with a deadline of Monday, 12 January, for all comments. Best regards, Nurani Nimpuno on behalf of the RIPE CRISP team Begin forwarded message: > From: Izumi Okutani > Subject: [NRO-IANAXFER] Internet Number Community IANA Stewardship Proposal: Final Call for Comments > Date: 8 januari 2015 17:21:08 CET > To: "ianaxfer at nro.net" > > Dear colleagues, > > > Please find the second draft of the Internet numbers community's > response to the Request For Proposals issued by the IANA Stewardship > Coordination Group (ICG). > > This draft has been prepared by the Consolidated RIR IANA Stewardship > Proposal (CRISP) Team, with considerations of feedback received from the > global community on mailing list. > > We have incorporated the following key points in the second draft: > > - Additional description on contract details, review committee and > intellectual property rights > - Description revised on Section V. NITA Requirements and VI. > Community Process for more clarity > - No changes are made to key elements of the proposal > > The CRISP Team have considered all comments expressed on > mailing list before the deadline of 5th Jan 2015, and > would now like to make the final call for comments from the global > community on the draft proposal, before submitting to the ICG. > > Second Draft proposal: > ------------------------ > Clean Version : > > > Redline Version: > > > The deadline for providing feedback: Mon, 12 January 2015 23:59 UTC > Feedback should be sent to : mailing list > > Community Inputs Considered by the CRISP Team: > ------------------------------------------ > You can check the status of the issues raised by the community and > proposed the CRISP Team positions at: > > > > Key dates: > ----------- > Second draft to be published : 8 Jan 2015 > Second draft comments close : 12 Jan 2015, 23:59 UTC > Final proposal to be sent to ICG : 15 Jan 2015 > > How to Engage in Discussions: > ----------------------------- > All global discussions, for the CRISP team to consider as community > feedback, will be conducted at mailing list. > All the CRISP Team discussions are open to observers. > > Next Step: > ----------- > In developing the final draft based on further feedback, the CRISP > Team will ensure it has completed considerations of all substantial > issues raised by the global community, which are compiled in the > published issues list. The proposal will only incorporate issues that > the CRISP team believes have received consensus support from the > community. > > References: > ------------ > * Discussions by the CRISP Team > Details of all the CRISP team's work to date, including recordings, > minutes and agendas of all the CRISP Team teleconferences and a > public archive of the internal CRISP team mailing list, are > available at: > https://nro.net/crisp-team > > * Other links: > - The ICG request for proposals: > > > - The IANA Stewardship Transition Discussion in each RIR region: > > > - First Draft proposal (Edited version) > > > > _______________________________________________ > ianaxfer mailing list > ianaxfer at nro.net > https://www.nro.net/mailman/listinfo/ianaxfer -------------- next part -------------- An HTML attachment was scrubbed... URL: From hph at oslo.net Fri Jan 9 15:41:45 2015 From: hph at oslo.net (Hans Petter Holen) Date: Fri, 09 Jan 2015 15:41:45 +0100 Subject: [address-policy-wg] Internet Number Community IANA Stewardship Proposal: Final Call for Comments In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C0115435E2D@E2010-MBX03.exchange2010.nl> References: <4B4EB6BB-CBA5-42FD-AD66-E1638093D83E@netnod.se> <54AEFE5B.5040002@oslo.net> <862A73D42343AE49B2FC3C32FDDFE91C0115435E2D@E2010-MBX03.exchange2010.nl> Message-ID: <54AFE8A9.8060604@oslo.net> Hi Erik, On 09.01.15 12.41, Erik Bais wrote: > There is a discussion mailing list for this > (https://www.nro.net/pipermail/ianaxfer/ ), is the idea to have > questions and discussion on that particular mailing list for those > that want to get a clear global reply on questions they might have ? If you send your comments directly to ianaxfer at nro.net you will get response directly from the CRISP team. That is clearly the most efficient way at this stage. > and the more RIPE RIR point discussion in coop-wg ? > You may also do that, and our crisp team members will have to pick it up. -- Hans Petter Holen Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue Jan 13 14:50:37 2015 From: gert at space.net (Gert Doering) Date: Tue, 13 Jan 2015 14:50:37 +0100 Subject: [address-policy-wg] 2014-04 - end of review phase In-Reply-To: References: Message-ID: <20150113135037.GA28837@Space.Net> Dear APWG, On Tue, Dec 09, 2014 at 04:20:30PM +0100, Marco Schmidt wrote: > The draft document for version 3.0 of the policy proposal 2014-04, > "Removing IPv6 Requirement for Receiving Space from the Final /8", > has now been published, along with an impact analysis conducted by > the RIPE NCC. [..] > We encourage you to read the draft document and send any comments > to address-policy-wg at ripe.net before 7 January 2015. 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. This is what I'll do now -> move 2014-04 to Last Call. Marco will send the formal announcement for that later today or tomorrow. 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 Dec 09, 2014 Support: Nick Hilliard Andre Keller Daniel Roesen Hamed Shafaghi Tore Anderson Daniel Stolpe Erik Bais Mike Burns George Giannousopoulos (as long as the NCC informs applicants about IPv6) Sebastian Wiesinger Opposing: Daniel Baeza Stefan Schiele (both on the basis that stronger encouragement for IPv6 is needed, and that the IPv4 "last /22" policy would be the right approach to doing it) Comment, not stating clear pro/con Peter Koch -- 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 Jan 13 15:46:56 2015 From: gert at space.net (Gert Doering) Date: Tue, 13 Jan 2015 15:46:56 +0100 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <54A57DB0.1010107@inex.ie> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> <20141225103945.GD40149@Vurt.local> <54A57DB0.1010107@inex.ie> Message-ID: <20150113144656.GY34798@Space.Net> Hi, On Thu, Jan 01, 2015 at 05:02:40PM +0000, Nick Hilliard wrote: > On 25/12/2014 10:39, Job Snijders wrote: > > So you are using a terrible amount of handwaving and overbreathing to > > suggest that we refrain from ASN Assignment policy changes until the AGM > > decides to start charging a yearly fee for ASNs again? > > > > What if such a yaerly fee is never introduced? > > As a more general issue, we need to accept as a community that there is a > crossover between RIPE Community policy and RIPE NCC membership policy, and > that this is one of those intersections. [..] > All things considered, there's not a major problem living with the current > policy formulation for another 12 months if that's what it takes to fix the > policy properly. So your suggestion would be to stall this proposal until we know what comes out of the next AGM, and then see if we need the clause in question at all, anymore? What if the AGM decides to bring back a yearly recurring charge for ASNs, we loosen up our policy, the AGM decides to remove the charge once again, and Nick No Hats decides to send in 4 billion ASN requests to the NCC (I recall that it was you initially who was worried about the potential for abuse here, so I'm slightly confused what to make out of this now)? Given that we only have indirect influence on the AGM decisions, I can see why the proposers wanted to have a safety net in the parts we get to control... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 Jan 13 16:54:02 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 13 Jan 2015 16:54:02 +0100 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20150113144656.GY34798@Space.Net> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> <20141225103945.GD40149@Vurt.local> <54A57DB0.1010107@inex.ie> <20150113144656.GY34798@Space.Net> Message-ID: <01dc01d02f49$2f487460$8dd95d20$@a2b-internet.com> Hi Gert, > So your suggestion would be to stall this proposal until we know what > comes out of the next AGM, and then see if we need the clause in question > at all, anymore? I would not recommend stalling the proposal based on what will be decided. My strong suggestion would be to move forward regardless. The current policy text provides a fix for possible abuse of requesting AS numbers. And if there will be a charge in the future for an AS number via the charging scheme, that number would be easy removed to replace it by the charge for the AS. > What if the AGM decides to bring back a yearly recurring charge for ASNs, > we loosen up our policy, the AGM decides to remove the charge once again, > and Nick No Hats decides to send in 4 billion ASN requests to the NCC > (I recall that it was you initially who was worried about the potential > for abuse here, so I'm slightly confused what to make out of this now)? Let's not try to fix every potential issue here I would say. We can always address that if we see someone sign-up as Mr. No Hats at a RIPE meeting and take him aside ... cluebats are great for providing some insight into a specific direction .. ;-) > Given that we only have indirect influence on the AGM decisions, I can > see why the proposers wanted to have a safety net in the parts we get > to control... The proposers didn't wanted this safety net if I recall initially .. that came to the discussion after someone decided he wanted to request the complete number pool ... And he didn't even wanted to do so.. he just played with the idea that it would be possible ... This complete theoretic possible abuse for this specific policy has been entertained long enough I would say .. time to move forward. Regards, Erik Bais From nick at inex.ie Tue Jan 13 16:57:07 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 13 Jan 2015 15:57:07 +0000 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20150113144656.GY34798@Space.Net> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> <20141225103945.GD40149@Vurt.local> <54A57DB0.1010107@inex.ie> <20150113144656.GY34798@Space.Net> Message-ID: <54B54053.6040501@inex.ie> On 13/01/2015 14:46, Gert Doering wrote: > So your suggestion would be to stall this proposal until we know what > comes out of the next AGM, and then see if we need the clause in > question at all, anymore? yes, that was my suggestion. The current configuration is stable, so there are no pressing operational reasons to change things in a hurry. If we're going to change, we need to do that's best for N years down the road, not what's best for a couple of months during 2015. > What if the AGM decides to bring back a yearly recurring charge for > ASNs, we loosen up our policy, the AGM decides to remove the charge once > again, from previous email: >> As a more general issue, we need to accept as a community that there >> is a crossover between RIPE Community policy and RIPE NCC membership >> policy, and that this is one of those intersections. Both the RIPE NCC membership and the AP working group tend to end up with reasonable policies. I'm pretty confident that this isn't going to change any time soon. Nick From elvis at v4escrow.net Tue Jan 13 18:23:09 2015 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Tue, 13 Jan 2015 18:23:09 +0100 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <54B54053.6040501@inex.ie> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> <20141225103945.GD40149@Vurt.local> <54A57DB0.1010107@inex.ie> <20150113144656.GY34798@Space.Net> <54B54053.6040501@inex.ie> Message-ID: <54B5547D.9030400@v4escrow.net> Hi Nick, On 13/01/15 16:57, Nick Hilliard wrote: > On 13/01/2015 14:46, Gert Doering wrote: >> So your suggestion would be to stall this proposal until we know what >> comes out of the next AGM, and then see if we need the clause in >> question at all, anymore? > yes, that was my suggestion. The current configuration is stable, so there > are no pressing operational reasons to change things in a hurry. If we're > going to change, we need to do that's best for N years down the road, not > what's best for a couple of months during 2015. I do not think it is a good idea to stall a policy proposal in order to see if the Board/AGM decides to take into consideration or ignore in the future your presentation/proposal from the previous AGM. I think your suggestion sets a very dangerous precedent where a policy proposal would be stalled pending a decision that may or not be taken at the next AGM. Regarding the current configuration, well.. it requires the requester of the ASN to come up with a reason that can not be verified by the RIPE NCC and with a predicted set of peers that may or not peer with the assigned ASN. For example, see the e-mail sent to the members-discuss mailing list yesterday by Shahin Gharghi; the current policy requires the requester to list the two ASNs they will peer with, what if some companies can not peer with two ASNs because of local regulations. Do you think that company should not receive the ASN they need? Also, from your e-mail I understand that you are sure the AGM will vote within 'a couple of months' to charge for ASNs. Do you know something that I don't? :) >> What if the AGM decides to bring back a yearly recurring charge for >> ASNs, we loosen up our policy, the AGM decides to remove the charge once >> again, > from previous email: > >>> As a more general issue, we need to accept as a community that there >>> is a crossover between RIPE Community policy and RIPE NCC membership >>> policy, and that this is one of those intersections. > Both the RIPE NCC membership and the AP working group tend to end up with > reasonable policies. I'm pretty confident that this isn't going to change > any time soon. It has already changed from a year to the other and that is why I did not like the proposal you made at the previous AGM. We need to have a charging scheme that is predictable and will not change from a year to the other. I think that if this policy proposal becomes policy and too many companies start requesting 1000 ASNs, the AGM can react and start charging (either from the first, the second or the 100th ASN) based on numbers that the RIPE NCC will provide. I do not like the idea that a policy proposal can be stalled because someone can imagine a way the proposal/policy could be abused. If it does get abused, we react on that and not on predictions. > Nick > > 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 nick at inex.ie Tue Jan 13 18:56:25 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 13 Jan 2015 17:56:25 +0000 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <54B5547D.9030400@v4escrow.net> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> <20141225103945.GD40149@Vurt.local> <54A57DB0.1010107@inex.ie> <20150113144656.GY34798@Space.Net> <54B54053.6040501@inex.ie> <54B5547D.9030400@v4escrow.net> Message-ID: <54B55C49.4040809@inex.ie> On 13/01/2015 17:23, Elvis Daniel Velea wrote: > Regarding the current configuration, well.. it requires the requester of > the ASN to come up with a reason that can not be verified by the RIPE NCC > and with a predicted set of peers that may or not peer with the assigned ASN. Elvis, you probably know the documentation much better than I do, but the formal requirement for multihoming has been in place since at least RIPE-140, dating from 1996. RIPE-140 refers to existing assignment practices and from what I remember of before that date, there was an informal expectation of multihoming for ASN assignment from the very early days of the Internet, even if it wasn't formally documented. As a community, we managed to arrive at a practical workaround, namely that you can apply for an ASN if you have a plan to multihome and can state a name for a potential peering partner. We all quietly acknowledge that it might not match the spirit of the policy, but it works and has worked for as long as the RIPE NCC has existed. It needs to work because often an organisation needs an ASN even when they're not yet ready to multihome. Again, let me be clear where I'm coming from: if we are going to change a policy which has been in existence for more than 19 years, let's change it to what we want for the next 19, rather than put in place a temporary stopgap with the aim of plugging a leak. If this means being patient for another couple of months until RIPE71, then that's fine by me. > Also, from your e-mail I understand that you are sure the AGM will vote > within 'a couple of months' to charge for ASNs. Do you know something that > I don't? :) Then you misread my email: I have no more information than anyone else about how people might vote. Nick From apwg at c4inet.net Tue Jan 13 19:48:36 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 13 Jan 2015 18:48:36 +0000 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <54B55C49.4040809@inex.ie> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> <20141225103945.GD40149@Vurt.local> <54A57DB0.1010107@inex.ie> <20150113144656.GY34798@Space.Net> <54B54053.6040501@inex.ie> <54B5547D.9030400@v4escrow.net> <54B55C49.4040809@inex.ie> Message-ID: <20150113184836.GA1012@cilantro.c4inet.net> On Tue, Jan 13, 2015 at 05:56:25PM +0000, Nick Hilliard wrote: >As a community, we managed to arrive at a practical workaround, namely that >you can apply for an ASN if you have a plan to multihome and can state a >name for a potential peering partner. >We all quietly acknowledge that it might not match the spirit of the >policy, but it works and has worked for as long as the RIPE NCC has >existed. > It needs to work because often an organisation needs an ASN even >when they're not yet ready to multihome. So, you admit that the policy, as it stands, is ineffective and is honoured in breach more than in observance. The proposed policy does not much more than put in writing the current practice anyway. >to what we want for the next 19, rather than put in place a temporary >stopgap with the aim of plugging a leak. If this means being patient for >another couple of months until RIPE71, then that's fine by me. I'm not in favour of making policy at the meetings, not least because I rarely have the opportunity to attend and I consider this an attempt at disenfranchisement. Remember 2007-01! >Then you misread my email: I have no more information than anyone else >about how people might vote. Well I will vote against charging for ASNs, for one. Charging for something one effectively *needs* to operate smells of Ryanair-ish practice to me. What is your plan in case the members vote against this charge? rgds, Sascha Luck From apwg at c4inet.net Tue Jan 13 20:03:23 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 13 Jan 2015 19:03:23 +0000 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> Message-ID: <20150113190323.GB1012@cilantro.c4inet.net> On Thu, Dec 25, 2014 at 01:10:41PM +0100, Erik Bais - A2B Internet wrote: >There has been 2 suggestions to this scary (automation) AS request that Nick might use when the policy comes into place ... Pay per AS or limit the number of AS'n per organisation. Another possibility would be that n ASN can be assigned to an Organisation without proving any need and any further assignments have to prove need. How much n should be is open to debate of course. This should be more flexible than a fixed limit (who knows, maybe there's an operator that needs >1000 ASN), it also addresses the possibility of the AGM de-fanging a "charging" implementation without the need to go back and make a new policy. rgds, Sascha Luck From gert at space.net Tue Jan 13 21:51:01 2015 From: gert at space.net (Gert Doering) Date: Tue, 13 Jan 2015 21:51:01 +0100 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <54B5547D.9030400@v4escrow.net> References: <549AE73C.9040800@inex.ie> <20141224181427.GT34798@Space.Net> <549B2D9E.4020905@inex.ie> <20141225103945.GD40149@Vurt.local> <54A57DB0.1010107@inex.ie> <20150113144656.GY34798@Space.Net> <54B54053.6040501@inex.ie> <54B5547D.9030400@v4escrow.net> Message-ID: <20150113205101.GD34798@Space.Net> Hi, On Tue, Jan 13, 2015 at 06:23:09PM +0100, Elvis Daniel Velea wrote: > I do not think it is a good idea to stall a policy proposal in order to > see if the Board/AGM decides to take into consideration or ignore in the > future your presentation/proposal from the previous AGM. > I think your suggestion sets a very dangerous precedent where a policy > proposal would be stalled pending a decision that may or not be taken at > the next AGM. I think the wording "dangerous precedent" is a bit too strong here - we did that in the past (stall a proposal until something else was decided), and as long as the proposer and WG chair agree on the course, there is nothing wrong here... after all, the proposer can withdraw at any time as well :) . [..] > For example, see the e-mail sent to the members-discuss mailing list > yesterday by Shahin Gharghi; the current policy requires the requester > to list the two ASNs they will peer with, what if some companies can not > peer with two ASNs because of local regulations. Do you think that > company should not receive the ASN they need? One could argue indeed that if you have only a single BGP upstream, an AS number is not strictly needed. But of course this is one of the reasons the proposers had to bring this up - private ASNs or announcing from the upstream's ASN will not always get the job done either. > Also, from your e-mail I understand that you are sure the AGM will vote > within 'a couple of months' to charge for ASNs. Do you know something > that I don't? :) Well, Nick and I brought it up at the last AGM, and we made sure the board was awake and listening :-) - so we'll see what happens at the next AGM. [..] > I do not like the idea that a > policy proposal can be stalled because someone can imagine a way the > proposal/policy could be abused. If it does get abused, we react on that > and not on predictions. Actually we *do* try to make policy in a way that we don't have to scramble to fix the ways it can be abused right afterwards :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 Jan 14 10:28:35 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 14 Jan 2015 10:28:35 +0100 Subject: [address-policy-wg] 2014-04 Last Call for Comments (Removing IPv6 Requirement for Receiving Space from the Final /8) Message-ID: Dear colleagues, The proposal described in 2014-04, Removing IPv6 Requirement for Receiving Space from the Final /8, 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 before 12 February 2015 and must be supported by an explanation. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-04 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net. Regards, Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Fri Jan 16 14:49:34 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 16 Jan 2015 14:49:34 +0100 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) Message-ID: Dear colleagues, The draft documents for version 3.0 of the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources", have now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 2.0 include: - Introduction of needs justification for transfers from RIR regions that require need-based policies - Explicit statement about when RIPE policies apply during a transfer - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-05 The draft documents are available at: https://www.ripe.net/ripe/policies/proposals/2014-05/draft We encourage you to read the draft document text and send any comments to before 16 February 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From ripe-ml-2012 at ssd.axu.tm Mon Jan 19 03:28:29 2015 From: ripe-ml-2012 at ssd.axu.tm (Aleksi Suhonen) Date: Mon, 19 Jan 2015 04:28:29 +0200 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> Message-ID: <54BC6BCD.1000703@ssd.axu.tm> Hi, There was a small ruckus on this mailing list about the 1000 ASN limit during the holidays. The whole disagreement is centred around the fact that ASNs are free now. I've read a lot of messages that seem to suggest that there should be some charge related to them that prevents amassing them in the billions. I sort of agree with that, but... Is there someone in this community that feels they should be completely free, no matter how many you have? I'd like to offer some more food for thought. These are not realistic suggestions, but I hope they will close the gap between the two debating sides: How many ASNs can a LIR get using one email or one click on the RIPE portal? My understanding is that even after 2014-03 is implemented, the answer will be one(1). After that email/click, the LIR will go through the Process. I don't think any amount of policy simplification will reduce the work required per Process Instance at both the LIR and the RIR below two minutes. In the crypto(slash)security community this is called the proof-of-work system. So, for a thousand ASNs this would mean about 33 hours. As we want to turn that into money, working at ten Euros per hour the cost would be 330 Euros. You can twist the numbers every which way, but it's hard to twist them so far that the result would be much smaller than Nick's example of setting up another company for 10 Euros (+work.) If we want to make sure that a LIR doesn't automate their email responses to the Process, we can include another random proof-of-work such as "what is the sum of the digits in today's date?", "how much is this ticket number divided by the number of ASNs you already have?" or "when do the cows come home to roost?" Or just a plain old CAPTCHA. Someone suggested that if the ASNs were free and someone got four billion of them, we can fix that post-fact by raising the ASN fee above zero. The same person, in the same sentence, also hinted that this special someone would be based at some tax haven sort of place, where exacting this fee won't really be possible, should the someone refuse to pay the new fee. The resulting reclamation process would leave us without ASNs for a couple of years. Then again, according to my above thesis of ASN acquisition speed, it would take thousands of years for the bad guy to finish all the Processes to get all the ASNs in the first place. There, a couple of cents worth... -- Aleksi Suhonen / Let bogons be bogons. From stolpe at resilans.se Mon Jan 19 09:49:23 2015 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 19 Jan 2015 09:49:23 +0100 (CET) Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <54BC6BCD.1000703@ssd.axu.tm> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> Message-ID: Hi Aleksi, That one strikes me as well. I don't know how often people arguing about ASN stockpiling really apply for ASN's but my experience is that it takes quite a lot of explanation even to get a second ASN for the same entity. But maybe I am missing something here and the "non multihoming" rule means the NCC will not check anything at all in the future and just give away ASN's to anyone asking for them, no matter how many? On Mon, 19 Jan 2015, Aleksi Suhonen wrote: > Hi, > > There was a small ruckus on this mailing list about the 1000 ASN limit during > the holidays. The whole disagreement is centred around the fact that ASNs are > free now. I've read a lot of messages that seem to suggest that there should > be some charge related to them that prevents amassing them in the billions. I > sort of agree with that, but... > > Is there someone in this community that feels they should be completely free, > no matter how many you have? > > I'd like to offer some more food for thought. These are not realistic > suggestions, but I hope they will close the gap between the two debating > sides: > > How many ASNs can a LIR get using one email or one click on the RIPE portal? > My understanding is that even after 2014-03 is implemented, the answer will > be one(1). > > After that email/click, the LIR will go through the Process. I don't think > any amount of policy simplification will reduce the work required per Process > Instance at both the LIR and the RIR below two minutes. > In the crypto(slash)security community this is called the proof-of-work > system. > > So, for a thousand ASNs this would mean about 33 hours. As we want to turn > that into money, working at ten Euros per hour the cost would be 330 Euros. > You can twist the numbers every which way, but it's hard to twist them so far > that the result would be much smaller than Nick's example of setting up > another company for 10 Euros (+work.) > > If we want to make sure that a LIR doesn't automate their email responses to > the Process, we can include another random proof-of-work such as "what is the > sum of the digits in today's date?", "how much is this ticket number divided > by the number of ASNs you already have?" or "when do the cows come home to > roost?" Or just a plain old CAPTCHA. > > Someone suggested that if the ASNs were free and someone got four billion of > them, we can fix that post-fact by raising the ASN fee above zero. The same > person, in the same sentence, also hinted that this special someone would be > based at some tax haven sort of place, where exacting this fee won't really > be possible, should the someone refuse to pay the new fee. > > The resulting reclamation process would leave us without ASNs for a couple of > years. Then again, according to my above thesis of ASN acquisition speed, it > would take thousands of years for the bad guy to finish all the Processes to > get all the ASNs in the first place. > > There, a couple of cents worth... > > -- > Aleksi Suhonen / Let bogons be bogons. > > > Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From mstafyla at ripe.net Mon Jan 19 11:59:43 2015 From: mstafyla at ripe.net (Maria Stafyla) Date: Mon, 19 Jan 2015 11:59:43 +0100 Subject: [address-policy-wg] Internet Number Resources Approved to the RIPE NCC Message-ID: <019C2929-CB12-422F-8461-A0B837784998@ripe.net> Dear Colleagues, The RIPE NCC Arbiters Panel has approved a request for an IPv6 PI assignment and an Autonomous System Number (ASN) resource to the RIPE NCC for its resiliency node in Stockholm based on the RIPE Document, "Allocating/Assigning Resources to the RIPE NCC", and the RIPE NCC procedural document, ?RIPE NCC Conflict Arbitration Procedure?. You can find the full announcement at: https://www.ripe.net/internet-coordination/news/about-ripe-ncc-and-ripe/internet-number-resources-approved-to-the-ripe-ncc-1 If you have any questions, please send an email to feedback at ripe.net Kind regards, Maria Stafyla The secretary of the Arbiters Panel of the RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Mon Jan 19 22:32:50 2015 From: nick at inex.ie (Nick Hilliard) Date: Mon, 19 Jan 2015 21:32:50 +0000 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <54BC6BCD.1000703@ssd.axu.tm> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> Message-ID: <54BD7802.7020006@inex.ie> On 19/01/2015 02:28, Aleksi Suhonen wrote: > Is there someone in this community that feels they should be completely > free, no matter how many you have? we all want a free lunch. > I'd like to offer some more food for thought. These are not realistic > suggestions, but I hope they will close the gap between the two debating > sides: > > How many ASNs can a LIR get using one email or one click on the RIPE > portal? My understanding is that even after 2014-03 is implemented, the > answer will be one(1). (End Users, not just LIRs.) > After that email/click, the LIR will go through the Process. I don't think > any amount of policy simplification will reduce the work required per > Process Instance at both the LIR and the RIR below two minutes. > In the crypto(slash)security community this is called the proof-of-work > system. [example deleted] this certainly creates work for the applicant, possibly enough to slow down the process of ASN acquisition. It also creates work for the RIPE NCC and someone needs to pay the RIPE NCC bills both to develop and to operate the system. This cost will be borne by the LIRs and as a LIR, I'm not much keen on funding this sort of thing. Also the proposal doesn't include any sort of garbage collection mechanism. In a situation where we face short-term depletion of the resource, this is important. Nick From sander at steffann.nl Mon Jan 19 22:42:49 2015 From: sander at steffann.nl (Sander Steffann) Date: Mon, 19 Jan 2015 13:42:49 -0800 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> Message-ID: Hi Daniel, > That one strikes me as well. I don't know how often people arguing about ASN stockpiling really apply for ASN's but my experience is that it takes quite a lot of explanation even to get a second ASN for the same entity. > > But maybe I am missing something here and the "non multihoming" rule means the NCC will not check anything at all in the future and just give away ASN's to anyone asking for them, no matter how many? That is the basic idea: ask for another ASN and you'll get one. Then some participants on this mailing list were worried that someone might request the whole pool. That caused a new version of the proposal to be written with some limits in them. Those limits were chosen in such a way that even the organisation with the largest number of ASNs could request 10x as much as they currently have and still fit in the policy. It is however a 'magic' number. That caused some objections because the policy is now not as clean and simple anymore. So now this working group needs to decide in which direction to move: a very simple and clean policy that is 'ask and you will get', or a policy that places arbitrary limits just in case someone might try to abuse the policy. Or some other form of rate-limiting? If the RIPE NCC started charging for ASNs again then that would be a limiter and a reclaim mechanism. The policy could certainly remain a lot cleaner in that case. Or, just thinking out loud: we could allow the NCC to limit the number of resource requests they accept per week from the same organisation or something like that. With exponential back-off? ;) As a working group we need to decide a few things: - do we want to make it easy to get ASNs? (the answer seems to be "yes") - do we want to place a limit? - do we want a time-based or absolute limit? - do we wait for the next RIPE NCC charging scheme to see if that solves our problems? Cheers, Sander Steffann APWG co-chair From nick at inex.ie Mon Jan 19 22:45:30 2015 From: nick at inex.ie (Nick Hilliard) Date: Mon, 19 Jan 2015 21:45:30 +0000 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> Message-ID: <54BD7AFA.3000103@inex.ie> On 19/01/2015 21:42, Sander Steffann wrote: > As a working group we need to decide a few things: > - do we want to make it easy to get ASNs? (the answer seems to be "yes") > - do we want to place a limit? > - do we want a time-based or absolute limit? > - do we wait for the next RIPE NCC charging scheme to see if that solves our problems? and: - do we want to implement garbage collection for unused assignments. Nick From sander at steffann.nl Mon Jan 19 22:45:58 2015 From: sander at steffann.nl (Sander Steffann) Date: Mon, 19 Jan 2015 13:45:58 -0800 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <54BD7802.7020006@inex.ie> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> <54BD7802.7020006@inex.ie> Message-ID: Hi Nick, > Also the proposal doesn't include any sort of garbage collection mechanism. > In a situation where we face short-term depletion of the resource, this is > important. 2007-01 was supposed to solve that, but its intentions as a reclaim/return incentive are not being implemented for ASNs at the moment. Let's see how the board and the members react to your statement at the last AGM. I'm not sure we should create another garbage collection mechanism. I would prefer the NCC to implement the existing one :) Cheers, Sander From sander at steffann.nl Mon Jan 19 23:01:50 2015 From: sander at steffann.nl (Sander Steffann) Date: Mon, 19 Jan 2015 14:01:50 -0800 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <54BD7AFA.3000103@inex.ie> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> <54BD7AFA.3000103@inex.ie> Message-ID: <7DA6673A-5396-4A77-9034-2A365FBC4E36@steffann.nl> Hi Nick, > Op 19 jan. 2015 om 13:45 heeft Nick Hilliard het volgende geschreven: > >> On 19/01/2015 21:42, Sander Steffann wrote: >> As a working group we need to decide a few things: >> - do we want to make it easy to get ASNs? (the answer seems to be "yes") >> - do we want to place a limit? >> - do we want a time-based or absolute limit? >> - do we wait for the next RIPE NCC charging scheme to see if that solves our problems? > > and: > > - do we want to implement garbage collection for unused assignments. Indeed! Sander From apwg at c4inet.net Tue Jan 20 00:59:51 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 19 Jan 2015 23:59:51 +0000 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> <54BD7802.7020006@inex.ie> Message-ID: <20150119235951.GC1012@cilantro.c4inet.net> On Mon, Jan 19, 2015 at 01:45:58PM -0800, Sander Steffann wrote: >I'm not sure we should create another garbage collection >mechanism. I would prefer the NCC to implement the [2007-01] one No thanks. The same heap of bureaucratic bullshit that is required to get PI space just to get an *ASN*? Not to mention the lulz that will result when a LIR applies for an ASN and the NCC refuses the request because the same entity can't be on both sides of the contract... Garbage collection can be more easily implemented, just request (annual?) confirmation the resource is still required, if the answer is negative, or there is none, reclaim it. (This could even be extended to PIv6) Also, what did I miss? When did ASNs become such a scarce resource that drastic rationing is required? rgds, Sascha Luck From apwg at c4inet.net Tue Jan 20 01:07:55 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 20 Jan 2015 00:07:55 +0000 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> Message-ID: <20150120000755.GD1012@cilantro.c4inet.net> On Mon, Jan 19, 2015 at 01:42:49PM -0800, Sander Steffann wrote: >As a working group we need to decide a few things: >- do we want to make it easy to get ASNs? (the answer seems to be "yes") Yes, please. >- do we want to place a limit? Probably a good idea. >- do we want a time-based or absolute limit? A time-based limit has merit, actually. It avoids the "magic number" issue and will certainly prevent a "smash-and-grab" scenario. >- do we wait for the next RIPE NCC charging scheme to see if >that solves our problems? I'm not in favour of this. What I want to see is that the membership fee covers all my dealings with the NCC. In small companies, you often have to get budgetary approval for even EUR50, and I'm in *no* mood to explain to a bean-counter (or the boss's wife) what an ASN is and why I need 50 quid to pay for another one. rgds, Sascha Luck >Cheers, Sander Steffann APWG co-chair > > From apwg at c4inet.net Tue Jan 20 01:17:08 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 20 Jan 2015 00:17:08 +0000 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <54BD7802.7020006@inex.ie> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> <54BD7802.7020006@inex.ie> Message-ID: <20150120001708.GE1012@cilantro.c4inet.net> On Mon, Jan 19, 2015 at 09:32:50PM +0000, Nick Hilliard wrote: >we all want a free lunch. TANSTAAFL. But *nobody* wants Ryanair, where you pay and then pay again. And again. And again. >this certainly creates work for the applicant, possibly enough >to slow down the process of ASN acquisition. It also creates >work for the RIPE NCC and someone needs to pay the RIPE NCC I'm sure this scenario is not beyond the limits of automation. One ASN per LIR, then block any more requests for 24h (or whatever). Any of the NCC software bods want to comment on how hard this could possible be? rgds, Sascha Luck From tore at fud.no Tue Jan 20 07:31:46 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 20 Jan 2015 07:31:46 +0100 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: Message-ID: <20150120073146.35eda6b8@echo.ms.redpill-linpro.com> * "Marco Schmidt" > The draft documents for version 3.0 of the policy proposal 2014-05, > "Policy for Inter-RIR Transfers of Internet Resources", have now been > published, along with an impact analysis conducted by the RIPE NCC. Looks fine to me. It's about time we get this one out the door. +1 [I do have some editorial gripes, but I'll let those slide for now, as there's a unified resource transfer policy proposal on the horizon that will hopefully clean up those as well.] Tore From tore at fud.no Tue Jan 20 07:51:13 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 20 Jan 2015 07:51:13 +0100 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> Message-ID: <20150120075113.104959d1@echo.ms.redpill-linpro.com> * Sander Steffann > As a working group we need to decide a few things: > - do we want to make it easy to get ASNs? (the answer seems to be "yes") Yep. I'm not opposed to saying that the applicant must have *some* form of technical need for it. Multihoming would be one valid requirement, but it shouldn't be the only qualifying technical need. I liked the first version of the proposal... > - do we want to place a limit? I agree that it's not ideal. > - do we wait for the next RIPE NCC charging scheme to see if that > solves our problems? Do we have any idea if the board will propose an ASN charge at the Spring GM? (Hi Nigel!) I think waiting would make sense if we know that an ASN charge is in the works. Tore From tore at fud.no Tue Jan 20 08:00:10 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 20 Jan 2015 08:00:10 +0100 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <20150120000755.GD1012@cilantro.c4inet.net> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> <20150120000755.GD1012@cilantro.c4inet.net> Message-ID: <20150120080010.7e12eee3@echo.ms.redpill-linpro.com> * "Sascha Luck [ml]" > On Mon, Jan 19, 2015 at 01:42:49PM -0800, Sander Steffann wrote: > > >- do we wait for the next RIPE NCC charging scheme to see if > >that solves our problems? > > I'm not in favour of this. What I want to see is that the > membership fee covers all my dealings with the NCC. In small > companies, you often have to get budgetary approval for even > EUR50, and I'm in *no* mood to explain to a bean-counter (or the > boss's wife) what an ASN is and why I need 50 quid to pay for > another one. Hi Sascha, Would an ASN charge be more palatable to you if the membership fee included a quota of 1 (or N) gratis ASNs? Or perhaps that the already existing IPv4/IPv6 PI charge would include 1 gratis ASN per resource? I'm thinking that as long as N is a quite modest number, this does not cause any real abuse potential and at the same time it would make it more likely that the membership would agree to having an ASN fee put in place - as the vast majority of us won't actually have to pay anything more than we do today. (I'm well aware that this is outside of APWG's jurisdiction though. Just thinking out loud, perhaps some board members are listening...) Tore From tore at fud.no Tue Jan 20 08:08:49 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 20 Jan 2015 08:08:49 +0100 Subject: [address-policy-wg] 2014-12 Draft Document and Impact Analysis Published (Allow IPv6 Transfers) In-Reply-To: References: Message-ID: <20150120080849.74c040f8@echo.ms.redpill-linpro.com> * "Marco Schmidt" > The proposal described in 2014-12, "Allow IPv6 Transfers", is now in > its Review Phase. The need for IPv6 tranfers are probably going to be miniscule as IPv6 numbers are readily available from the NCC, but nevertheless I think it makes sense to harmonise the transfer policies for all the different resource types we have. In some corner cases a transfer could prevent the need to renumber (parts of) a network though. It's worth having this just to support folks in that position. +1 Tore From randy at psg.com Tue Jan 20 08:29:57 2015 From: randy at psg.com (Randy Bush) Date: Tue, 20 Jan 2015 16:29:57 +0900 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> Message-ID: > - do we want to make it easy to get ASNs? (the answer seems to be > "yes") well, easy to get an ASN, and hard to get 42 > - do we want to place a limit? that is one means of damping > - do we want a time-based or absolute limit? or both > - do we wait for the next RIPE NCC charging scheme to see if that > solves our problems? think for a minute what price would have a damping affect while not being a pita to marjorie who just wants an asn to get her job done. there may not be a good price point that accomplishes both. randy From tore at fud.no Tue Jan 20 09:03:34 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 20 Jan 2015 09:03:34 +0100 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: References: Message-ID: <20150120090334.235037ec@echo.ms.redpill-linpro.com> * "Hannigan, Martin" > Agreed on the policy. I support its continued move forward. +1 Tore From stolpe at resilans.se Tue Jan 20 10:02:39 2015 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 20 Jan 2015 10:02:39 +0100 (CET) Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <20150120075113.104959d1@echo.ms.redpill-linpro.com> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> <20150120075113.104959d1@echo.ms.redpill-linpro.com> Message-ID: On Tue, 20 Jan 2015, Tore Anderson wrote: > * Sander Steffann > >> As a working group we need to decide a few things: >> - do we want to make it easy to get ASNs? (the answer seems to be "yes") > > Yep. I'm not opposed to saying that the applicant must have *some* form > of technical need for it. Multihoming would be one valid requirement, > but it shouldn't be the only qualifying technical need. Yes, that is where I thought we were. I was aware of the proposal to remove the multihoming as an absolute demand but I thought there would still be some kind of needs based delegation. > I liked the first version of the proposal... Maybe I have some reading to catch up with. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From job at instituut.net Tue Jan 20 10:04:29 2015 From: job at instituut.net (Job Snijders) Date: Tue, 20 Jan 2015 10:04:29 +0100 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> Message-ID: <20150120090429.GT1090@Vurt.local> On Tue, Jan 20, 2015 at 04:29:57PM +0900, Randy Bush wrote: > > - do we wait for the next RIPE NCC charging scheme to see if that > > solves our problems? > > think for a minute what price would have a damping affect while not > being a pita to marjorie who just wants an asn to get her job done. > there may not be a good price point that accomplishes both. 1 euro per year per ASN would already have a strong dampening effect From elvis at velea.eu Tue Jan 20 10:04:57 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Tue, 20 Jan 2015 10:04:57 +0100 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <54BD7802.7020006@inex.ie> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> <54BD7802.7020006@inex.ie> Message-ID: <54BE1A39.7080602@velea.eu> Hi, On 19/01/15 22:32, Nick Hilliard wrote: [...] > It also creates work for the RIPE NCC and > someone needs to pay the RIPE NCC bills both to develop and to operate the > system. This cost will be borne by the LIRs and as a LIR, I'm not much > keen on funding this sort of thing. Are you sure this battle of yours is not so that you can go on one-week free trips to Bali paid by the LIRs? (like the IGF a couple of years ago) I am asking this rude question because, I do not see why you come back with the argument that LIRs should not fund the NCC for assigning free ASNs. The members during the AGM have already decided to remove the 50E fee for ASNs a couple of years ago and you fight with all your strength to put it back on. Also, since we are talking about costs per LIRs, have you not noticed that the price an LIR has been paying has continuously decreased, almost every year? And this has been happening while the RIPE NCC budget has increased every year.. > Also the proposal doesn't include any sort of garbage collection mechanism. > In a situation where we face short-term depletion of the resource, this is > important. There are 32bit ASNs available with the billions.. which short-term depletion are you referring to? The 16bit ASNs have, already, an exception in the proposed policy text "When requesting a 16-bit AS Number, the network must be multihomed within nine months of the assignment. Failure to multihome within this timeframe will result in deregistration of the assignment." As for the garbage collection, the 50E/assignment will not fix the problem (in most of the cases) because most of the LIRs just pay without bothering to check whether the customer still needs the resource or may want to return it. Maybe the RIPE NCC can actually implement a method where it actually asks the customer or the LIR to confirm (by ticking a box ?) the resource is still needed, on a yearly basis. > Nick > > /Elvis From ggiannou at gmail.com Tue Jan 20 10:05:19 2015 From: ggiannou at gmail.com (George Giannousopoulos) Date: Tue, 20 Jan 2015 11:05:19 +0200 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: <20150120090334.235037ec@echo.ms.redpill-linpro.com> References: <20150120090334.235037ec@echo.ms.redpill-linpro.com> Message-ID: support. Regards, George On Tue, Jan 20, 2015 at 10:03 AM, Tore Anderson wrote: > * "Hannigan, Martin" > > > Agreed on the policy. I support its continued move forward. > > +1 > > Tore > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stolpe at resilans.se Tue Jan 20 10:06:01 2015 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 20 Jan 2015 10:06:01 +0100 (CET) Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> Message-ID: On Tue, 20 Jan 2015, Randy Bush wrote: >> - do we want to make it easy to get ASNs? (the answer seems to be >> "yes") > > well, easy to get an ASN, and hard to get 42 I agree, as long as we talk about end-users here, rather than LIR's. We help quite a few end users to get ANS's and sometimes more than one in the same day. There are no problems today as long as you ask for one (1) ASN per end-user. So while I support the idea that some entities that do not qualify today because of the multihoming demand, I would not like to have more trouble receiving new ASN's for those who get them rather easily today. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From d.baeza at tvt-datos.es Tue Jan 20 10:07:41 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Tue, 20 Jan 2015 10:07:41 +0100 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: References: <20150120090334.235037ec@echo.ms.redpill-linpro.com> Message-ID: <54BE1ADD.40500@tvt-datos.es> support El 20/01/2015 a las 10:05, George Giannousopoulos escribi?: > support. > > Regards, > George > > On Tue, Jan 20, 2015 at 10:03 AM, Tore Anderson > wrote: > > * "Hannigan, Martin" > > > > Agreed on the policy. I support its continued move forward. > > +1 > > Tore > > -- Daniel Baeza Centro de Observaci?n de Red Dpto. Red y Sistemas Television Costa Blanca S.L. Telf. 966.190.847 | Fax. 965.074.390 http://www.tvt.es | http://www.tvt-datos.es Correo: d.baeza at tvt-datos.es -- [Atenci?n] La informaci?n contenida en este e-mail es confidencial, privilegiada y est? dirigida exclusivamente a su destinatario. Cualquier revisi?n, difusi?n, distribuci?n o copiado de este mensaje sin autorizaci?n del propietario est? prohibido. Si ha recibido este e-mail por error por favor b?rrelo y env?e un mensaje al remitente. [Disclaimer] The information contained in this e-mail is privileged and confidential and is intended only for its addressee. Any review, dissemination, distribution or copying of this e-mail is prohibited. If you have received it in error please delete the original message and e-mail us. (!) El medio ambiente es responsabilidad de todos. Imprime este mail si es absolutamente necesario. From elvis at velea.eu Tue Jan 20 10:21:39 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Tue, 20 Jan 2015 10:21:39 +0100 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <20150120073146.35eda6b8@echo.ms.redpill-linpro.com> References: <20150120073146.35eda6b8@echo.ms.redpill-linpro.com> Message-ID: <54BE1E23.6050004@velea.eu> On 20/01/15 07:31, Tore Anderson wrote: > * "Marco Schmidt" > >> The draft documents for version 3.0 of the policy proposal 2014-05, >> "Policy for Inter-RIR Transfers of Internet Resources", have now been >> published, along with an impact analysis conducted by the RIPE NCC. > Looks fine to me. It's about time we get this one out the door. +1 +1 /elvis > > [I do have some editorial gripes, but I'll let those slide for now, as > there's a unified resource transfer policy proposal on the horizon that > will hopefully clean up those as well.] > > Tore > From elvis at velea.eu Tue Jan 20 10:22:30 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Tue, 20 Jan 2015 10:22:30 +0100 Subject: [address-policy-wg] 2014-12 Draft Document and Impact Analysis Published (Allow IPv6 Transfers) In-Reply-To: <20150120080849.74c040f8@echo.ms.redpill-linpro.com> References: <20150120080849.74c040f8@echo.ms.redpill-linpro.com> Message-ID: <54BE1E56.5090606@velea.eu> On 20/01/15 08:08, Tore Anderson wrote: > * "Marco Schmidt" > >> The proposal described in 2014-12, "Allow IPv6 Transfers", is now in >> its Review Phase. > The need for IPv6 tranfers are probably going to be miniscule as IPv6 > numbers are readily available from the NCC, but nevertheless I think it > makes sense to harmonise the transfer policies for all the different > resource types we have. > > In some corner cases a transfer could prevent the need to renumber > (parts of) a network though. It's worth having this just to support > folks in that position. > > +1 > > Tore > I also support it, it's a good idea to have a policy that allows the transfer of all kinds of resources. /elvis From elvis at velea.eu Tue Jan 20 10:22:45 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Tue, 20 Jan 2015 10:22:45 +0100 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: <20150120090334.235037ec@echo.ms.redpill-linpro.com> References: <20150120090334.235037ec@echo.ms.redpill-linpro.com> Message-ID: <54BE1E65.4000806@velea.eu> On 20/01/15 09:03, Tore Anderson wrote: > * "Hannigan, Martin" > >> Agreed on the policy. I support its continued move forward. > +1 > > Tore > +1 /elvis From ipaddman at bt.com Tue Jan 20 10:25:43 2015 From: ipaddman at bt.com (ipaddman at bt.com) Date: Tue, 20 Jan 2015 09:25:43 +0000 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <20150120073146.35eda6b8@echo.ms.redpill-linpro.com> References: <20150120073146.35eda6b8@echo.ms.redpill-linpro.com> Message-ID: It would be good to get this policy up and running +1 Best regards, Steve Wright This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Tore Anderson Sent: 20 January 2015 06:32 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) * "Marco Schmidt" > The draft documents for version 3.0 of the policy proposal 2014-05, > "Policy for Inter-RIR Transfers of Internet Resources", have now been > published, along with an impact analysis conducted by the RIPE NCC. Looks fine to me. It's about time we get this one out the door. +1 [I do have some editorial gripes, but I'll let those slide for now, as there's a unified resource transfer policy proposal on the horizon that will hopefully clean up those as well.] Tore From nick at inex.ie Tue Jan 20 11:02:57 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 20 Jan 2015 10:02:57 +0000 Subject: [address-policy-wg] 2014-12 Draft Document and Impact Analysis Published (Allow IPv6 Transfers) In-Reply-To: <20150120080849.74c040f8@echo.ms.redpill-linpro.com> References: <20150120080849.74c040f8@echo.ms.redpill-linpro.com> Message-ID: <54BE27D1.7040205@inex.ie> On 20/01/2015 07:08, Tore Anderson wrote: > * "Marco Schmidt" > >> The proposal described in 2014-12, "Allow IPv6 Transfers", is now in >> its Review Phase. > > The need for IPv6 tranfers are probably going to be miniscule as IPv6 > numbers are readily available from the NCC, but nevertheless I think it > makes sense to harmonise the transfer policies for all the different > resource types we have. Can I suggest that this text be clarified slightly: > The block that is to be re-assigned must not be smaller than the minimum > assignment block size at the time of re-assignment. e.g. > The block that is to be re-assigned must not be smaller than the minimum > RIPE NCC IPv6 Provider Independent assignment block size at the time of > re-assignment. Otherwise the intent is ambiguous. Is there a reason that the 24-month cooling down period was removed for this proposal? Nick From modonovan at btireland.net Tue Jan 20 11:00:25 2015 From: modonovan at btireland.net (Mick O'Donovan) Date: Tue, 20 Jan 2015 10:00:25 +0000 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: Message-ID: <54BE2739.7030801@btireland.net> Hi Marco/all, I'm happy to support this proposal. Regards and thanks! Mick On 16/01/2015 13:49, Marco Schmidt wrote: > Dear colleagues, > > The draft documents for version 3.0 of the policy proposal 2014-05, > "Policy for Inter-RIR Transfers of Internet Resources", have now been > published, along with an impact analysis conducted by the RIPE NCC. > > Some of the differences from version 2.0 include: > > - Introduction of needs justification for transfers from RIR regions that require need-based policies > - Explicit statement about when RIPE policies apply during a transfer > - Related wording adjustments in the summary and rationale of the proposal > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2014-05 > > The draft documents are available at: > > https://www.ripe.net/ripe/policies/proposals/2014-05/draft > > We encourage you to read the draft document text and send any comments > to before 16 February 2015. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > From nick at inex.ie Tue Jan 20 11:28:16 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 20 Jan 2015 10:28:16 +0000 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: <20150120090334.235037ec@echo.ms.redpill-linpro.com> References: <20150120090334.235037ec@echo.ms.redpill-linpro.com> Message-ID: <54BE2DC0.1030708@inex.ie> On 20/01/2015 08:03, Tore Anderson wrote: > * "Hannigan, Martin" > >> Agreed on the policy. I support its continued move forward. > > +1 I agree in principal with resource transfer but would like to see some more discussion about the removal of the requirement to return unused resources to the RIPE NCC. This is a substantial change to the current policy which hasn't yet been commented on. Nick From ipaddman at bt.com Tue Jan 20 11:56:11 2015 From: ipaddman at bt.com (ipaddman at bt.com) Date: Tue, 20 Jan 2015 10:56:11 +0000 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: Message-ID: I support this policy proposal +1 Best regards, Steve Wright -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Marco Schmidt Sent: 16 January 2015 13:50 To: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) Dear colleagues, The draft documents for version 3.0 of the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources", have now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 2.0 include: - Introduction of needs justification for transfers from RIR regions that require need-based policies - Explicit statement about when RIPE policies apply during a transfer - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-05 The draft documents are available at: https://www.ripe.net/ripe/policies/proposals/2014-05/draft We encourage you to read the draft document text and send any comments to before 16 February 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From ipaddman at bt.com Tue Jan 20 12:05:05 2015 From: ipaddman at bt.com (ipaddman at bt.com) Date: Tue, 20 Jan 2015 11:05:05 +0000 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: Message-ID: I support this policy proposal +1 Best regards, Steve Wright -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Marco Schmidt Sent: 16 January 2015 13:50 To: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) Dear colleagues, The draft documents for version 3.0 of the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources", have now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 2.0 include: - Introduction of needs justification for transfers from RIR regions that require need-based policies - Explicit statement about when RIPE policies apply during a transfer - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-05 The draft documents are available at: https://www.ripe.net/ripe/policies/proposals/2014-05/draft We encourage you to read the draft document text and send any comments to before 16 February 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From nick at inex.ie Tue Jan 20 13:00:05 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 20 Jan 2015 12:00:05 +0000 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <20150120001708.GE1012@cilantro.c4inet.net> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> <54BD7802.7020006@inex.ie> <20150120001708.GE1012@cilantro.c4inet.net> Message-ID: <54BE4345.7010601@inex.ie> On 20/01/2015 00:17, Sascha Luck [ml] wrote: > On Mon, Jan 19, 2015 at 09:32:50PM +0000, Nick Hilliard wrote: >> we all want a free lunch. > > TANSTAAFL. But *nobody* wants Ryanair, where you pay and then pay > again. And again. And again. yes, TANSTAAFL. Doesn't stop me from wanting it though. >> this certainly creates work for the applicant, possibly enough >> to slow down the process of ASN acquisition. It also creates >> work for the RIPE NCC and someone needs to pay the RIPE NCC > > I'm sure this scenario is not beyond the limits of automation. One ASN per > LIR, then block any more requests for 24h (or > whatever). Any of the NCC software bods want to comment on how > hard this could possible be? The primary consideration should be whether the proposed policy mechanism is sound rather than on how much it would cost the NCC to implement it. I'm not convinced that creating more bureaucracy in an explicit attempt to make it more difficult for people to apply for ASNS is a good basis for creating policy. Nick From apwg at c4inet.net Tue Jan 20 13:23:21 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 20 Jan 2015 12:23:21 +0000 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <20150120080010.7e12eee3@echo.ms.redpill-linpro.com> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> <20150120000755.GD1012@cilantro.c4inet.net> <20150120080010.7e12eee3@echo.ms.redpill-linpro.com> Message-ID: <20150120122321.GF1012@cilantro.c4inet.net> On Tue, Jan 20, 2015 at 08:00:10AM +0100, Tore Anderson wrote: >Would an ASN charge be more palatable to you if the membership fee >included a quota of 1 (or N) gratis ASNs? Or perhaps that the already >existing IPv4/IPv6 PI charge would include 1 gratis ASN per resource? > >I'm thinking that as long as N is a quite modest number, this does not >cause any real abuse potential and at the same time it would make it >more likely that the membership would agree to having an ASN fee put in >place - as the vast majority of us won't actually have to pay anything >more than we do today. It would make it operationally easier (at least for me), but I still think it's a bad idea to have a policy depend on the charging scheme (or vice versa). Even assuming the NCC proposes an ASN charge *and* the members vote for it, this is not guaranteed to survive the next GM. This gives two possible outcomes: a) there is a (perceived) barrier to changing the charging scheme again because a policy depends on it. Basically, policy infringing on something that should be the exclusive purview of the membership. b) if the charging scheme does get changed regardless, the policy doesn't work and needs changing again. Waste of time and offends Nick's sensible requirement that the policy should be good for n years... All in all, an unelegant solution. Besides, I like the idea of a "flat-rate" charging scheme where you pay yor membership fee and have all your services for the year covered. rgds, Sascha Luck From nick at inex.ie Tue Jan 20 13:29:19 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 20 Jan 2015 12:29:19 +0000 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <20150120122321.GF1012@cilantro.c4inet.net> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> <20150120000755.GD1012@cilantro.c4inet.net> <20150120080010.7e12eee3@echo.ms.redpill-linpro.com> <20150120122321.GF1012@cilantro.c4inet.net> Message-ID: <54BE4A1F.7050008@inex.ie> On 20/01/2015 12:23, Sascha Luck [ml] wrote: > All in all, an unelegant solution. Besides, I like the idea of a > "flat-rate" charging scheme where you pay yor membership fee and > have all your services for the year covered. that would be nice, except ASNs are assigned to end users not LIRs. A large number of end users with ASNs are not LIRs. Nick From apwg at c4inet.net Tue Jan 20 13:47:22 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 20 Jan 2015 12:47:22 +0000 Subject: [address-policy-wg] (no subject) Message-ID: <20150120124722.GH1012@cilantro.c4inet.net> Cc: address-policy-wg at ripe.net Bcc: Subject: Re: [address-policy-wg] late conciliatory response to 2014-03 Reply-To: In-Reply-To: <54BE4A1F.7050008 at inex.ie> X-Operating-System: FreeBSD 10.1-RELEASE On Tue, Jan 20, 2015 at 12:29:19PM +0000, Nick Hilliard wrote: >On 20/01/2015 12:23, Sascha Luck [ml] wrote: >> All in all, an unelegant solution. Besides, I like the idea of >> a "flat-rate" charging scheme where you pay yor membership fee >> and have all your services for the year covered. > >that would be nice, except ASNs are assigned to end users not >LIRs. A large number of end users with ASNs are not LIRs. Just noticed that 2007-01 *is* in effect for ASNs, so I guess assignments to non-members are not materially affected by the proposal. rgds, Sascha Luck From ipaddman at bt.com Tue Jan 20 16:09:52 2015 From: ipaddman at bt.com (ipaddman at bt.com) Date: Tue, 20 Jan 2015 15:09:52 +0000 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: Message-ID: I support this policy proposal +1 Best regards, Steve Wright -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Marco Schmidt Sent: 16 January 2015 13:50 To: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) Dear colleagues, The draft documents for version 3.0 of the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources", have now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 2.0 include: - Introduction of needs justification for transfers from RIR regions that require need-based policies - Explicit statement about when RIPE policies apply during a transfer - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-05 The draft documents are available at: https://www.ripe.net/ripe/policies/proposals/2014-05/draft We encourage you to read the draft document text and send any comments to before 16 February 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From mike at iptrading.com Tue Jan 20 16:25:19 2015 From: mike at iptrading.com (Mike Burns) Date: Tue, 20 Jan 2015 10:25:19 -0500 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: References: <20150120090334.235037ec@echo.ms.redpill-linpro.com> Message-ID: Support. Mike Burns From: George Giannousopoulos Sent: Tuesday, January 20, 2015 4:05 AM To: RIPE address policy WG Subject: Re: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) support. Regards, George On Tue, Jan 20, 2015 at 10:03 AM, Tore Anderson wrote: * "Hannigan, Martin" > Agreed on the policy. I support its continued move forward. +1 Tore -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Tue Jan 20 17:18:54 2015 From: mike at iptrading.com (Mike Burns) Date: Tue, 20 Jan 2015 11:18:54 -0500 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: <20150120073146.35eda6b8@echo.ms.redpill-linpro.com> Message-ID: Support. Regards, Mike Burns IPTrading.com -----Original Message----- From: ipaddman at bt.com Sent: Tuesday, January 20, 2015 4:25 AM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) It would be good to get this policy up and running +1 Best regards, Steve Wright This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Tore Anderson Sent: 20 January 2015 06:32 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) * "Marco Schmidt" > The draft documents for version 3.0 of the policy proposal 2014-05, > "Policy for Inter-RIR Transfers of Internet Resources", have now been > published, along with an impact analysis conducted by the RIPE NCC. Looks fine to me. It's about time we get this one out the door. +1 [I do have some editorial gripes, but I'll let those slide for now, as there's a unified resource transfer policy proposal on the horizon that will hopefully clean up those as well.] Tore From ebais at a2b-internet.com Tue Jan 20 22:23:11 2015 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Tue, 20 Jan 2015 22:23:11 +0100 Subject: [address-policy-wg] 2014-13 New Draft Document and Impact Analysis Published (Allow AS Number Transfers) In-Reply-To: <54BE2DC0.1030708@inex.ie> References: <20150120090334.235037ec@echo.ms.redpill-linpro.com> <54BE2DC0.1030708@inex.ie> Message-ID: Hi Nick, Gathering resources just for the idea of collecting resources isn't what is intended in any of the transfer policies. Not for this one, or for the others ... The intention as explained for the policy for both v6 an AS numbers is to enable companies to actually consolidate their LIR's or resources. Currently that is not possible as they might not fit the profile of the operational procedure for M&A's ... The intention is also still in the policy proposal, as the 'must return' is replaced by a 'should return', and not removed. This is to avoid an issue in the policy where a transfer is initiated and the RIPE NCC would read the policy as if that particular company would not need the resource anymore and de-register the resource. I can't say or predict that this policy change will bring more or less unused resources back to the NCC .. Nor is that the goal. It is however my expectation that more resources will come at a place where they will be used ... If the transfer market for IPv4 has shown us one thing, is that the new reality will put the unused resources into used resources. Hope that explains, Egards, Erik Bais Verstuurd vanaf mijn iPad > Op 20 jan. 2015 om 11:28 heeft Nick Hilliard het volgende geschreven: > >> On 20/01/2015 08:03, Tore Anderson wrote: >> * "Hannigan, Martin" >> >>> Agreed on the policy. I support its continued move forward. >> >> +1 > > I agree in principal with resource transfer but would like to see some more > discussion about the removal of the requirement to return unused resources > to the RIPE NCC. This is a substantial change to the current policy which > hasn't yet been commented on. > > Nick > > From nick at inex.ie Wed Jan 21 01:20:21 2015 From: nick at inex.ie (Nick Hilliard) Date: Wed, 21 Jan 2015 00:20:21 +0000 Subject: [address-policy-wg] late conciliatory response to 2014-03 In-Reply-To: <54BE1A39.7080602@velea.eu> References: <1B67B3B0-02D9-42C3-B946-A6579DA6513E@a2b-internet.com> <54BC6BCD.1000703@ssd.axu.tm> <54BD7802.7020006@inex.ie> <54BE1A39.7080602@velea.eu> Message-ID: <54BEF0C5.2040003@inex.ie> On 20/01/2015 09:04, Elvis Daniel Velea wrote: > Are you sure this battle of yours is not so that you can go on one-week > free trips to Bali paid by the LIRs? (like the IGF a couple of years ago) Elvis, If you have concerns about the RIPE NCC member outreach program, it would be more appropriate to bring them up in a forum where they can be addressed properly, e.g. the ncc members mailing list, at a RIPE NCC General Meeting or directly with RIPE NCC management. Nick From guych at btireland.net Wed Jan 21 10:02:12 2015 From: guych at btireland.net (Guy Chilton) Date: Wed, 21 Jan 2015 09:02:12 +0000 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: Message-ID: <54BF6B14.6090805@btireland.net> I support this policy as well. Regards, Guy On 20/01/2015 15:09, ipaddman at bt.com wrote: > I support this policy proposal +1 > > Best regards, > Steve Wright > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Marco Schmidt > Sent: 16 January 2015 13:50 > To: policy-announce at ripe.net > Cc: address-policy-wg at ripe.net > Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) > > > Dear colleagues, > > The draft documents for version 3.0 of the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources", have now been published, along with an impact analysis conducted by the RIPE NCC. > > Some of the differences from version 2.0 include: > > - Introduction of needs justification for transfers from RIR regions that require need-based policies > - Explicit statement about when RIPE policies apply during a transfer > - Related wording adjustments in the summary and rationale of the proposal > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2014-05 > > The draft documents are available at: > > https://www.ripe.net/ripe/policies/proposals/2014-05/draft > > We encourage you to read the draft document text and send any comments to before 16 February 2015. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > From dscotland at plus.net Wed Jan 21 10:53:21 2015 From: dscotland at plus.net (dscotland at plus.net) Date: Wed, 21 Jan 2015 09:53:21 +0000 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <54BF6B14.6090805@btireland.net> References: <54BF6B14.6090805@btireland.net> Message-ID: I support this policy. -- Duncan Scotland LIR Plusnet plc | www.plus.net Tel: 0114 220 0081 Registered Office: Plusnet | The Balance | 2 Pinfold Street | Sheffield | S1 2GU Registered in England no: 3279013 On 21/01/2015 09:02, "Guy Chilton" wrote: >I support this policy as well. > >Regards, > >Guy > >On 20/01/2015 15:09, ipaddman at bt.com wrote: >> I support this policy proposal +1 >> >> Best regards, >> Steve Wright >> >> -----Original Message----- >> From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On >>Behalf Of Marco Schmidt >> Sent: 16 January 2015 13:50 >> To: policy-announce at ripe.net >> Cc: address-policy-wg at ripe.net >> Subject: [address-policy-wg] 2014-05 New Draft Document and Impact >>Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) >> >> >> Dear colleagues, >> >> The draft documents for version 3.0 of the policy proposal 2014-05, >>"Policy for Inter-RIR Transfers of Internet Resources", have now been >>published, along with an impact analysis conducted by the RIPE NCC. >> >> Some of the differences from version 2.0 include: >> >> - Introduction of needs justification for transfers from RIR regions >>that require need-based policies >> - Explicit statement about when RIPE policies apply during a transfer >> - Related wording adjustments in the summary and rationale of the >>proposal >> >> You can find the full proposal and the impact analysis at: >> >> https://www.ripe.net/ripe/policies/proposals/2014-05 >> >> The draft documents are available at: >> >> https://www.ripe.net/ripe/policies/proposals/2014-05/draft >> >> We encourage you to read the draft document text and send any comments >>to before 16 February 2015. >> >> Regards, >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> > > From lukas at wunner.de Wed Jan 21 23:48:53 2015 From: lukas at wunner.de (Lukas Wunner) Date: Wed, 21 Jan 2015 23:48:53 +0100 Subject: [address-policy-wg] 2014-12 Draft Document and Impact Analysis Published (Allow IPv6 Transfers) Message-ID: <20150121224853.GA5700@wunner.de> Hi, > The proposal described in 2014-12, "Allow IPv6 Transfers", > is now in its Review Phase. I fully support this proposal. Best regards, Lukas Wunner (LW26-RIPE) From daniel at blueskysystems.co.uk Wed Jan 21 12:09:50 2015 From: daniel at blueskysystems.co.uk (Daniel Davis) Date: Wed, 21 Jan 2015 11:09:50 +0000 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) Message-ID: Hi, Our comment on thIs proposal is: We would not support this proposal to Remove the IPv6 Requirement for Receiving Space from the Final /8. This is because his policy encourages ripe members to start the process of using ipv6 addresses, and that given the shortage of ipv4 space migration is becoming increasingly important. By changing this policy we believe this will give out the wrong signals to the industry about ipv6 migration. Best Regards, Daniel Davis Director Blue Sky Systems Limited Tel: 03300 101 550 Mobile: 07718 425 855 Email: daniel at blueskysystems.co.uk Web: www.blueskysystems.co.uk Registered Office: Unit 16 Horizon Business Village, 1 Brooklands Road, Weybridge, Surrey, KT13 0TJ. Registered in England No: 8856125. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Jan 22 11:55:46 2015 From: gert at space.net (Gert Doering) Date: Thu, 22 Jan 2015 11:55:46 +0100 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: References: Message-ID: <20150122105546.GD34798@Space.Net> Hi, On Wed, Jan 21, 2015 at 11:09:50AM +0000, Daniel Davis wrote: > Our comment on thIs proposal is: > We would not support this proposal to Remove the IPv6 Requirement for Receiving Space from the Final /8. > This is because his policy encourages ripe members to start the process of using ipv6 addresses, and that given the shortage of ipv4 space migration is becoming increasingly important. > By changing this policy we believe this will give out the wrong signals to the industry about ipv6 migration. This argument has been brought up before, and I consider it addressed (by asking the RIPE NCC to send very clear signals regarding IPv6 encouragements to future applicants, and also increasing their general IPv6 outreach). Last Call is there to bring up arguments opposing the proposal that have not been voiced and answered before - like, some completely new angle hat has been overlooked. As always, consensus does not have to be unanimous if there is sufficiently strong support. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 st at sct.de Thu Jan 22 12:38:39 2015 From: st at sct.de (Stefan Schiele) Date: Thu, 22 Jan 2015 12:38:39 +0100 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <20150122105546.GD34798@Space.Net> References: <20150122105546.GD34798@Space.Net> Message-ID: <54C0E13F.9090909@sct.de> Hi Gert, I don't consider this argument as being addressed by simply asking the RIPE NCC to send out clear signals that IPv6 is important. There is a difference between being forced to request an IPv6 allocation to receive IPv4 space from the final /8 and the RIPE NCC sending out some signals regarding IPv6. From my point of view, this argument hasn't been really addressed; some agreed with it and some didn't. If the majority agrees with this proposal that's fine for me; and I can live with that. However, as the one who brought up this argument a few weeks ago in the first place please allow me to tell you that I think it is not addressed by simply asking the RIPE NCC to send out some signals. The proposed policy change will speed up the shortage of IPv4 space; and therefore I still strongly oppose this proposal. By the way, this proposal would increase prices on the IPv4 transfer market (due to it speeding up the shortening of the free IPv4 address space); and that is generally nothing that's good for the community, either. Kind Regards, Stefan Schiele Am 22.01.2015 um 11:55 schrieb Gert Doering: > Hi, > > On Wed, Jan 21, 2015 at 11:09:50AM +0000, Daniel Davis wrote: >> Our comment on thIs proposal is: >> We would not support this proposal to Remove the IPv6 Requirement for Receiving Space from the Final /8. >> This is because his policy encourages ripe members to start the process of using ipv6 addresses, and that given the shortage of ipv4 space migration is becoming increasingly important. >> By changing this policy we believe this will give out the wrong signals to the industry about ipv6 migration. > This argument has been brought up before, and I consider it addressed > (by asking the RIPE NCC to send very clear signals regarding IPv6 > encouragements to future applicants, and also increasing their general > IPv6 outreach). > > Last Call is there to bring up arguments opposing the proposal that have > not been voiced and answered before - like, some completely new angle > hat has been overlooked. > > As always, consensus does not have to be unanimous if there is sufficiently > strong support. > > Gert Doering > -- APWG chair From elvis at v4escrow.net Thu Jan 22 13:04:13 2015 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Thu, 22 Jan 2015 13:04:13 +0100 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <54C0E13F.9090909@sct.de> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> Message-ID: <54C0E73D.3060801@v4escrow.net> Hi Stefan, On 22/01/15 12:38, Stefan Schiele wrote: [...] > The proposed policy change will speed up the shortage of IPv4 space; > and therefore I still strongly oppose this proposal. I do not think there will be any difference in how much IPv4 will be requested/allocated from the last /8 if the policy changes. I could easily just use the LIR Portal 3-click request and get an IPv6 allocation if it's one of the steps in requesting the IPv4 allocation. It does not mean that I will actually use it or do anything with it. It's just a step in the process of me getting the /22 I wanted. > > By the way, this proposal would increase prices on the IPv4 transfer > market (due to it speeding up the shortening of the free IPv4 address > space); and that is generally nothing that's good for the community, > either. > I doubt it will have any effect. The RIPE NCC still has more than a /8 in /22s (18.55 mil IP addresses) [1] and can allocate the /22s for at least 5-10 years (my personal opinion is that it will never stop allocating the /22s). Regards, Elvis [1] https://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph > Kind Regards, > > Stefan Schiele > > Am 22.01.2015 um 11:55 schrieb Gert Doering: >> Hi, >> >> On Wed, Jan 21, 2015 at 11:09:50AM +0000, Daniel Davis wrote: >>> Our comment on thIs proposal is: >>> We would not support this proposal to Remove the IPv6 Requirement >>> for Receiving Space from the Final /8. >>> This is because his policy encourages ripe members to start the >>> process of using ipv6 addresses, and that given the shortage of ipv4 >>> space migration is becoming increasingly important. >>> By changing this policy we believe this will give out the wrong >>> signals to the industry about ipv6 migration. >> This argument has been brought up before, and I consider it addressed >> (by asking the RIPE NCC to send very clear signals regarding IPv6 >> encouragements to future applicants, and also increasing their general >> IPv6 outreach). >> >> Last Call is there to bring up arguments opposing the proposal that have >> not been voiced and answered before - like, some completely new angle >> hat has been overlooked. >> >> As always, consensus does not have to be unanimous if there is >> sufficiently >> strong support. >> >> Gert Doering >> -- APWG chair > > -- 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 nigel at titley.com Thu Jan 22 13:13:52 2015 From: nigel at titley.com (Nigel Titley) Date: Thu, 22 Jan 2015 12:13:52 +0000 Subject: [address-policy-wg] RIPE NCC Charging Scheme 2016 Discussion Message-ID: <54C0E980.9050404@titley.com> Dear Colleagues, The RIPE NCC Executive Board has closely followed the ASN discussion on the Address Policy Working Group mailing list. The issue of the RIPE NCC Charging Scheme has been raised, so I'd like to give you an idea of the Board's thinking on this. We hope this will inform the discussion and also give sufficient time for members to give their feedback, which we will take into account when making a Charging Scheme 2016 proposal to present to the General Meeting (GM) in May this year. The issue of reintroducing a charge for ASNs was raised at the last GM in November 2014. You can follow the details of that discussion in the GM minutes: https://www.ripe.net/lir-services/ncc/gm/november-2014/minutes-ripe-ncc-general-meeting-november-2014 This discussion, interesting though it was, did not result in a conclusive outcome on how the membership would like the Board to proceed with regard to ASNs. It also raised the issue of charging for PI address space. Another issue raised at the previous GM during the discussion on providing RIPE NCC services for Legacy Internet resource holders was that members can vote only to approve or reject the Charging Scheme as a whole and they cannot vote on individual aspects of the Charging Scheme. In trying to address the Charging Scheme-related issues raised, the Board would like to make two statements: Firstly, the Board would like to retain the current "one LIR, one fee" Charging Scheme model that was approved by the membership and which provides fairness, predictability and simplicity for RIPE NCC members. Secondly, the Board strongly believes that the Charging Scheme should be aligned with RIPE Policy. For this reason, there is a separate charge for PI resources that ensures alignment with ripe-452, "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region (2007-01)". With this in mind, the Board would like to offer two different proposals for the Charging Scheme 2016: 1. The Board can propose a Charging Scheme in advance of the May GM and have the membership discuss the proposal. The Board would take the discussion into account before proposing a final Charging Scheme to be voted on by the membership in May. or 2. The Board could take a two-step approach to the Charging Scheme. In May, members would vote on individual issues such as charging for ASNs. The result of the voting would then be used to create a Charging Scheme that would be voted on in the usual way by members at the November GM. The RIPE NCC Executive Board is appointed to represent the interests of the membership. For this reason, we encourage you to give us your feedback on these proposals so that the RIPE NCC Charging Scheme 2016 can come as close as possible to reflecting the wishes of the membership. You can discuss the proposal and related Charging Scheme issues on the Members Discuss mailing list (members-discuss at ripe.net ) or you can contact the Board directly at exec-board at ripe.net . The next Executive Board meeting takes place on 19 March, so we would appreciate your feedback before that date. I will also copy this mail to the Address Policy Working Group mailing list to ensure all interested parties are aware of the Board's thinking. Best regards, Nigel Titley RIPE NCC Executive Board Chairman -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkennedy at libertyglobal.com Thu Jan 22 13:38:41 2015 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Thu, 22 Jan 2015 12:38:41 +0000 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <54C0E13F.9090909@sct.de> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> Message-ID: <13E63C78A6256E4A857726374FBF926E127669A5@NLAMSPEXMB022.upcit.ds.upc.biz> Hello, Wouldn't relaxing the text (as initially suggested) to require the LIR to have *any* form of IPv6, rather than removing it altogether, be more beneficial to general IPv6 adoption? I fear having no IPv6 requirement at all may encourage the LIR to look into alternatives, such as NAT or the transfer market. Of course the LIR's deployment decision will ultimately come down to QoS, scalability, revenue etc., but I don't see the harm in encouraging the LIR to get some IPv6. After all, it's really very easy to get an IPv6 allocation from the NCC and at no additional cost.. currently :) Receiving their own v6 block may spark an interest in LIRs that previously had no IPv6 plans. Regards, James -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Stefan Schiele Sent: 22 January 2015 12:39 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) Hi Gert, I don't consider this argument as being addressed by simply asking the RIPE NCC to send out clear signals that IPv6 is important. There is a difference between being forced to request an IPv6 allocation to receive IPv4 space from the final /8 and the RIPE NCC sending out some signals regarding IPv6. From my point of view, this argument hasn't been really addressed; some agreed with it and some didn't. If the majority agrees with this proposal that's fine for me; and I can live with that. However, as the one who brought up this argument a few weeks ago in the first place please allow me to tell you that I think it is not addressed by simply asking the RIPE NCC to send out some signals. The proposed policy change will speed up the shortage of IPv4 space; and therefore I still strongly oppose this proposal. By the way, this proposal would increase prices on the IPv4 transfer market (due to it speeding up the shortening of the free IPv4 address space); and that is generally nothing that's good for the community, either. Kind Regards, Stefan Schiele Am 22.01.2015 um 11:55 schrieb Gert Doering: > Hi, > > On Wed, Jan 21, 2015 at 11:09:50AM +0000, Daniel Davis wrote: >> Our comment on thIs proposal is: >> We would not support this proposal to Remove the IPv6 Requirement for Receiving Space from the Final /8. >> This is because his policy encourages ripe members to start the process of using ipv6 addresses, and that given the shortage of ipv4 space migration is becoming increasingly important. >> By changing this policy we believe this will give out the wrong signals to the industry about ipv6 migration. > This argument has been brought up before, and I consider it addressed > (by asking the RIPE NCC to send very clear signals regarding IPv6 > encouragements to future applicants, and also increasing their general > IPv6 outreach). > > Last Call is there to bring up arguments opposing the proposal that > have not been voiced and answered before - like, some completely new > angle hat has been overlooked. > > As always, consensus does not have to be unanimous if there is > sufficiently strong support. > > Gert Doering > -- APWG chair From st at sct.de Thu Jan 22 17:42:06 2015 From: st at sct.de (Stefan Schiele) Date: Thu, 22 Jan 2015 17:42:06 +0100 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <54C0E73D.3060801@v4escrow.net> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <54C0E73D.3060801@v4escrow.net> Message-ID: <54C1285E.9040200@sct.de> Hi Elvis, Am 22.01.2015 um 13:04 schrieb Elvis Daniel Velea: > [...] >> The proposed policy change will speed up the shortage of IPv4 space; >> and therefore I still strongly oppose this proposal. > I do not think there will be any difference in how much IPv4 will be > requested/allocated from the last /8 if the policy changes. I could > easily just use the LIR Portal 3-click request and get an IPv6 > allocation if it's one of the steps in requesting the IPv4 allocation. > It does not mean that I will actually use it or do anything with it. > It's just a step in the process of me getting the /22 I wanted. The current policy actually had a positive effect on our company. The main reason for us to sign up as an LIR was to get more IPv4 addresses; and since we had to request an IPv6 allocation we wanted to have this set up and running. If it had been possible to get that /22 without an IPv6 address space we would probably still be using IPv4 only (the IPv4 address space we currently have is large enough for our business for the foreseeable future). Since this policy had a positive effect on IPv6 awareness for us I simply deduce that it should have a positive effect for some other companies as well. However, that's not just a guess, there is also statistical data regarding this: Andrea Cima from RIPE NCC wrote on 11 December 2014: > The RIPE NCC has started allocating /22s from the last /8 on 14 > September 2012. Since then 4190 IPv6 allocations have been made, out > of which 1160 are currently visible in the BGP routing tables. > > If we take into consideration the total number of IPv6 allocations > made by the RIPE NCC, 8398 IPv6 allocations have been made, out of > which 4098 are currently visible in the BGP routing tables. That means that more than 27% of those IPv6 allocations are really used; and that's a quite impressive figure. And I think we can conclude that the current policy does have a positive effect on IPv6 deployment. In comparison about 49% of all IPv6 allocations are visible in the BGP routing table; and that makes that 27% even more impressive. >> >> By the way, this proposal would increase prices on the IPv4 transfer >> market (due to it speeding up the shortening of the free IPv4 address >> space); and that is generally nothing that's good for the community, >> either. >> > I doubt it will have any effect. The RIPE NCC still has more than a /8 > in /22s (18.55 mil IP addresses) [1] and can allocate the /22s for at > least 5-10 years (my personal opinion is that it will never stop > allocating the /22s). Any increase in IPv6 awareness is good for lessening the demand for IPv4 addresses. In any free market prices are subject to "supply and demand"; anything that reduces supply or increases demand will make prices go up. I agree with you that the RIPE NCC will not run out of IPv4 address space during the next few years. Given the amount of 18.55 mil IP addresses this is enough for about 18.000 new /22 allocations. Given the data Andrea Cima from RIPE NCC posted on December 11th on this list 4190 IPv6 allocation have been made between 14 September 2012 (the date when the RIPE NCC has started allocation /22s from the last /8) until 11 December 2014 we could estimate that that address space will be sufficient for the next 9-10 years; and even if we take into account that the number of new LIRs will increase in the future I still think that your 5-10 year range is a reasonable estimate. Presumably you agree with me that increasing the IPv6 awareness will help reducing the demand for IPv4 addresses; my personal opinion is that prices for IPv4 addresses on the transfer market will still go up during the next years due to the increasing shortage of available IPv4 address space; however, if we are successful as a community in convincing new and existing LIRs to deploy IPv6 that increase will be lower. I think that forcing anyone who wants to get address space from the last IPv4 to get an IPv6 allocation first won't do any harm to anyone; even if a LIR does not want to deploy IPv6 now they can simply put that allocation on a shelf and deploy it later. And the impressive statistics from the RIPE NCC show that the current policy text helps IPv6 deployment. Kind Regards, Stefan > > Regards, > Elvis > > [1] > https://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph > >> Kind Regards, >> >> Stefan Schiele >> >> Am 22.01.2015 um 11:55 schrieb Gert Doering: >>> Hi, >>> >>> On Wed, Jan 21, 2015 at 11:09:50AM +0000, Daniel Davis wrote: >>>> Our comment on thIs proposal is: >>>> We would not support this proposal to Remove the IPv6 Requirement >>>> for Receiving Space from the Final /8. >>>> This is because his policy encourages ripe members to start the >>>> process of using ipv6 addresses, and that given the shortage of >>>> ipv4 space migration is becoming increasingly important. >>>> By changing this policy we believe this will give out the wrong >>>> signals to the industry about ipv6 migration. >>> This argument has been brought up before, and I consider it addressed >>> (by asking the RIPE NCC to send very clear signals regarding IPv6 >>> encouragements to future applicants, and also increasing their general >>> IPv6 outreach). >>> >>> Last Call is there to bring up arguments opposing the proposal that >>> have >>> not been voiced and answered before - like, some completely new angle >>> hat has been overlooked. >>> >>> As always, consensus does not have to be unanimous if there is >>> sufficiently >>> strong support. >>> >>> Gert Doering >>> -- APWG chair >> >> > > > -- > > > > 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 catrangiumarius at gmail.com Thu Jan 22 17:55:59 2015 From: catrangiumarius at gmail.com (Marius Catrangiu) Date: Thu, 22 Jan 2015 18:55:59 +0200 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <54C1285E.9040200@sct.de> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <54C0E73D.3060801@v4escrow.net> <54C1285E.9040200@sct.de> Message-ID: I totally agree with Stefan and I support what he said here. ipv6 should be a must. On Jan 22, 2015 6:42 PM, "Stefan Schiele" wrote: > Hi Elvis, > > Am 22.01.2015 um 13:04 schrieb Elvis Daniel Velea: > > [...] > > The proposed policy change will speed up the shortage of IPv4 space; and > therefore I still strongly oppose this proposal. > > I do not think there will be any difference in how much IPv4 will be > requested/allocated from the last /8 if the policy changes. I could easily > just use the LIR Portal 3-click request and get an IPv6 allocation if it's > one of the steps in requesting the IPv4 allocation. It does not mean that I > will actually use it or do anything with it. It's just a step in the > process of me getting the /22 I wanted. > > > The current policy actually had a positive effect on our company. The main > reason for us to sign up as an LIR was to get more IPv4 addresses; and > since we had to request an IPv6 allocation we wanted to have this set up > and running. If it had been possible to get that /22 without an IPv6 > address space we would probably still be using IPv4 only (the IPv4 address > space we currently have is large enough for our business for the > foreseeable future). > > Since this policy had a positive effect on IPv6 awareness for us I simply > deduce that it should have a positive effect for some other companies as > well. However, that's not just a guess, there is also statistical data > regarding this: > > Andrea Cima from RIPE NCC wrote on 11 December 2014: > > The RIPE NCC has started allocating /22s from the last /8 on 14 September > 2012. Since then 4190 IPv6 allocations have been made, out of which 1160 > are currently visible in the BGP routing tables. > > If we take into consideration the total number of IPv6 allocations made by > the RIPE NCC, 8398 IPv6 allocations have been made, out of which 4098 are > currently visible in the BGP routing tables. > > > That means that more than 27% of those IPv6 allocations are really used; > and that's a quite impressive figure. And I think we can conclude that the > current policy does have a positive effect on IPv6 deployment. In > comparison about 49% of all IPv6 allocations are visible in the BGP routing > table; and that makes that 27% even more impressive. > > > By the way, this proposal would increase prices on the IPv4 transfer > market (due to it speeding up the shortening of the free IPv4 address > space); and that is generally nothing that's good for the community, > either. > > I doubt it will have any effect. The RIPE NCC still has more than a /8 in > /22s (18.55 mil IP addresses) [1] and can allocate the /22s for at least > 5-10 years (my personal opinion is that it will never stop allocating the > /22s). > > > Any increase in IPv6 awareness is good for lessening the demand for IPv4 > addresses. In any free market prices are subject to "supply and demand"; > anything that reduces supply or increases demand will make prices go up. > > I agree with you that the RIPE NCC will not run out of IPv4 address space > during the next few years. Given the amount of 18.55 mil IP addresses this > is enough for about 18.000 new /22 allocations. Given the data Andrea Cima > from RIPE NCC posted on December 11th on this list 4190 IPv6 allocation > have been made between 14 September 2012 (the date when the RIPE NCC has > started allocation /22s from the last /8) until 11 December 2014 we could > estimate that that address space will be sufficient for the next 9-10 > years; and even if we take into account that the number of new LIRs will > increase in the future I still think that your 5-10 year range is a > reasonable estimate. > > Presumably you agree with me that increasing the IPv6 awareness will help > reducing the demand for IPv4 addresses; my personal opinion is that prices > for IPv4 addresses on the transfer market will still go up during the next > years due to the increasing shortage of available IPv4 address space; > however, if we are successful as a community in convincing new and existing > LIRs to deploy IPv6 that increase will be lower. > > I think that forcing anyone who wants to get address space from the last > IPv4 to get an IPv6 allocation first won't do any harm to anyone; even if a > LIR does not want to deploy IPv6 now they can simply put that allocation on > a shelf and deploy it later. And the impressive statistics from the RIPE > NCC show that the current policy text helps IPv6 deployment. > > Kind Regards, > Stefan > > > Regards, > Elvis > > [1] > https://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph > > Kind Regards, > > Stefan Schiele > > Am 22.01.2015 um 11:55 schrieb Gert Doering: > > Hi, > > On Wed, Jan 21, 2015 at 11:09:50AM +0000, Daniel Davis wrote: > > Our comment on thIs proposal is: > We would not support this proposal to Remove the IPv6 Requirement for > Receiving Space from the Final /8. > This is because his policy encourages ripe members to start the process of > using ipv6 addresses, and that given the shortage of ipv4 space migration > is becoming increasingly important. > By changing this policy we believe this will give out the wrong signals to > the industry about ipv6 migration. > > This argument has been brought up before, and I consider it addressed > (by asking the RIPE NCC to send very clear signals regarding IPv6 > encouragements to future applicants, and also increasing their general > IPv6 outreach). > > Last Call is there to bring up arguments opposing the proposal that have > not been voiced and answered before - like, some completely new angle > hat has been overlooked. > > As always, consensus does not have to be unanimous if there is > sufficiently > strong support. > > Gert Doering > -- APWG chair > > > > > > -- > 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 dave.wilson at heanet.ie Thu Jan 22 18:02:38 2015 From: dave.wilson at heanet.ie (Dave Wilson) Date: Thu, 22 Jan 2015 17:02:38 +0000 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <13E63C78A6256E4A857726374FBF926E127669A5@NLAMSPEXMB022.upcit.ds.upc.biz> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <13E63C78A6256E4A857726374FBF926E127669A5@NLAMSPEXMB022.upcit.ds.upc.biz> Message-ID: <54C12D2E.7000909@heanet.ie> Hello James, On 22/01/2015 12:38, Kennedy, James wrote: > Wouldn't relaxing the text (as initially suggested) to require the LIR to have *any* form of IPv6, rather than removing it altogether, be more beneficial to general IPv6 adoption? > I fear having no IPv6 requirement at all may encourage the LIR to look into alternatives, such as NAT or the transfer market. Honestly, I don't think it would, no. We'd get some anecdotes like we already have, but nothing systematic. This proposal looks harsh because all a proposal can do is changing the policy text and, taken on its own, that appears to be a negative change. Might as well do something, right? But "something is better than nothing" is just not effective; in fact the thrust of my talk at RIPE68 is that it's worse than useless. Here's one example for this particular case: the number of v6 assignments is not currently a useful measure of interest in IPv6, because it's polluted by assignments to people who only applied because they had to do so to get a /22. As Gert said, the RIPE NCC is asked to send very clear signals about IPv6 to future applicants. That's something that doesn't belong in the policy text, but is absolutely pertinent to this proposal, and my feeling is that it'll be an overall improvement. More importantly, it's something that can be worked on over time so that we do end up with a systematic improvement. (So to be clear: I support the policy as is in last call.) All the best, Dave -- Dave Wilson, Project Manager web: www.heanet.ie HEAnet Ltd, 5 George's Dock, IFSC, Dublin 1 tel: +353-1-660-9040 Registered in Ireland, no 275301 fax: +353-1-660-3666 From dave.wilson at heanet.ie Thu Jan 22 18:15:03 2015 From: dave.wilson at heanet.ie (Dave Wilson) Date: Thu, 22 Jan 2015 17:15:03 +0000 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <54C1285E.9040200@sct.de> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <54C0E73D.3060801@v4escrow.net> <54C1285E.9040200@sct.de> Message-ID: <54C13017.4010802@heanet.ie> Hi Stefan, On 22/01/2015 16:42, Stefan Schiele wrote: > Andrea Cima from RIPE NCC wrote on 11 December 2014: >> The RIPE NCC has started allocating /22s from the last /8 on 14 >> September 2012. Since then 4190 IPv6 allocations have been made, out >> of which 1160 are currently visible in the BGP routing tables. >> >> If we take into consideration the total number of IPv6 allocations >> made by the RIPE NCC, 8398 IPv6 allocations have been made, out of >> which 4098 are currently visible in the BGP routing tables. > > That means that more than 27% of those IPv6 allocations are really used; > and that's a quite impressive figure. And I think we can conclude that > the current policy does have a positive effect on IPv6 deployment. In > comparison about 49% of all IPv6 allocations are visible in the BGP > routing table; and that makes that 27% even more impressive. I disagree with your interpretation: present in the routing table does not imply being used. I used to take it as a good sign, but now I believe it is a very low bar - someone thought to apply for the address space and succeeded in configuring a BGP session somewhere. Maybe they really use it and maybe they don't; it's just not a very useful metric. Note that "arguments supporting the proposal" says that the status quo is actively troublesome for users of IPv6 PI space: to get a /22, they have to disrupt their IPv6 installation to return their PI assignment and get a PA allocation. Having this in policy is currently doing harm to IPv6, and we can do better outreach than this. Best regards, Dave -- Dave Wilson, Project Manager web: www.heanet.ie HEAnet Ltd, 5 George's Dock, IFSC, Dublin 1 tel: +353-1-660-9040 Registered in Ireland, no 275301 fax: +353-1-660-3666 From d.baeza at tvt-datos.es Thu Jan 22 18:20:41 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Thu, 22 Jan 2015 18:20:41 +0100 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <54C13017.4010802@heanet.ie> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <54C0E73D.3060801@v4escrow.net> <54C1285E.9040200@sct.de> <54C13017.4010802@heanet.ie> Message-ID: <54C13169.8040104@tvt-datos.es> Hi Dave, El 22/01/2015 a las 18:15, Dave Wilson escribi?: > Note that "arguments supporting the proposal" says that the status quo > is actively troublesome for users of IPv6 PI space: to get a /22, they > have to disrupt their IPv6 installation to return their PI assignment > and get a PA allocation. This can be solved just modifiyin the IPv6 Requirement, not removing it. Just allowing PI assignments valid for recieving an allocation from the last /8. Easy as that. No troublesome for LIRs with PI assignments and to the ones that dont have any v6 PI/PA Space still in the need to request first for an IPv6. By this way, all happy. Cheers, -- Daniel Baeza From dave.wilson at heanet.ie Thu Jan 22 18:55:29 2015 From: dave.wilson at heanet.ie (Dave Wilson) Date: Thu, 22 Jan 2015 17:55:29 +0000 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <54C13169.8040104@tvt-datos.es> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <54C0E73D.3060801@v4escrow.net> <54C1285E.9040200@sct.de> <54C13017.4010802@heanet.ie> <54C13169.8040104@tvt-datos.es> Message-ID: <54C13991.50005@heanet.ie> Hi Daniel, >> Note that "arguments supporting the proposal" says that the status quo >> is actively troublesome for users of IPv6 PI space: to get a /22, they >> have to disrupt their IPv6 installation to return their PI assignment >> and get a PA allocation. > > This can be solved just modifiyin the IPv6 Requirement, not removing it. It could, but the other arguments already discussed still stand for the proposal as is. :-) I just wanted to remind that the current policy in effect is causing problems. All the best, Dave -- Dave Wilson, Project Manager web: www.heanet.ie HEAnet Ltd, 5 George's Dock, IFSC, Dublin 1 tel: +353-1-660-9040 Registered in Ireland, no 275301 fax: +353-1-660-3666 From gert at space.net Thu Jan 22 22:14:10 2015 From: gert at space.net (Gert Doering) Date: Thu, 22 Jan 2015 22:14:10 +0100 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <54C0E13F.9090909@sct.de> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> Message-ID: <20150122211410.GG34798@Space.Net> Hi, On Thu, Jan 22, 2015 at 12:38:39PM +0100, Stefan Schiele wrote: > I don't consider this argument as being addressed by simply asking the > RIPE NCC to send out clear signals that IPv6 is important. There is a > difference between being forced to request an IPv6 allocation to receive > IPv4 space from the final /8 and the RIPE NCC sending out some signals > regarding IPv6. It is, but I have to make a decision how to go ahead if many members of the community support the proposal, while a single argument is brought in opposition - "stop the proposal" (which would mean "nothing gets anywhere, ever") or "understand the concerns and find a way that will at least bring some compromise". [..] > The proposed policy change will speed up the shortage of IPv4 space; and > therefore I still strongly oppose this proposal. It will not - people who want the last /22 for speculation can have it today perfectly fine. Forcing them to take a (free) /32 with it will not make them more conservative - it sends a message ("hey! think of IPv6!") and we can convey that message in other ways, too. > By the way, this proposal would increase prices on the IPv4 transfer > market (due to it speeding up the shortening of the free IPv4 address > space); and that is generally nothing that's good for the community, either. This is handwaving based on assumptions... Anyway, there is a group working on a proposal to prevent exactly this: speculation with the last /22 allocations ("open LIR, grab /22, sell it, close LIR, open new LIR, ..."). The policy proposal discussed here has really no influence on people that want to speculate - nothing stops them form accepting the free /32 together with the /22, sell the /22, return the /32, and close the LIR... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 Thu Jan 22 22:23:00 2015 From: gert at space.net (Gert Doering) Date: Thu, 22 Jan 2015 22:23:00 +0100 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <54C1285E.9040200@sct.de> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <54C0E73D.3060801@v4escrow.net> <54C1285E.9040200@sct.de> Message-ID: <20150122212300.GH34798@Space.Net> Hi, On Thu, Jan 22, 2015 at 05:42:06PM +0100, Stefan Schiele wrote: > Andrea Cima from RIPE NCC wrote on 11 December 2014: > > The RIPE NCC has started allocating /22s from the last /8 on 14 > > September 2012. Since then 4190 IPv6 allocations have been made, out > > of which 1160 are currently visible in the BGP routing tables. > > > > If we take into consideration the total number of IPv6 allocations > > made by the RIPE NCC, 8398 IPv6 allocations have been made, out of > > which 4098 are currently visible in the BGP routing tables. > > That means that more than 27% of those IPv6 allocations are really used; > and that's a quite impressive figure. And I think we can conclude that > the current policy does have a positive effect on IPv6 deployment. In > comparison about 49% of all IPv6 allocations are visible in the BGP > routing table; and that makes that 27% even more impressive. The nice things about numbers is that you can interpret them any way you like. For me, these numbers tell me: LIRs that have not been *forced* to take a /32 are *more likely* to actually announce it in BGP than those that had to take it as "mandatory" (nearly 50% of all IPv6 allocations in total are in BGP, but only 27% of those after September 2012). You assume that LIRs will only ask for IPv6 because they have to - but that is just wrong. All the "pre /22" LIRs that have IPv6 asked for it because they *wanted* IPv6. [Before anyone chimes in: nobody understands why allocations do not show up in BGP, or why it takes as long as it does for them to show up, and "show up in BGP" is also not a useful metric for "has deployed IPv6 on more than a single router"] [..] > I think that forcing anyone who wants to get address space from the last > IPv4 to get an IPv6 allocation first won't do any harm to anyone; The current policy *does* cause harm for those that have already deployed IPv6 but have done so with PI space - because forcing them to take a PA allocation will also force them to return their PI space and renumber all their existing IPv6 deployment. This is what got the whole ball rolling. You might want to enlighten yourself by reading up the discussion on possible alternative wordings to the policy, and why we ended up with removing the criteria altogether. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 Thu Jan 22 22:25:11 2015 From: gert at space.net (Gert Doering) Date: Thu, 22 Jan 2015 22:25:11 +0100 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <54C0E73D.3060801@v4escrow.net> <54C1285E.9040200@sct.de> Message-ID: <20150122212511.GI34798@Space.Net> Hi, On Thu, Jan 22, 2015 at 06:55:59PM +0200, Marius Catrangiu wrote: > I totally agree with Stefan and I support what he said here. ipv6 should be > a must. Please understand what "Last Call" is about: *new* arguments that have not be heard in the review or discussion phase, and have not been answered. It is not useful to re-run the same arguments in circles after it has become clear that there is rough consensus the other way (and also remember: rough consensus does not mean "everybody agrees"). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 jkennedy at libertyglobal.com Thu Jan 22 23:01:01 2015 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Thu, 22 Jan 2015 22:01:01 +0000 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <54C12D2E.7000909@heanet.ie> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <13E63C78A6256E4A857726374FBF926E127669A5@NLAMSPEXMB022.upcit.ds.upc.biz>, <54C12D2E.7000909@heanet.ie> Message-ID: <855D0B5A-681C-457E-AFA0-6FCF1EBCC092@upcbroadband.com> Hi Dave, > On 22 Jan 2015, at 18:12, "Dave Wilson" > wrote: > > This proposal looks harsh because all a proposal can do is changing the > policy text and, taken on its own, that appears to be a negative change. > Might as well do something, right? But "something is better than > nothing" is just not effective; in fact the thrust of my talk at RIPE68 > is that it's worse than useless. Sorry I missed your talk, sounds interesting. I wouldn't say this proposal is negative, I just haven't read anyone explain how having an *any* IPv6 requirement negatively impacts IPv6 internet growth. How could it be worse than useless? Would it deter or slow a company's IPv6 adoption? I don't see how. In fact the IPv6 requirement in the current policy actually got Stefan Schiele's organisation on their unplanned road to v6, just like I said having their own v6 block may spark the interest of an organisation that previously only thought about IPv4: > On 22 Jan 2015, at 17:42, "Stefan Schiele" > wrote: > > The current policy actually had a positive effect on our company. The main reason for us to sign up as an LIR was to get more IPv4 addresses; and since we had to request an IPv6 allocation we wanted to have this set up and running. If it had been possible to get that /22 without an IPv6 address space we would probably still be using IPv4 only (the IPv4 address space we currently have is large enough for our business for the foreseeable future). > > Since this policy had a positive effect on IPv6 awareness for us I simply deduce that it should have a positive effect for some other companies as well. > On 22 Jan 2015, at 18:12, "Dave Wilson" > wrote: > Here's one example for this particular case: the number of v6 > assignments is not currently a useful measure of interest in IPv6, > because it's polluted by assignments to people who only applied because > they had to do so to get a /22. Don't get me wrong, good measurements are very valuable, but more valuable than increasing the actual number of IPv6 adoptions and usage? I think that should be the focus. > As Gert said, the RIPE NCC is asked to send very clear signals about > IPv6 to future applicants. Indeed the NCC is doing a very good job of promoting IPv6. However reality is many organisations live outside the RIPE bubble and just want a last IPv4 block. Giving them a free IPv6 allocation to go home and play with (immediately, or in time) kinda seems like a good thing to me. Kind regards, James Sent from my iPhone On 22 Jan 2015, at 18:12, "Dave Wilson" > wrote: Hello James, On 22/01/2015 12:38, Kennedy, James wrote: Wouldn't relaxing the text (as initially suggested) to require the LIR to have *any* form of IPv6, rather than removing it altogether, be more beneficial to general IPv6 adoption? I fear having no IPv6 requirement at all may encourage the LIR to look into alternatives, such as NAT or the transfer market. Honestly, I don't think it would, no. We'd get some anecdotes like we already have, but nothing systematic. This proposal looks harsh because all a proposal can do is changing the policy text and, taken on its own, that appears to be a negative change. Might as well do something, right? But "something is better than nothing" is just not effective; in fact the thrust of my talk at RIPE68 is that it's worse than useless. Here's one example for this particular case: the number of v6 assignments is not currently a useful measure of interest in IPv6, because it's polluted by assignments to people who only applied because they had to do so to get a /22. As Gert said, the RIPE NCC is asked to send very clear signals about IPv6 to future applicants. That's something that doesn't belong in the policy text, but is absolutely pertinent to this proposal, and my feeling is that it'll be an overall improvement. More importantly, it's something that can be worked on over time so that we do end up with a systematic improvement. (So to be clear: I support the policy as is in last call.) All the best, Dave -- Dave Wilson, Project Manager web: www.heanet.ie HEAnet Ltd, 5 George's Dock, IFSC, Dublin 1 tel: +353-1-660-9040 Registered in Ireland, no 275301 fax: +353-1-660-3666 From sander at steffann.nl Thu Jan 22 23:03:51 2015 From: sander at steffann.nl (Sander Steffann) Date: Thu, 22 Jan 2015 14:03:51 -0800 Subject: [address-policy-wg] [members-discuss] RIPE NCC Charging Scheme 2016 Discussion In-Reply-To: <54C0E980.9050404@titley.com> References: <54C0E980.9050404@titley.com> Message-ID: Hi Nigel, > 1. The Board can propose a Charging Scheme in advance of the May GM and > have the membership discuss the proposal. The Board would take the > discussion into account before proposing a final Charging Scheme to be > voted on by the membership in May. I would go for this option. Let's discuss what we (the members) want and let the board make the final proposal that we then vote on. If we are going to vote on individual issues the result might be an inconsistent charging scheme and it would prevent members from suggesting something that doesn't fit in the list of issues that are voted upon. I think having an open discussion and then trusting the board to come up with a good proposal will produce better results. Cheers, Sander From jkennedy at libertyglobal.com Thu Jan 22 23:05:16 2015 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Thu, 22 Jan 2015 22:05:16 +0000 Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <855D0B5A-681C-457E-AFA0-6FCF1EBCC092@upcbroadband.com> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <13E63C78A6256E4A857726374FBF926E127669A5@NLAMSPEXMB022.upcit.ds.upc.biz>, <54C12D2E.7000909@heanet.ie>, <855D0B5A-681C-457E-AFA0-6FCF1EBCC092@upcbroadband.com> Message-ID: <262C2D1F-8141-45C1-A19C-C60DC8C5B383@upcbroadband.com> Sorry for joining the discussion too late Gert, only caught my eye today :) Regards, James > On 22 Jan 2015, at 23:01, "Kennedy, James" wrote: > > Hi Dave, > > >> On 22 Jan 2015, at 18:12, "Dave Wilson" > wrote: >> >> This proposal looks harsh because all a proposal can do is changing the >> policy text and, taken on its own, that appears to be a negative change. >> Might as well do something, right? But "something is better than >> nothing" is just not effective; in fact the thrust of my talk at RIPE68 >> is that it's worse than useless. > > Sorry I missed your talk, sounds interesting. > I wouldn't say this proposal is negative, I just haven't read anyone explain how having an *any* IPv6 requirement negatively impacts IPv6 internet growth. How could it be worse than useless? Would it deter or slow a company's IPv6 adoption? I don't see how. In fact the IPv6 requirement in the current policy actually got Stefan Schiele's organisation on their unplanned road to v6, just like I said having their own v6 block may spark the interest of an organisation that previously only thought about IPv4: > >> On 22 Jan 2015, at 17:42, "Stefan Schiele" > wrote: >> >> The current policy actually had a positive effect on our company. The main reason for us to sign up as an LIR was to get more IPv4 addresses; and since we had to request an IPv6 allocation we wanted to have this set up and running. If it had been possible to get that /22 without an IPv6 address space we would probably still be using IPv4 only (the IPv4 address space we currently have is large enough for our business for the foreseeable future). >> >> Since this policy had a positive effect on IPv6 awareness for us I simply deduce that it should have a positive effect for some other companies as well. > > >> On 22 Jan 2015, at 18:12, "Dave Wilson" > wrote: >> Here's one example for this particular case: the number of v6 >> assignments is not currently a useful measure of interest in IPv6, >> because it's polluted by assignments to people who only applied because >> they had to do so to get a /22. > > Don't get me wrong, good measurements are very valuable, but more valuable than increasing the actual number of IPv6 adoptions and usage? I think that should be the focus. > > >> As Gert said, the RIPE NCC is asked to send very clear signals about >> IPv6 to future applicants. > > Indeed the NCC is doing a very good job of promoting IPv6. However reality is many organisations live outside the RIPE bubble and just want a last IPv4 block. Giving them a free IPv6 allocation to go home and play with (immediately, or in time) kinda seems like a good thing to me. > > > Kind regards, > James > > > Sent from my iPhone > > On 22 Jan 2015, at 18:12, "Dave Wilson" > wrote: > > Hello James, > > On 22/01/2015 12:38, Kennedy, James wrote: > Wouldn't relaxing the text (as initially suggested) to require the LIR to have *any* form of IPv6, rather than removing it altogether, be more beneficial to general IPv6 adoption? > I fear having no IPv6 requirement at all may encourage the LIR to look into alternatives, such as NAT or the transfer market. > > Honestly, I don't think it would, no. We'd get some anecdotes like we > already have, but nothing systematic. > > This proposal looks harsh because all a proposal can do is changing the > policy text and, taken on its own, that appears to be a negative change. > Might as well do something, right? But "something is better than > nothing" is just not effective; in fact the thrust of my talk at RIPE68 > is that it's worse than useless. > > Here's one example for this particular case: the number of v6 > assignments is not currently a useful measure of interest in IPv6, > because it's polluted by assignments to people who only applied because > they had to do so to get a /22. > > As Gert said, the RIPE NCC is asked to send very clear signals about > IPv6 to future applicants. That's something that doesn't belong in the > policy text, but is absolutely pertinent to this proposal, and my > feeling is that it'll be an overall improvement. More importantly, it's > something that can be worked on over time so that we do end up with a > systematic improvement. > > (So to be clear: I support the policy as is in last call.) > > All the best, > Dave > > -- > Dave Wilson, Project Manager web: www.heanet.ie > HEAnet Ltd, 5 George's Dock, IFSC, Dublin 1 tel: +353-1-660-9040 > Registered in Ireland, no 275301 fax: +353-1-660-3666 > > From tore at fud.no Fri Jan 23 08:53:11 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 23 Jan 2015 08:53:11 +0100 Subject: [address-policy-wg] [members-discuss] RIPE NCC Charging Scheme 2016 Discussion In-Reply-To: References: <54C0E980.9050404@titley.com> Message-ID: <20150123085311.5f1839ba@echo.ms.redpill-linpro.com> * Sander Steffann > > 1. The Board can propose a Charging Scheme in advance of the May GM > > and have the membership discuss the proposal. The Board would take > > the discussion into account before proposing a final Charging > > Scheme to be voted on by the membership in May. > > I would go for this option. Agreed. One piece of input for the initial proposal: The ASN charge is primarily intended as a means of discouraging hoarding, not to be a "cash cow" for the NCC. As such, the ideal situation would be that no one (who is not hoarding ASNs) would actually have to pay the charge. One way I believe this could be accomplished is that if you already pay the NCC membership fee or a PI fee, then you automatically get a reasonable quota of gratis ASNs. (Not automatic assignment of those ASNs, but that you won't get a separate charge until you have requested enough ASNs to exceed your quota.) This way, I think that the "one LIR, one fee" approach would hold true for the vast majority of the members. Tore From kaa at net-art.cz Fri Jan 23 00:36:03 2015 From: kaa at net-art.cz (sergey myasoedov) Date: Fri, 23 Jan 2015 00:36:03 +0100 Subject: [address-policy-wg] [members-discuss] RIPE NCC Charging Scheme 2016 Discussion In-Reply-To: References: <54C0E980.9050404@titley.com> Message-ID: <439171846.20150123003603@net-art.cz> Nigel, Sander, I would rather prefer option 2: > 2. The Board could take a two-step approach to the Charging Scheme. In > May, members would vote on individual issues such as charging for ASNs. > The result of the voting would then be used to create a Charging Scheme > that would be voted on in the usual way by members at the November GM. This approach is more balanced as for me and it allows to produce the charging scheme proposal that is better reflect the expectation of members. By the way, does the Board have any financial appraisal of proposed amendment of the Charging Scheme? -- Kind regards, Sergey Myasoedov You wrote Thursday, January 22, 2015, 11:03:51 PM: >> 1. The Board can propose a Charging Scheme in advance of the May GM and >> have the membership discuss the proposal. The Board would take the >> discussion into account before proposing a final Charging Scheme to be >> voted on by the membership in May. > I would go for this option. Let's discuss what we (the members) want and let the board > make the final proposal that we then vote on. If we are going to vote on individual > issues the result might be an inconsistent charging scheme and it would prevent members > from suggesting something that doesn't fit in the list of issues that are voted upon. I > think having an open discussion and then trusting the board to come up with a good proposal will produce better results. From juampe at cerezo.org Fri Jan 23 10:35:33 2015 From: juampe at cerezo.org (Juan P. Cerezo) Date: Fri, 23 Jan 2015 10:35:33 +0100 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: Message-ID: Hi, Marco, all. Support. Juan P. Cerezo > On 16 Jan 2015, at 14:49, Marco Schmidt wrote: > > The draft documents for version 3.0 of the policy proposal 2014-05, > "Policy for Inter-RIR Transfers of Internet Resources", have now been > published, along with an impact analysis conducted by the RIPE NCC. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ripe-ml-2012 at ssd.axu.tm Fri Jan 23 11:02:01 2015 From: ripe-ml-2012 at ssd.axu.tm (Aleksi Suhonen) Date: Fri, 23 Jan 2015 12:02:01 +0200 Subject: [address-policy-wg] 2014-04 using an IPv4 policy to force IPv6 adoption In-Reply-To: <54C0E13F.9090909@sct.de> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> Message-ID: <54C21C19.7040909@ssd.axu.tm> Hello, I'd like to state again, that sticking to the current policy is only hurting people that have already adopted IPv6 using PI space. "The bad guys" that aren't even planning to ever adopt IPv6 will happily reserve an IPv6 block just to get more IPv4 addresses. I hope this message gets across to the people who oppose 2014-04. You're not helping your own cause. For more information, read the archives of the 2014-04 discussion from last year. -- +358 4567 02048 / http://www.trex.fi/ Aleksi Suhonen / TREX Regional Exchanges Oy `What I need,' shouted Ford, by way of clarifying his previous remarks, `is a strong drink and a peer-group.' -- Douglas Adams, Life the Universe and Everything From d.baeza at tvt-datos.es Fri Jan 23 11:34:53 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Fri, 23 Jan 2015 11:34:53 +0100 Subject: [address-policy-wg] 2014-04 using an IPv4 policy to force IPv6 adoption In-Reply-To: <54C21C19.7040909@ssd.axu.tm> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <54C21C19.7040909@ssd.axu.tm> Message-ID: <54C223CD.7080803@tvt-datos.es> Hi Aleksi, > I'd like to state again, that sticking to the current policy is only > hurting people that have already adopted IPv6 using PI space. "The bad > guys" that aren't even planning to ever adopt IPv6 will happily reserve > an IPv6 block just to get more IPv4 addresses. And I state again, changing instead of removing the policy will make the same. Just allowing IPv6 PI space to be valid to request the IPv4 will do the same. And as stated before, lot of LIRs are adopting IPv6 only because the were forced to request an IPv6 Alloc. All those future LIRs who, as many cases, would go in for IPv6 only because they are forced to request the IPv6, with this removal, they wont do. Please, stop saying the removal is the only solution when, at least there is one solution much better than this. Of course, the community said yes so all we (the ones opposing) will accept as is. We are not going to ragequit. Consensous happens and, as we say here, it never rains please everyone. (Dont know if the translation is good, but for sure you all understand what I mean) Cheers, -- Daniel Baeza From jkennedy at libertyglobal.com Fri Jan 23 11:47:17 2015 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Fri, 23 Jan 2015 10:47:17 +0000 Subject: [address-policy-wg] 2014-04 using an IPv4 policy to force IPv6 adoption In-Reply-To: <54C21C19.7040909@ssd.axu.tm> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <54C21C19.7040909@ssd.axu.tm> Message-ID: <13E63C78A6256E4A857726374FBF926E127677D2@NLAMSPEXMB022.upcit.ds.upc.biz> Hi Aleksi, I don't think anyone wants to keep the policy as it is. I back the calls (albeit too late now in the policy process) to change the text so it includes organisations that have *any* IPv6, including PI. Simple really. James -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Aleksi Suhonen Sent: 23 January 2015 11:02 To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2014-04 using an IPv4 policy to force IPv6 adoption Hello, I'd like to state again, that sticking to the current policy is only hurting people that have already adopted IPv6 using PI space. "The bad guys" that aren't even planning to ever adopt IPv6 will happily reserve an IPv6 block just to get more IPv4 addresses. I hope this message gets across to the people who oppose 2014-04. You're not helping your own cause. For more information, read the archives of the 2014-04 discussion from last year. -- +358 4567 02048 / http://www.trex.fi/ Aleksi Suhonen / TREX Regional Exchanges Oy `What I need,' shouted Ford, by way of clarifying his previous remarks, `is a strong drink and a peer-group.' -- Douglas Adams, Life the Universe and Everything From stolpe at resilans.se Fri Jan 23 15:59:45 2015 From: stolpe at resilans.se (Daniel Stolpe) Date: Fri, 23 Jan 2015 15:59:45 +0100 (CET) Subject: [address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space) In-Reply-To: <54C12D2E.7000909@heanet.ie> References: <20150122105546.GD34798@Space.Net> <54C0E13F.9090909@sct.de> <13E63C78A6256E4A857726374FBF926E127669A5@NLAMSPEXMB022.upcit.ds.upc.biz> <54C12D2E.7000909@heanet.ie> Message-ID: On Thu, 22 Jan 2015, Dave Wilson wrote: > Hello James, > > On 22/01/2015 12:38, Kennedy, James wrote: >> Wouldn't relaxing the text (as initially suggested) to require the LIR to have *any* form of IPv6, rather than removing it altogether, be more beneficial to general IPv6 adoption? >> I fear having no IPv6 requirement at all may encourage the LIR to look into alternatives, such as NAT or the transfer market. > > Honestly, I don't think it would, no. We'd get some anecdotes like we > already have, but nothing systematic. > > This proposal looks harsh because all a proposal can do is changing the > policy text and, taken on its own, that appears to be a negative change. > Might as well do something, right? But "something is better than > nothing" is just not effective; in fact the thrust of my talk at RIPE68 > is that it's worse than useless. > > Here's one example for this particular case: the number of v6 > assignments is not currently a useful measure of interest in IPv6, > because it's polluted by assignments to people who only applied because > they had to do so to get a /22. > > As Gert said, the RIPE NCC is asked to send very clear signals about > IPv6 to future applicants. That's something that doesn't belong in the > policy text, but is absolutely pertinent to this proposal, and my > feeling is that it'll be an overall improvement. More importantly, it's > something that can be worked on over time so that we do end up with a > systematic improvement. > > (So to be clear: I support the policy as is in last call.) +1 Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From gert at space.net Sun Jan 25 20:56:34 2015 From: gert at space.net (Gert Doering) Date: Sun, 25 Jan 2015 20:56:34 +0100 Subject: [address-policy-wg] [members-discuss] RIPE NCC Charging Scheme 2016 Discussion In-Reply-To: <20150123085311.5f1839ba@echo.ms.redpill-linpro.com> References: <54C0E980.9050404@titley.com> <20150123085311.5f1839ba@echo.ms.redpill-linpro.com> Message-ID: <20150125195634.GY34798@Space.Net> Hi, On Fri, Jan 23, 2015 at 08:53:11AM +0100, Tore Anderson wrote: > One way I believe this could be accomplished is that if you already > pay the NCC membership fee or a PI fee, then you automatically get a > reasonable quota of gratis ASNs. (Not automatic assignment of those > ASNs, but that you won't get a separate charge until you have requested > enough ASNs to exceed your quota.) This would work for me. Agreeing with Tore that this is not supposed to bring in additional revenue, and also not supposed to punish/hurt LIRs that make good use of their ASNs - but to be an incentive to return (or trade away) unused ASNs to make them used again, and to prevent useless hoarding which would burn NCC resources. Gert Doering -- RIPE member, and interested in good resource management -- 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 Mon Jan 26 10:38:46 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 26 Jan 2015 10:38:46 +0100 Subject: [address-policy-wg] 2014-12 Review Phase Period extended until 10 February 2015 (Allow IPv6 Transfers) Message-ID: Dear colleagues, The Review Phase Period for the proposal 2014-12, "Allow IPv6 Transfers" has been extended until 10 February 2015. We request your feedback, even if you have provided it during the initial Discussion Phase, so that the Working Group Chairs can determine whether there is rough consensus. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-12 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt Policy Development Officer RIPE NCC From ak at list.ak.cx Mon Jan 26 10:54:24 2015 From: ak at list.ak.cx (Andre Keller) Date: Mon, 26 Jan 2015 10:54:24 +0100 Subject: [address-policy-wg] 2014-12 Review Phase Period extended until 10 February 2015 (Allow IPv6 Transfers) In-Reply-To: References: Message-ID: <54C60ED0.2060703@list.ak.cx> On 26.01.2015 10:38, Marco Schmidt wrote: > We request your feedback, even if you have provided it during the initial > Discussion Phase, so that the Working Group Chairs can determine whether > there is rough consensus. Support Regards Andr? From andreas.vogler at geneon.de Mon Jan 26 11:11:53 2015 From: andreas.vogler at geneon.de (Andreas Vogler) Date: Mon, 26 Jan 2015 11:11:53 +0100 Subject: [address-policy-wg] 2014-12 Review Phase Period extended until 10 February 2015 (Allow IPv6 Transfers) In-Reply-To: References: Message-ID: <27CE2179D1925A4F9F4874725C3B4E0FB7DED14354@COSMOS.nbg.geneon.de> I support this proposal. Andreas Vogler -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Marco Schmidt Gesendet: Montag, 26. Januar 2015 10:39 An: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Betreff: [address-policy-wg] 2014-12 Review Phase Period extended until 10 February 2015 (Allow IPv6 Transfers) Dear colleagues, The Review Phase Period for the proposal 2014-12, "Allow IPv6 Transfers" has been extended until 10 February 2015. We request your feedback, even if you have provided it during the initial Discussion Phase, so that the Working Group Chairs can determine whether there is rough consensus. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-12 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt Policy Development Officer RIPE NCC From salvatore.sciacco at cdlan.it Mon Jan 26 11:14:04 2015 From: salvatore.sciacco at cdlan.it (Salvatore Sciacco) Date: Mon, 26 Jan 2015 11:14:04 +0100 Subject: [address-policy-wg] 2014-12 Review Phase Period extended until 10 February 2015 (Allow IPv6 Transfers) In-Reply-To: References: Message-ID: 2015-01-26 10:38 GMT+01:00 Marco Schmidt : > We request your feedback, even if you have provided it during the initial > Discussion Phase, so that the Working Group Chairs can determine whether > there is rough consensus. > Support Best, S. -- Salvatore Sciacco Cdlan S.r.l. - Via Pergolesi 16 - I-20124 Milano Tel. +39.02.6706800 Fax +39.02.67100856 P.IVA: 13064680153 - Cap. soc.: 115.000EUR i.v. - REA: MI-1614446 AVVISO DI RISERVATEZZA - Questo messaggio e' ad uso esclusivo dei destinatari e contiene informazioni riservate. Se lo avete ricevuto per errore, vi preghiamo di cancellarlo immediatamente e di non rivelare ne' diffondere i suoi contenuti. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eva at telia.net Tue Jan 27 08:48:35 2015 From: eva at telia.net (=?windows-1252?Q?=22=D6rnberg=2C_Eva_E=2E=22?=) Date: Tue, 27 Jan 2015 08:48:35 +0100 Subject: [address-policy-wg] 2014-12 Review Phase Period extended until 10 February 2015 (Allow IPv6 Transfers) In-Reply-To: References: Message-ID: <54C742D3.8040703@telia.net> support BR /// Eva Registry TeliaNet On 2015-01-26 10:38, Marco Schmidt wrote: > Dear colleagues, > > > The Review Phase Period for the proposal 2014-12, "Allow IPv6 Transfers" > has been extended until 10 February 2015. > > We request your feedback, even if you have provided it during the initial > Discussion Phase, so that the Working Group Chairs can determine whether > there is rough consensus. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-12 > > > We encourage you to review this policy proposal and send your comments > to . > > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > From mschmidt at ripe.net Wed Jan 28 10:41:41 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 28 Jan 2015 10:41:41 +0100 Subject: [address-policy-wg] 2014-03 Review Period extended until 12 February 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 12 February 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