From rgori at wirem.net Fri Apr 3 16:46:33 2015 From: rgori at wirem.net (Riccardo Gori) Date: Fri, 03 Apr 2015 16:46:33 +0200 Subject: [address-policy-wg] 2015-01 New Policy Proposal (Alignment ofTransfer Requirements for IPv4 Allocations) Message-ID: <551EA7C9.1060101@wirem.net> Hi everybody, This policy proposal gets +1 support from me, a rookie. My little experience is so recent but so clear: RIPE wants to burn out this resources or at least make this resources available does not matter to who. Maybe someone thinks this way will be the IPv6 time or maybe someone owns a lot of resources and wants to make much more money from them for a while... don't know. Too young in this to understand, anyway this looks to me slightly far from the spirit of the last /8 policy I read. I think the support of the policy would be correct but it can certainly higher the market price and if there is no way to stop big player this could be converted in a mess. Thee proposal is a good start but I think the community needs something better. I would go this way: - approve 24 months holding time - forbid companies (not LIRs) holding more than one /22 if they already hold resources before allocated before /8 policy Older resource holder allocated before /8 policy had the chance in the past to request resources for sligtly lower costs. They are in the market and they have experience in routing and managin IPs, they should (must) start IPv6 deployment as an example for others. kind regards Riccardo Gori From sander at steffann.nl Tue Apr 7 12:02:38 2015 From: sander at steffann.nl (Sander Steffann) Date: Tue, 7 Apr 2015 12:02:38 +0200 Subject: [address-policy-wg] Working group chair selection process: consensus Message-ID: <88518808-41D3-4F09-A568-95BD829D8FA3@steffann.nl> Hi working group, The last call for the working group chair selection process has ended and no further comments were received. Therefore the working group chairs hereby declare consensus for the process. Cheers, Sander & Gert From sander at steffann.nl Tue Apr 7 12:08:17 2015 From: sander at steffann.nl (Sander Steffann) Date: Tue, 7 Apr 2015 12:08:17 +0200 Subject: [address-policy-wg] Working group chair rotation 1 Message-ID: Hello working group, As we now have a working group chair rotation/selection process in place it is time to start that process for the first time! After long deliberation (a.k.a. a random number generator) we have decided that Gert is going to be the first chair to step down. He will do so at the upcoming RIPE meeting (RIPE 70 in Amsterdam). He has also volunteered again and is therefore our first candidate. If anybody else wants to volunteer then please make yourself known on this mailing list before the start of RIPE 70. Cheers, Sander & Gert From gert at space.net Tue Apr 7 12:42:27 2015 From: gert at space.net (Gert Doering) Date: Tue, 7 Apr 2015 12:42:27 +0200 Subject: [address-policy-wg] Working group chair rotation 1 In-Reply-To: References: Message-ID: <20150407104227.GK54385@Space.Net> Hi, On Tue, Apr 07, 2015 at 12:08:17PM +0200, Sander Steffann wrote: > As we now have a working group chair rotation/selection process > in place it is time to start that process for the first time! After > long deliberation (a.k.a. a random number generator) we have decided > that Gert is going to be the first chair to step down. He will do > so at the upcoming RIPE meeting (RIPE 70 in Amsterdam). He has also > volunteered again and is therefore our first candidate. So, you can hear it from myself - I'm still willing to serve as APWG chair for at least one additional round of two years. This is important work, and it is still fun (most of the time), so here I am. The whole WG chair rotation(-or-not) thing will be done by Sander, so I'll abstain on anything formal. Gert Doering -- still 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 Apr 7 13:58:03 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 7 Apr 2015 13:58:03 +0200 Subject: [address-policy-wg] Working group chair rotation 1 In-Reply-To: <20150407104227.GK54385@Space.Net> References: <20150407104227.GK54385@Space.Net> Message-ID: <00ee01d0712a$1fe1a0f0$5fa4e2d0$@a2b-internet.com> Hi Gert, Are you going to formally introduce yourself to the mailing list for those that might not know who you are and what your shoe size is ? And can we expect the usual election talks / promises on where we are going in the next period with you at the helm ... Personally I would like to know what we are getting ourselves into ... ;) Regards, Erik From gert at space.net Tue Apr 7 14:26:35 2015 From: gert at space.net (Gert Doering) Date: Tue, 7 Apr 2015 14:26:35 +0200 Subject: [address-policy-wg] Working group chair rotation 1 In-Reply-To: <00ee01d0712a$1fe1a0f0$5fa4e2d0$@a2b-internet.com> References: <20150407104227.GK54385@Space.Net> <00ee01d0712a$1fe1a0f0$5fa4e2d0$@a2b-internet.com> Message-ID: <20150407122635.GQ54385@Space.Net> Hi, On Tue, Apr 07, 2015 at 01:58:03PM +0200, Erik Bais wrote: > Are you going to formally introduce yourself to the mailing list for those > that might not know who you are and what your shoe size is ? > > And can we expect the usual election talks / promises on where we are going > in the next period with you at the helm ... > > Personally I would like to know what we are getting ourselves into ... ;) Well, if you ask so nicely :-) - here's the short form Gert Doering * age 42 * shoe size 47, preferrably wearing sandals * university diploma in physics, but into networking since about 22 years * the ISP I work for is SpaceNet, AS5539 - a regional ISP in Munich, DE, who provides mostly "datacenter" and "managed hosting" services these days (but used to provide access, so I know both sides of the medal) * hands-on-geek - network, peering, unix admin - and long-time LIR contact, so I know both the operational side of "IP networks" and the bureaucracy side of "I want a Class C network!" - "here's a /29" haggling. * attending RIPE meetings since RIPE 24 in Berlin, 1996 (missing two since then, Dublin I and Prague II) * address policy working group co-chair since RIPE 44 in Amsterdam, 2003 (https://www.ripe.net/ripe/meetings/ripe-meetings/ripe-44/meeting-report) - then still called the "LIR working group". And now for the future plans * listen to the community and to the RIPE NCC RS on where current policy causes avoidable friction * guide policy proposals through the PDP, finding ways that solve the problem at hand *and* get consensus from the community (or accepting failure if something is just not agreeable) * and *not* having personal ambitions here besides "help in creating policy that is easy to follow, distributes resources in a as-fair-as-possible way, and is good for the Internet" I think the last part is especially important: the APWG chairs should *not* follow their own agenda, but help and guide the community in agreeing on policy. While I do have opinions (galore!), as the AP WG chair, it's not my job to push for my personal goals. Of course there is: * find and push volunteers to actually write up policy documents that reflect what was discussed at RIPE meetings, so things are not forgotten but followed through :-) Basically - I intend to continue doing what I've done the last couple of years. "Continuity in this space". Eventually, I expect to wind down the AP WG as we'll have achieved a point where policy is perfect, and we do not need to have the WG actively meet every meeting anymore. But this is still some time away. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 sander at steffann.nl Tue Apr 7 18:35:36 2015 From: sander at steffann.nl (Sander Steffann) Date: Tue, 7 Apr 2015 18:35:36 +0200 Subject: [address-policy-wg] 2014-05 - end of last call (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <20150303123930.GA98671@Space.Net> References: <20150303123930.GA98671@Space.Net> Message-ID: <1BA90D61-9311-4B43-AB80-8733B03926EC@steffann.nl> Hello working group, The last call period for proposal 2014-05 (Policy for Inter-RIR Transfers of Internet Resources) has ended. In this phase no new feedback has been sent to the working group and the working group chairs have therefore concluded that the consensus as previously announced (see below) still stands. We ask the RIPE NCC to go ahead and implement this policy. Cheers, Your working group chairs Gert & Sander > Op 3 mrt. 2015, om 13:39 heeft Gert Doering het volgende geschreven: > > Dear AP WG, > > the review phase for 2014-05 has ended. > > While this proposal has taken quite a while to come to a conclusion, we > seem to have quite strong support and no opposition now - nine persons > spoke up in support of the proposal, and no other comments of any sort have > been received. > > So, I declare we have consensus, and move 2014-05 to Last Call. Marco > will send the formal announcement for that in the next days. > > For reference, a list of people that voiced support or opposition (or > something else) in the previous review phase is appended below. This is > what I have based my decision on. > > If you disagree with my interpretation of what has been said and the > conclusion I have drawn from it, please let us know. > > Gert Doering, > Address Policy WG Chair > > > Review Phase for V3.0, starting Jan 16, 2015 > > Support: > > Mick O'Donovan > Steve Wright (3 times!) > Tore Anderson > (some editorial gripes, but postponed addressing them in the unified > transfer policy document showing on the horizon) > Elvis Daniel Velea > Mike Burns > Guy Chilton > Duncan Scotland > Juan P. Cerezo > Hamed Shafaghi > > Comments, Opposition: > > - > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From mschmidt at ripe.net Thu Apr 9 16:31:38 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 09 Apr 2015 16:31:38 +0200 Subject: [address-policy-wg] 2014-05 Proposal Accepted (Policy for Inter-RIR Transfers of Internet Resources) Message-ID: Dear colleagues, Consensus has been reached, and the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources" has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-05 The new RIPE Document is ripe-644 and is available at: https://www.ripe.net/ripe/docs/ripe-644 The proposal also amended the policies described in the RIPE Document "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". The new RIPE Document is ripe-643 and is available at: https://www.ripe.net/ripe/docs/ripe-643 We have already begun the implementation and will start with our procedures, including the necessary coordination with the other RIRs. The technical implementation will start in around one month's time, as it needs to link with the ongoing implementation of the recently accepted IPv6 and ASN transfer policies. We estimate that it will take about four months to fully implement this proposal. Details of the implementation status are available at: https://www.ripe.net/lir-services/resource-management/policy-implementation-status We will send another announcement when the implementation is finished and the new procedures are in place. Thank you to everyone who provided their input. Regards Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Tue Apr 14 11:28:37 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 14 Apr 2015 11:28:37 +0200 Subject: [address-policy-wg] 2015-01 Impact Analysis will be produced (Alignment of Transfer Requirements for IPv4 Allocations) Message-ID: Dear colleagues, The discussion period for the proposal described in 2015-01, "Alignment of Transfer Requirements for IPv4 Allocations" has ended. The RIPE NCC Impact Analysis will now be prepared for review. We will publish the document shortly and we will make an announcement. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-01 Regards Marco Schmidt Policy Development Officer RIPE NCC From d.baeza at tvt-datos.es Tue Apr 14 11:35:22 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Tue, 14 Apr 2015 11:35:22 +0200 Subject: [address-policy-wg] 2015-01 Impact Analysis will be produced (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: <552CDF5A.7090307@tvt-datos.es> Hi, Thats means policy is approved? Regards, El 14/04/2015 a las 11:28, Marco Schmidt escribi?: > Dear colleagues, > > The discussion period for the proposal described in 2015-01, > "Alignment of Transfer Requirements for IPv4 Allocations" has ended. > > The RIPE NCC Impact Analysis will now be prepared for review. We will publish the > document shortly and we will make an announcement. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-01 > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > -- 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 tom at kebab.org.pl Tue Apr 14 11:48:27 2015 From: tom at kebab.org.pl (-TOM-) Date: Tue, 14 Apr 2015 11:48:27 +0200 Subject: [address-policy-wg] 2015-01 Impact Analysis will be produced (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <552CDF5A.7090307@tvt-datos.es> References: <552CDF5A.7090307@tvt-datos.es> Message-ID: <552CE26B.5010900@kebab.org.pl> Not yet, Daniel. Best regards Tomasz ?l?ski W dniu 2015-04-14 o 11:35, Daniel Baeza (Red y Sistemas TVT) pisze: > Hi, > > Thats means policy is approved? > > Regards, > > El 14/04/2015 a las 11:28, Marco Schmidt escribi?: >> Dear colleagues, >> >> The discussion period for the proposal described in 2015-01, >> "Alignment of Transfer Requirements for IPv4 Allocations" has ended. >> >> The RIPE NCC Impact Analysis will now be prepared for review. We will >> publish the >> document shortly and we will make an announcement. >> >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2015-01 >> >> Regards >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> > From gert at space.net Tue Apr 14 11:56:10 2015 From: gert at space.net (Gert Doering) Date: Tue, 14 Apr 2015 11:56:10 +0200 Subject: [address-policy-wg] 2015-01 Impact Analysis will be produced (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <552CDF5A.7090307@tvt-datos.es> References: <552CDF5A.7090307@tvt-datos.es> Message-ID: <20150414095610.GX54385@Space.Net> Hi, On Tue, Apr 14, 2015 at 11:35:22AM +0200, Daniel Baeza (Red y Sistemas TVT) wrote: > Thats means policy is approved? It means what it says: the *discussion phase* is over, and we're now moving to the next phase in the policy development process: impact analysis, and based on that, review phase. After that, if we have consensus, we go to "last call", and *then* we can get to "approved". The requirements to move from discussion to IA/review phase are fairly low - "some amount of support from the WG, not so much opposition" - it was a bit on the edge this time (as there was quite some opposition), but since we do not have to declare consensus yet, and there *was* support, going forward is possible. 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 Tue Apr 14 14:52:58 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 14 Apr 2015 14:52:58 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) Message-ID: Dear colleagues, A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" is now available for discussion. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-02 We encourage you to review this proposal and send your comments to before 13 May 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC From gert at space.net Tue Apr 14 18:10:07 2015 From: gert at space.net (Gert Doering) Date: Tue, 14 Apr 2015 18:10:07 +0200 Subject: [address-policy-wg] RIPE70 meeting agenda, draft 1 Message-ID: <20150414161007.GA54385@Space.Net> Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Amsterdam in the following time slots: Wednesday, May 13, 09:00 - 10:30 Wednesday, May 13, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. So far, the agenda is fairly light - if you have something you want to address, or that bothers you, let us know and we make room for you :-) The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) B. WG Chair Selection Process [15 min?] - presenting the current draft document - discussion C. Current Policy Topics - Marco Schmidt, NCC PDO [15-20 min] - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE69 2014-04 Removing IPv6 Requirement for Receiving Space from the Final /8 (consensus, policy) 2014-05 Policy for Inter-RIR Transfers of Internet Resources (consensus, policy) 2014-07 Language Clarification 2014-08 Language Clarification 2014-10 Language Clarification 2014-11 Language Clarification (consensus, policy) 2014-09 Language Clarification in "IPv6 Address Space for IXPs" **no consensus, withdrawn** 2014-12 Allow IPv6 Transfers (consensus, policy) 2014-13 Allow AS Number Transfers (consensus, policy) - brief overview over new proposals (if any) D. Feedback From NCC Registration Service - Andrea Cima (NCC RS) [10-15 min] (+ discussion with the group) F. Discussion of open policy proposals 2014-03 Remove Multihoming Requirement for AS Number .. (Job Snijders) 2015-01 Alignment of Transfer Requirements for IPv4 Allocations (Elvis Velea) [some bits might get moved to "after coffee break" if we run out of time] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back F. Discussion of open policy proposals [60 min?] 2015-02 Keep IPv6 PI When Requesting IPv6 Allocation (James Kennedy) N.N. "On IPv6 Allocation Criteria" (no formal proposal yet) G. New Ideas under Discussion - Elvis Daniel Velea - change size of last /22 allocations Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." Z. AOB Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 Apr 14 18:25:05 2015 From: gert at space.net (Gert Doering) Date: Tue, 14 Apr 2015 18:25:05 +0200 Subject: [address-policy-wg] RIPE70 meeting agenda, draft 1 In-Reply-To: <552D3E38.8050207@boeddinghaus.de> References: <20150414161007.GA54385@Space.Net> <552D3E38.8050207@boeddinghaus.de> Message-ID: <20150414162505.GC54385@Space.Net> Hi, On Tue, Apr 14, 2015 at 06:20:08PM +0200, Wilhelm Boeddinghaus wrote: > is the election of a new chair or reelection of the current chair part > of "B. WG Chair Selection Process " ? Uh. Lazy me, that's what you get from copying over previous agendas and only glancing over some of the "regular items". Yes, B. is actually "WG chair selection". I'll update. > > B. WG Chair Selection Process [15 min?] > > - presenting the current draft document > > - discussion B. WG Chair Selection - longest-serving chair (Gert Doering) stepping down - willing to be re-appointed and serve another term *sigh* Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 wilhelm at boeddinghaus.de Tue Apr 14 18:20:08 2015 From: wilhelm at boeddinghaus.de (Wilhelm Boeddinghaus) Date: Tue, 14 Apr 2015 18:20:08 +0200 Subject: [address-policy-wg] RIPE70 meeting agenda, draft 1 In-Reply-To: <20150414161007.GA54385@Space.Net> References: <20150414161007.GA54385@Space.Net> Message-ID: <552D3E38.8050207@boeddinghaus.de> Hi Gert, is the election of a new chair or reelection of the current chair part of "B. WG Chair Selection Process " ? Thanks, Wilhelm Am 14.04.2015 um 18:10 schrieb Gert Doering: > Hi APWG folks, RIPE meeting orga, > > below you can find a draft for the RIPE address policy WG meeting's agenda, > which will take place in Amsterdam in the following time slots: > > Wednesday, May 13, 09:00 - 10:30 > Wednesday, May 13, 11:00 - 12:30 > > If you have anything else you want to see on the agenda, or if we need > to change anything, please let us know. So far, the agenda is fairly > light - if you have something you want to address, or that bothers you, > let us know and we make room for you :-) > > The distribution of items to the two timeslot is somewhat subject to > the time spent on discussion - but we'll try to stick to what's published. > > regards, > > Gert Doering, > APWG chair > > > ---------------------------------------------------------------------- > Wednesday, 09:00-10:30 > ---------------------------------------------------------------------- > > A. Administrative Matters 5 min > (welcome, thanking the scribe, approving the minutes, etc.) > > B. WG Chair Selection Process [15 min?] > - presenting the current draft document > - discussion > > C. Current Policy Topics - Marco Schmidt, NCC PDO [15-20 min] > > - global policy overview > "what's going on?" > > - common policy topics in all regions > (end of IPv4, transfers, ...) > > - overview over concluded proposals in the RIPE region since RIPE69 > > 2014-04 Removing IPv6 Requirement for Receiving Space from the Final /8 > (consensus, policy) > > 2014-05 Policy for Inter-RIR Transfers of Internet Resources > (consensus, policy) > > 2014-07 Language Clarification > 2014-08 Language Clarification > 2014-10 Language Clarification > 2014-11 Language Clarification > (consensus, policy) > > 2014-09 Language Clarification in "IPv6 Address Space for IXPs" > **no consensus, withdrawn** > > 2014-12 Allow IPv6 Transfers > (consensus, policy) > > 2014-13 Allow AS Number Transfers > (consensus, policy) > > > - brief overview over new proposals (if any) > > > D. Feedback From NCC Registration Service - Andrea Cima (NCC RS) [10-15 min] > (+ discussion with the group) > > > F. Discussion of open policy proposals > > 2014-03 Remove Multihoming Requirement for AS Number .. > (Job Snijders) > > 2015-01 Alignment of Transfer Requirements for IPv4 Allocations > (Elvis Velea) > > [some bits might get moved to "after coffee break" if we run out of time] > > > ---------------------------------------------------------------------- > Wednesday, 11:00-12:30 > ---------------------------------------------------------------------- > > Welcome back > > > > F. Discussion of open policy proposals [60 min?] > > 2015-02 Keep IPv6 PI When Requesting IPv6 Allocation (James Kennedy) > > N.N. "On IPv6 Allocation Criteria" (no formal proposal yet) > > > G. New Ideas under Discussion > > - Elvis Daniel Velea - change size of last /22 allocations > > > Y. Open Policy Hour > > "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you > have a policy proposal you'd like to debut, prior to formally submitting > it, here is your opportunity." > > Z. AOB > > Gert Doering > -- NetMaster From nick at inex.ie Wed Apr 15 09:48:10 2015 From: nick at inex.ie (Nick Hilliard) Date: Wed, 15 Apr 2015 09:48:10 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <552E17BA.9060003@inex.ie> Looks good to me. Support. Nick On 14/04/2015 14:52, Marco Schmidt wrote: > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > From salvatore.sciacco at cdlan.it Wed Apr 15 10:44:21 2015 From: salvatore.sciacco at cdlan.it (Salvatore Sciacco) Date: Wed, 15 Apr 2015 10:44:21 +0200 Subject: [address-policy-wg] [policy-announce] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: Support. Best, S. 2015-04-14 14:52 GMT+02:00 Marco Schmidt : > > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment > Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > > -- 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 d.baeza at tvt-datos.es Wed Apr 15 10:46:34 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Wed, 15 Apr 2015 10:46:34 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <552E256A.9060105@tvt-datos.es> Support! El 14/04/2015 a las 14:52, Marco Schmidt escribi?: > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > -- 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 Alexander.Koeppe at merckgroup.com Wed Apr 15 10:40:06 2015 From: Alexander.Koeppe at merckgroup.com (Alexander.Koeppe at merckgroup.com) Date: Wed, 15 Apr 2015 08:40:06 +0000 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: <552E17BA.9060003@inex.ie> References: <552E17BA.9060003@inex.ie> Message-ID: <3922dfa5173c41b698cab4f45b70b2c2@de35s02aexc05.ucc.merckgroup.com> +1 Alexander K?ppe -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Nick Hilliard Gesendet: Mittwoch, 15. April 2015 09:48 An: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) Looks good to me. Support. Nick On 14/04/2015 14:52, Marco Schmidt wrote: > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.merckgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer. From elvis at velea.eu Wed Apr 15 10:56:01 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Wed, 15 Apr 2015 01:56:01 -0700 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: <552E17BA.9060003@inex.ie> References: <552E17BA.9060003@inex.ie> Message-ID: <552E27A1.5020700@velea.eu> On 15/04/15 00:48, Nick Hilliard wrote: > Looks good to me. Support. > > Nick clean and simple. this should have been done years ago +1 from me too /elvis > > On 14/04/2015 14:52, Marco Schmidt wrote: >> Dear colleagues, >> >> A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" >> is now available for discussion. >> >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2015-02 >> >> We encourage you to review this proposal and send your comments to >> before 13 May 2015. >> >> Regards >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> > From m.pels at tech.leaseweb.com Wed Apr 15 10:58:10 2015 From: m.pels at tech.leaseweb.com (Martin Pels) Date: Wed, 15 Apr 2015 10:58:10 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <20150415105810.1708fb60@pels-Latitude-E5450> ?I support this proposal. Kind regards, Martin On Tue, 14 Apr 2015 14:52:58 +0200 Marco Schmidt wrote: > > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and > Assignment Policy" is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Kind regards, Martin Pels CDN Network Engineer LeaseWeb Technologies B.V. T: +31 20 316 0235 M: E: m.pels at tech.leaseweb.com W: http://www.leaseweb.com Luttenbergweg 8, 1101 EC?Amsterdam,?Netherlands From ripe at opteamax.de Wed Apr 15 11:06:47 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Wed, 15 Apr 2015 11:06:47 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: <552E27A1.5020700@velea.eu> References: <552E17BA.9060003@inex.ie> <552E27A1.5020700@velea.eu> Message-ID: <552E2A27.3070707@opteamax.de> fully supported - better confirm it today than tomorrow ;) ... I just went to the shit of renumbering to return my IPv6-PI a couple of weeks ago, and it took several workingdays - I really would have known better stuff to do! BR Jens On 15.04.2015 10:56, Elvis Daniel Velea wrote: > On 15/04/15 00:48, Nick Hilliard wrote: >> Looks good to me. Support. >> >> Nick > clean and simple. this should have been done years ago > > +1 from me too > > /elvis > >> >> On 14/04/2015 14:52, Marco Schmidt wrote: >>> Dear colleagues, >>> >>> A proposed change to RIPE Document "IPv6 Address Allocation and >>> Assignment Policy" >>> is now available for discussion. >>> >>> You can find the full proposal at: >>> >>> https://www.ripe.net/participate/policies/proposals/2015-02 >>> >>> We encourage you to review this proposal and send your comments to >>> before 13 May 2015. >>> >>> Regards >>> >>> Marco Schmidt >>> Policy Development Officer >>> RIPE NCC >>> >>> >> > > > > !DSPAM:637,552e294e83703762487508! > -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From LIR at bva.bund.de Wed Apr 15 11:10:43 2015 From: LIR at bva.bund.de (LIR (BIT I 5)) Date: Wed, 15 Apr 2015 09:10:43 +0000 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: <552E17BA.9060003@inex.ie> Message-ID: I also would support this proposal. Regards Carsten -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Nick Hilliard Gesendet: Mittwoch, 15. April 2015 09:48 An: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) Looks good to me. Support. Nick On 14/04/2015 14:52, Marco Schmidt wrote: > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > From ripe-wgs at radu-adrian.feurdean.net Wed Apr 15 12:02:05 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 15 Apr 2015 12:02:05 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <1429092125.4157043.253999021.38C186E3@webmail.messagingengine.com> On Tue, Apr 14, 2015, at 14:52, Marco Schmidt wrote: > A proposed change to RIPE Document "IPv6 Address Allocation and > Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 Support. However, note that this policy is the "better solution" to a problem initially solved by 2014-04. From wilhelm at boeddinghaus.de Wed Apr 15 12:19:13 2015 From: wilhelm at boeddinghaus.de (Wilhelm Boeddinghaus) Date: Wed, 15 Apr 2015 12:19:13 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <552E3B21.1060204@boeddinghaus.de> Support. Wilhelm Am 14.04.2015 um 14:52 schrieb Marco Schmidt: > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > From stolpe at resilans.se Wed Apr 15 15:30:53 2015 From: stolpe at resilans.se (Daniel Stolpe) Date: Wed, 15 Apr 2015 15:30:53 +0200 (CEST) Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: <552E17BA.9060003@inex.ie> References: <552E17BA.9060003@inex.ie> Message-ID: On Wed, 15 Apr 2015, Nick Hilliard wrote: > Looks good to me. Support. +1. > Nick > > On 14/04/2015 14:52, Marco Schmidt wrote: >> Dear colleagues, >> >> A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" >> is now available for discussion. >> >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2015-02 >> >> We encourage you to review this proposal and send your comments to >> before 13 May 2015. >> >> Regards >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> > > > 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 ripe.address-policy-wg at ml.karotte.org Wed Apr 15 15:26:53 2015 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Wed, 15 Apr 2015 15:26:53 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <20150415132653.GI8672@danton.fire-world.de> * Marco Schmidt [2015-04-14 15:06]: > > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. Support. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 616 bytes Desc: Digital signature URL: From ak at list.ak.cx Wed Apr 15 15:54:52 2015 From: ak at list.ak.cx (Andre Keller) Date: Wed, 15 Apr 2015 15:54:52 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <552E6DAC.3060501@list.ak.cx> On 14.04.2015 14:52, Marco Schmidt wrote: > We encourage you to review this proposal support From modonovan at btireland.net Thu Apr 16 01:03:21 2015 From: modonovan at btireland.net (Mick O'Donovan) Date: Thu, 16 Apr 2015 00:03:21 +0100 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <20150415230321.GA32517@carra.btireland.net> On Tue, Apr 14, 2015 at 02:52:58PM +0200, Marco Schmidt wrote: > > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > +1 from me too. Logical step. -- Mick O'Donovan | Network Engineer | BT Ireland | 27 Willsborough Industrial Estate, Clonshaugh, Dublin 17. http://www.btireland.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: Digital signature URL: From tom at kebab.org.pl Thu Apr 16 10:40:13 2015 From: tom at kebab.org.pl (-TOM-) Date: Thu, 16 Apr 2015 10:40:13 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <552F756D.5080404@kebab.org.pl> +1, Support Tomasz ?l?ski W dniu 2015-04-14 o 14:52, Marco Schmidt pisze: > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > From Woeber at CC.UniVie.ac.at Thu Apr 16 18:01:52 2015 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 16 Apr 2015 18:01:52 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <552FDCF0.9070402@CC.UniVie.ac.at> Marco Schmidt wrote: > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. I fully support the proposal. I'd like to add a particular comment related to the potential increase of the global routing table: If that would be a real-world issue, the IP4 world would have startd to deal with that "waste" years ago. The information about possible improvement has been regularly available since ages. Regards, Wilfried > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > From apwg at c4inet.net Thu Apr 16 17:36:07 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Thu, 16 Apr 2015 16:36:07 +0100 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: <552E17BA.9060003@inex.ie> References: <552E17BA.9060003@inex.ie> Message-ID: <20150416153607.GE1012@cilantro.c4inet.net> On Wed, Apr 15, 2015 at 09:48:10AM +0200, Nick Hilliard wrote: >Looks good to me. Support. +1 rgds, Sascha Luck From bjornr at isnic.is Thu Apr 16 19:55:26 2015 From: bjornr at isnic.is (=?utf-8?Q?Bj=C3=B6rn_R=C3=B3bertsson?=) Date: Thu, 16 Apr 2015 17:55:26 +0000 (GMT) Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <25576085.237346.1429206926625.JavaMail.zimbra@sirona.isnic.is> +1 ----- Original Message ----- > From: "Marco Schmidt" > To: policy-announce at ripe.net > Cc: address-policy-wg at ripe.net > Sent: Tuesday, 14 April, 2015 12:52:58 PM > Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) > > > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment > Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > > From nigel at titley.com Thu Apr 16 20:09:46 2015 From: nigel at titley.com (Nigel Titley) Date: Thu, 16 Apr 2015 19:09:46 +0100 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <552FFAEA.2030603@titley.com> On 14/04/15 13:52, Marco Schmidt wrote: > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Sounds very sensible. Support Nigel From ripe-wgs.cs at schiefner.de Fri Apr 17 11:27:20 2015 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 17 Apr 2015 11:27:20 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <5530D1F8.10301@schiefner.de> Support. On 14.04.2015 14:52, Marco Schmidt wrote: > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC From flo at degnet.de Sat Apr 18 23:09:52 2015 From: flo at degnet.de (Florian Fuessl) Date: Sat, 18 Apr 2015 23:09:52 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: <5530D1F8.10301@schiefner.de> References: <5530D1F8.10301@schiefner.de> Message-ID: <47779CED-8727-438C-8B92-F06E24969DC3@degnet.de> +1 regards, Florian Fuessl > Am 17.04.2015 um 11:27 schrieb Carsten Schiefner : > > Support. > > On 14.04.2015 14:52, Marco Schmidt wrote: >> Dear colleagues, >> >> A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" >> is now available for discussion. >> >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2015-02 >> >> We encourage you to review this proposal and send your comments to >> before 13 May 2015. >> >> Regards >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4193 bytes Desc: not available URL: From guych at btireland.net Mon Apr 20 09:51:36 2015 From: guych at btireland.net (Guy Chilton) Date: Mon, 20 Apr 2015 08:51:36 +0100 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <5534B008.7070003@btireland.net> Completely logical change.. support. Guy On 14/04/15 13:52, Marco Schmidt wrote: > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > From mschmidt at ripe.net Wed Apr 22 14:06:28 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 22 Apr 2015 14:06:28 +0200 Subject: [address-policy-wg] RIPE Labs article on how Website Redesign affects Policy Proposal Discussions Message-ID: <55378EC4.8090203@ripe.net> Dear colleagues, The latest update on RIPE Labs is an article highlighting the simplification of policy proposal discussions thanks to the re-design of www.ripe.net. - Find out how the diff tool allows easy comparison of RIPE documents. - Learn how we improved navigation and participation. - Discover more improved usability elements when you read the full article at: https://www.ripe.net/s/iO45 For comments or questions, you?re welcome to use the RIPE Labs article page or send me a direct email. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC From ip at infinitytelecom.ro Thu Apr 23 12:18:41 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Thu, 23 Apr 2015 13:18:41 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: Message-ID: <1579994104.20150423131841@infinitytelecom.ro> Hello, If this proposal will be accepted: https://www.ripe.net/participate/policies/proposals/2015-01 The price per IP found at "IPv4 Transfer Listing Service" will be double or even worst. Little companies will be out of business.. and we will be one of them. To pay double or even more for some spammed IP.. its not a good choice.. only because smart guys with no real internet business hold very large blocks This proposal should have more time, its not like any other proposal, this can affect activity for a lot of small companies. Thank you. -- Cu stima, Gabriel Voitis | Sales Manager voitis at infinitytelecom.ro INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 contact at infinitytelecom.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Apr 23 13:12:16 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 13:12:16 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1579994104.20150423131841@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> Message-ID: <20150423111216.GS54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 01:18:41PM +0300, Infinity Telecom SRL wrote: > > If this proposal will be accepted: https://www.ripe.net/participate/policies/proposals/2015-01 > > The price per IP found at "IPv4 Transfer Listing Service" will be double or even worst. Why should it? The price for IPv4 addresses on the market is already (much!) higher today than "open LIR, get space", and still people happily trade v4 blocks around. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 ripe at opteamax.de Thu Apr 23 13:17:50 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 23 Apr 2015 13:17:50 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1579994104.20150423131841@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> Message-ID: <5538D4DE.1060303@opteamax.de> Hi, actually I do not understand why the price raises with this. It actually only prevents the currently more or less legal way to bypass the "last /8"-policy by setting up a bunch of LIRs which actually only have the single purpose to drop IPv4 into pool. I'd even prefer to go one step further and propose to extend the policy to: "A /22 allocation, which had been assigned under the last /8-Policy may only be transfered, when it has been in use for at least 24 month. Allocations which have not been used need to be returned to RIPE NCC to be readded to the pool." You know, same rules for everyone, else LIRs from countries where it is pretty easy and cheap to set up legal entities would have a big advantage over the ones located in countries where it's much more complicated and expensive. Acutally trading IPs as whole should not be accepted ... and to run the business fair for every LIR, it would actually be necessary to validate usage of IP-Space regualary and enforce returning unused blocks. Before last /8 you needed to jutify your need, but many LIRs faked their justifications and now can make profit out of their cheating. IMHO the only reason for a Resource-Transfer is a LIR-Merger, where the IP-Space is in use and the customers the IP-Space is assigned are also taken over bei the new LIR. Everything else is against the principles of equality between LIRs, as it is e.g. presented as the reason for why LIRs with /11 IPv4 pay the same as ones with only a single /22. Kind regards Jens On 23.04.2015 12:18, Infinity Telecom SRL wrote: > Hello, > > > If this proposal will be accepted: > https://www.ripe.net/participate/policies/proposals/2015-01 > > The price per IP found at "IPv4 Transfer Listing Service" will be > double or even worst. > > Little companies will be out of business.. and we will be one of them. > > To pay double or even more for some spammed IP.. its not a good > choice.. only because smart guys with no real internet business hold > very large blocks > > This proposal should have more time, its not like any other proposal, > this can affect activity for a lot of small companies. > > > Thank you. > > > /-- > Cu stima, > Gabriel Voitis | Sales Manager > /voitis at infinitytelecom.ro > > /INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 > Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 > /contact at infinitytelecom.ro > !DSPAM:637,5538cc3c196401601117903! -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From vladimir at quick-soft.net Thu Apr 23 13:20:31 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 14:20:31 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1579994104.20150423131841@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> Message-ID: <3006371429788031@web27m.yandex.ru> Hi, All! I decided to express my opinion regarding this proposal. As appears from the proposal summary it pursues the following goals: 1. prevent opening LIR, receiving /22 and selling it 2. prevent making a financial profit from st. 1 3. save IPv4 space from exhaustion Looking at listed items I can suppose either Elvis is angry at people earning money or really /22 reselling is bad for RIPE and its community. At half part of my letter I prove that /22 reselling has negligible impact on community. As a way to achieve the goals the proposal offer to substitute st. 5.5 from ripe-623 for: "LIRs that receive an allocation from the RIPE NCC or a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation." If pointed change to st. 5.5 is accepted we will face with the following: - Black market of /22 transfers will grow rapidly. Companies wishing to acquire IPv4 space can compose fake papers with sellers regarding merging/acquisition and send it to RIPE NCC (like IPv4 PI space as it was till recently). Also it should be noted that RIPE NCC can't forbid transfers which are under merging/acquisition since such transfers only reflect internal company(is) structure. - Companies wishing to sell /22 can just wait for 24 months (if they have enough patience of course). - The policy doesn't prevent opening multiple LIR's, merging LIR's together and then using received /22's for own company needs. In other words the policy doesn't introduce sufficient arrangements to achieve set goals. I.e. in current view the policy is inoperative. --------------------------------------------------------------------------------------------- Let's calculate what ratio of transferred /22's from last /8 (T1) to total count of allocated /22's (T2) is. At https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers page type into filter "185.0". After that go to web browser console and type: $('#transfers-table-allocations tr').length For 23 April 2015 we have T1 = 237. Total count of allocated blocks can be calculated (approximately) as A * B where A and B are octets in allocation address 185.A.B.0/22. Octet A can be named "series" and B is possible block count in each "series". B is always 64 and A (for now) is 97. Thus totally allocated T2 = 97 * 64 = 6208 blocks from last /8. Ratio of transferred blocks is 237 / 6208 * 100 ~ 3.81% >From my point of view it's NOT SIGNIFICANT number at all. --------------------------------------------------------------------------------------------- Let's also calculate how /22 reselling impact on IPv4 exhaustion. RIPE NCC allocate approximately 10-15 /22's per day of 40-60 /22's per week (S). Averaging will receive S = 50. Sold /22's have sped up IPV4 exhaustion only for T1 / S = 237 / 50 = 4.74 weeks. I.e. /22 reselling impact is just 1 MONTH of exhaustion! --------------------------------------------------------------------------------------------- Summarizing I would like to say that the proposal has questionable reasons of its introduction, also questionable goals and offer inoperative changes to RIPE NCC policy. Also I believe that listed arguments will help WG to make Impact Analysis. 23.04.2015, 13:29, "Infinity Telecom SRL" : > ?Hello, > > ?If this proposal will be accepted: https://www.ripe.net/participate/policies/proposals/2015-01 > > ?The price per IP found at "IPv4 Transfer Listing Service" ?will be double or even worst. > > ?Little companies will be out of business.. and we will be one of them. > > ?To pay double or even more for some spammed IP.. ?its not a good choice.. only because smart guys with no real internet business hold very large blocks > > ?This proposal should have more time, its not like any other proposal, this can affect activity for a lot of small companies. > > ?Thank you. > > ?-- > ?Cu stima, > ?Gabriel Voitis | Sales Manager > ?voitis at infinitytelecom.ro > > ?INFINITY TELECOM SRL ?| ?Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 > ?Mobil: +40 0725 677 477 ?| ?Tel: +40 021 7808805 ?| ?Fax: +40 021 7808806 > ?contact at infinitytelecom.ro --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ebais at a2b-internet.com Thu Apr 23 13:34:43 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 23 Apr 2015 13:34:43 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1579994104.20150423131841@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> Message-ID: <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> Hi Gabriel, This policy is not keep people from opening a new LIR .. it is to keep people from opening a new LIR and transfer the IP range for profit to someone else and shutdown the LIR within the first year... The reason for the proposal is fix it more into the intention on why the policy was designed as it was ? Every new entry to the market should be able to get a bit of IPv4 ? The intention was not to start a new LIR and sell the /22 to some other company ? either for profit or as a means of getting cheap IP?s ? To give some examples that might look familiar to you : >From RO.INFINITY to lt.bacloud : ( From the published Transfer stats page.. ) 185.64.104.0/22 185.64.104.0/22 Infinity Telecom SRL Informacines sistemos ir technologijos, UAB 15/09/2014 Allocation date to RO.INFINITY - 2014-07-18 >From IFN PAWN collection to ro.infinity : Original Block Transferred Blocks From To Date 185.85.180.0/22 185.85.180.0/22 IFN PAWN COLLECTION SRL Infinity Telecom SRL 10/04/2015 Allocation date to : IFN Pawn for 185.85.180.0/22 was on 2015-01-27 The LIR for IFN Pawn is no longer active ? If you claim that the issue is, that you have a shortage of IP space ?. Why are you selling the /22 that was originally allocated to your own LIR to a company in Italy ? Or is it because you don?t like it that this proposal will stop you from starting new LIR?s in dummy companies .. to be able to transfer the space to other LIR?s .. ? I think that your comments make it very clear why this proposal should be implemented .. But maybe I?m missing something ? Regards, Erik Bais Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Infinity Telecom SRL Verzonden: donderdag 23 april 2015 12:19 Aan: address-policy-wg at ripe.net Onderwerp: [address-policy-wg] Transfer Requirements for IPv4 Allocations Hello, If this proposal will be accepted: https://www.ripe.net/participate/policies/proposals/2015-01 The price per IP found at "IPv4 Transfer Listing Service" will be double or even worst. Little companies will be out of business.. and we will be one of them. To pay double or even more for some spammed IP.. its not a good choice.. only because smart guys with no real internet business hold very large blocks This proposal should have more time, its not like any other proposal, this can affect activity for a lot of small companies. Thank you. -- Cu stima, Gabriel Voitis | Sales Manager voitis at infinitytelecom.ro INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 contact at infinitytelecom.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From ip at infinitytelecom.ro Thu Apr 23 13:38:55 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Thu, 23 Apr 2015 14:38:55 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423111216.GS54385@Space.Net> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> Message-ID: <788721892.20150423143855@infinitytelecom.ro> Hello Gert, Thank you for reply. You said "people happily trade", what do you want to do ? They have 3 choice: 1. Close their business.. 2. Buy at outrageous price, from the "smart guys", almost "people happily trade" are very near to close their business. 3. Make another LIR and move resource to the old LIR.. get NEW IPs, never spammed and reasonable price. Thank you again. -- Cu stima, Gabriel Voitis | Sales Manager voitis at infinitytelecom.ro INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 contact at infinitytelecom.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From ip at infinitytelecom.ro Thu Apr 23 13:41:19 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Thu, 23 Apr 2015 14:41:19 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> Message-ID: <743864634.20150423144119@infinitytelecom.ro> Hello Erik, Why someone will come to me to get new IPs, when they can open a LIR by them self ? Without extra cost ? I think everyone that open a LIR right now its because they dont have any chance to BUY from sellers.. Thank you. -- Cu stima, Gabriel Voitis | Sales Manager voitis at infinitytelecom.ro INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 contact at infinitytelecom.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Apr 23 13:43:48 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 13:43:48 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <788721892.20150423143855@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> Message-ID: <20150423114348.GT54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 02:38:55PM +0300, Infinity Telecom SRL wrote: > Thank you for reply. > > You said "people happily trade", what do you want to do ? *I* want nothing in particular. > They have 3 choice: > > 1. Close their business.. > 2. Buy at outrageous price, from the "smart guys", almost "people happily trade" are very near to close their business. > 3. Make another LIR and move resource to the old LIR.. get NEW IPs, never spammed and reasonable price. But this is not the price "at the transfer service" that you claimed. ... and the community is free to declare that "Make another LIR and move resources to old LIR (right away)" is considered abuse of the last /8 policy, and dis-incentivize it... 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 ip at infinitytelecom.ro Thu Apr 23 13:47:34 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Thu, 23 Apr 2015 14:47:34 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> Message-ID: <176417641.20150423144734@infinitytelecom.ro> Hello Erik, About this examples: I was aware of this, also will follow another transfer very soon: ro.avacars to ro.infinity And ? Its more cheaper then to buy from the market.. at outrageous price. Your point its useless in my case.. i want to keep my IPs for 10 yrs. -- Cu stima, Gabriel Voitis | Sales Manager voitis at infinitytelecom.ro INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 contact at infinitytelecom.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Thu Apr 23 13:55:55 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 23 Apr 2015 13:55:55 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <743864634.20150423144119@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> Message-ID: <015101d07dbc$7d127670$77376350$@a2b-internet.com> Hi Gabriel, I agree with you that it might satisfy a specific need for a company at a certain time to open a new LIR.. I?ve seen LIR?s request for a /22 that didn?t even knew they could still get a free /22 from the RIPE NCC. . . . The goal of this proposal is to stop the abuse of opening a new LIR, transferring the /22 for profit to another LIR and close the LIR. As it is against the original intent of the final /8 last /22 procedure (https://www.ripe.net/publications/docs/ripe-643#51 ) And specifically : Point 3 : The LIR must confirm it will make assignment(s) from the allocation. The intention of the current policy and why it was made as it was in the past, is to give EVERY LIR 1 additional /22 ? and also have enough for new entries in the market ( looking at the new sign-ups of LIR typically in the market, if you look at how that number grew over the last couple years.. ) for at least 5 to 6 years ? Point 3 doesn?t say .. The LIR must confirm it will make assignment(s) from the allocation or transfer parts or the complete allocation for profit to another LIR. This policy text was never intended to have new LIR?s being setup and closed just to get cheap IP?s ? And I?m pretty sure that if that was foreseen at the time, that the respective author would have closed that gap at the time ? As that is in the past ? and this is currently being abused .. It is time to fix this and close this gap. Regards, Erik Bais Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Infinity Telecom SRL Verzonden: donderdag 23 april 2015 13:41 Aan: Erik Bais; address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] Transfer Requirements for IPv4 Allocations Hello Erik, Why someone will come to me to get new IPs, when they can open a LIR by them self ? Without extra cost ? I think everyone that open a LIR right now its because they dont have any chance to BUY from sellers.. Thank you. -- Cu stima, Gabriel Voitis | Sales Manager voitis at infinitytelecom.ro INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 contact at infinitytelecom.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Thu Apr 23 14:03:14 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 23 Apr 2015 14:03:14 +0200 (CEST) Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <788721892.20150423143855@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> Message-ID: On Thu, 23 Apr 2015, Infinity Telecom SRL wrote: > 3. Make another LIR and move resource to the old LIR.. get NEW IPs, > never spammed and reasonable price. You're free to do this after the minimum time according to the proposed changed text. You just have to keep the LIR open for at least 24 months before you can transfer the /24 out of it and close the LIR. It seems you're exactly one of the (ab)users of the current policy and you seem to think it's your right to continue with this. That's a valid opinion, but it's not shared with most other people here. -- Mikael Abrahamsson email: swmike at swm.pp.se From ip at infinitytelecom.ro Thu Apr 23 14:05:06 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Thu, 23 Apr 2015 15:05:06 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423114348.GT54385@Space.Net> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> Message-ID: <1533248069.20150423150506@infinitytelecom.ro> Hello Gert, "at the transfer services" i saw sellers that want 17-20 USD per IP, this is crazy, do you want forward ? Do you think this is a normal ? If right now they ask soo much even when they know someone like me can open a new LIR an close after 1 year. What will happen when someone like me will open a LIR and pay 2 yrs before to move the IPs to the old LIR I tell you what will happen, the sellers will put another 5-7 USD per IP, for sure. Most of the guys that are pro this proposal have large blocks for sell.. I dont have large blocks.. i want to keep my IPs and have more resource.. Thank you. -- Cu stima, Gabriel Voitis | Sales Manager voitis at infinitytelecom.ro INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 contact at infinitytelecom.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at quick-soft.net Thu Apr 23 14:07:54 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 15:07:54 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> Message-ID: <3484611429790874@web27g.yandex.ru> I think firstly we should answer question "why" to introduce change to RIPE NCC policy. And only then "what" to change. In my opinion any change to policy should reflect expectation of community as a whole. Current propose doesn't change anything to the direction of improvement for community. If somebody doesn't like that other people do their business on reselling it's not a problem of community. 23.04.2015, 15:03, "Mikael Abrahamsson" : > On Thu, 23 Apr 2015, Infinity Telecom SRL wrote: >> ?3. Make another LIR and move resource to the old LIR.. ?get NEW IPs, >> ?never spammed and reasonable price. > > You're free to do this after the minimum time according to the proposed > changed text. You just have to keep the LIR open for at least 24 months > before you can transfer the /24 out of it and close the LIR. > > It seems you're exactly one of the (ab)users of the current policy and you > seem to think it's your right to continue with this. That's a valid > opinion, but it's not shared with most other people here. > > -- > Mikael Abrahamsson ???email: swmike at swm.pp.se --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From vladimir at quick-soft.net Thu Apr 23 14:14:23 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 15:14:23 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3484611429790874@web27g.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> Message-ID: <3529201429791263@web27g.yandex.ru> In one of my prev. letter I listed calculations proving that reselling doesn't have big impact on IPv4 space exhaustion. In such case WHAT IS THIS DISCUSSION ABOUT? About PERSONAL wish of some people to play dirty tricks with /22 sellers? 23.04.2015, 15:07, "Vladimir Andreev" : > I think firstly we should answer question "why" to introduce change to RIPE NCC policy. And only then "what" to change. > > In my opinion any change to policy should reflect expectation of community as a whole. > Current propose doesn't change anything to the direction of improvement for community. > > If somebody doesn't like that other people do their business on reselling it's not a problem of community. > > 23.04.2015, 15:03, "Mikael Abrahamsson" : >> ?On Thu, 23 Apr 2015, Infinity Telecom SRL wrote: >>> ??3. Make another LIR and move resource to the old LIR.. ?get NEW IPs, >>> ??never spammed and reasonable price. >> ?You're free to do this after the minimum time according to the proposed >> ?changed text. You just have to keep the LIR open for at least 24 months >> ?before you can transfer the /24 out of it and close the LIR. >> >> ?It seems you're exactly one of the (ab)users of the current policy and you >> ?seem to think it's your right to continue with this. That's a valid >> ?opinion, but it's not shared with most other people here. >> >> ?-- >> ?Mikael Abrahamsson ???email: swmike at swm.pp.se > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From gert at space.net Thu Apr 23 14:16:35 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 14:16:35 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1533248069.20150423150506@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <1533248069.20150423150506@infinitytelecom.ro> Message-ID: <20150423121635.GV54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 03:05:06PM +0300, Infinity Telecom SRL wrote: > "at the transfer services" i saw sellers that want 17-20 USD per IP, this is crazy, do you want forward ? > > Do you think this is a normal ? No, this is exceptionary high. Normal going price is way lower. [..] > I dont have large blocks.. i want to keep my IPs and have more resource.. Go use IPv6? Especially .ro is one of the leaders in IPv6 deployment... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 ripe-wgs at radu-adrian.feurdean.net Thu Apr 23 14:17:49 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 23 Apr 2015 14:17:49 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <788721892.20150423143855@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> Message-ID: <1429791469.1161879.257597937.76B4FA8C@webmail.messagingengine.com> On Thu, Apr 23, 2015, at 13:38, Infinity Telecom SRL wrote: > You said "people happily trade", what do you want to do ? > > They have 3 choice: > > 1. Close their business.. > 2. Buy at outrageous price, from the "smart guys", almost "people happily > trade" are very near to close their business. > 3. Make another LIR and move resource to the old LIR.. get NEW IPs, > never spammed and reasonable price. Hi, The 24 months delay doesn't stop you from opening a new LIR, getting the space, starting using it immediately and only closing the LIR after 2 years. As a bonus - price is still lower that what you find on the market (~5-6 EUR/IP). - payment spans over several billing cycles (at least 2, most likely 3). You still don't get more than 1K IPs at once. The downside is that you have some extra administrtive overhead, which should be no problem for those that don't do anything else than opening LIRs and selling their space. From gert at space.net Thu Apr 23 14:20:19 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 14:20:19 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3484611429790874@web27g.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> Message-ID: <20150423122019.GW54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 03:07:54PM +0300, Vladimir Andreev wrote: > In my opinion any change to policy should reflect expectation of community as a whole. "Rough consensus" does not mean *everybody* has to agree. > Current propose doesn't change anything to the direction of improvement for community. Oh, to the contrary - ensuring that allocations from the last /8 are not burnt like crazy (by permitting arbitrary fast trading) might not be something good for you personally, but for the *rest* of the community, it might be actually a good thing (depending on whether or not you believe in the rationale for the last /8 policy). The last /8 is not there to do "business as usual, based on IPv4" - it is there to enable *new* market entrants to run a few critical things with IPv4, while the main deployment has to happen on IPv6. 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 vladimir at quick-soft.net Thu Apr 23 14:22:34 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 15:22:34 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423122019.GW54385@Space.Net> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> Message-ID: <3584301429791754@web27g.yandex.ru> But the proposal doesn't forbid to open many LIRs and then merge them together. So achieving "one LIR ? one /22" is impossible. 23.04.2015, 15:20, "Gert Doering" : > Hi, > > On Thu, Apr 23, 2015 at 03:07:54PM +0300, Vladimir Andreev wrote: >> ?In my opinion any change to policy should reflect expectation of community as a whole. > > "Rough consensus" does not mean *everybody* has to agree. >> ?Current propose doesn't change anything to the direction of improvement for community. > > Oh, to the contrary - ensuring that allocations from the last /8 are > not burnt like crazy (by permitting arbitrary fast trading) might not > be something good for you personally, but for the *rest* of the community, > it might be actually a good thing (depending on whether or not you > believe in the rationale for the last /8 policy). > > The last /8 is not there to do "business as usual, based on IPv4" - it > is there to enable *new* market entrants to run a few critical things > with IPv4, while the main deployment has to happen on IPv6. > > 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 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ripe at opteamax.de Thu Apr 23 14:27:05 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 23 Apr 2015 14:27:05 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1533248069.20150423150506@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <1533248069.20150423150506@infinitytelecom.ro> Message-ID: <5538E519.7010100@opteamax.de> Hello Gabriel, openig a bunch of LIR only for transfering their /22 V4 to another LIR is - and always was - abusing the policy. So you acutally don't want to speak against the change of Transfer-Policy but want to keep the backdoor open. So if you think the last /8 policy is not OK - where consensus was reached - you should stand up and make a change proposal for that. Knowing the way to bypass policy still does not mean, that it is fair/legal. IMHO LIRs which are willingly abusing policies shall get their entire resources withdrawn immediately, as they are not willing to be part of the community, so shall not profit from community. Sorry, but for me the way you are proposing to run a "business" is almost the same as the one of a guy selling stolen stuff ... Regards Jens On 23.04.2015 14:05, Infinity Telecom SRL wrote: > Hello Gert, > > > "at the transfer services" i saw sellers that want 17-20 USD per IP, > this is crazy, do you want forward ? > > Do you think this is a normal ? > > If right now they ask soo much even when they know someone like me can > open a new LIR an close after 1 year. > > What will happen when someone like me will open a LIR and pay 2 yrs > before to move the IPs to the old LIR > > I tell you what will happen, the sellers will put another 5-7 USD per > IP, for sure. > > Most of the guys that are pro this proposal have large blocks for sell.. > > I dont have large blocks.. i want to keep my IPs and have more resource.. > > Thank you. > > > > /-- > Cu stima, > Gabriel Voitis | Sales Manager > /voitis at infinitytelecom.ro > > /INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 > Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 > /contact at infinitytelecom.ro > !DSPAM:637,5538e2cc256411567483881! -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From vladimir at quick-soft.net Thu Apr 23 14:31:17 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 15:31:17 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538E519.7010100@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <1533248069.20150423150506@infinitytelecom.ro> <5538E519.7010100@opteamax.de> Message-ID: <3639401429792277@web27g.yandex.ru> > ?openig a bunch of LIR only for transfering their /22 V4 to another LIR > ?is - and always was - abusing the policy. Any links to documents proving it? > but for me the way you are proposing to run a "business" is > almost the same as the one of a guy selling stolen stuff ... Such a comparison is incorrect. 23.04.2015, 15:27, "Opteamax GmbH" : > ?Hello Gabriel, > > ?openig a bunch of LIR only for transfering their /22 V4 to another LIR > ?is - and always was - abusing the policy. So you acutally don't want to > ?speak against the change of Transfer-Policy but want to keep the > ?backdoor open. > > ?So if you think the last /8 policy is not OK - where consensus was > ?reached - you should stand up and make a change proposal for that. > > ?Knowing the way to bypass policy still does not mean, that it is > ?fair/legal. IMHO LIRs which are willingly abusing policies shall get > ?their entire resources withdrawn immediately, as they are not willing to > ?be part of the community, so shall not profit from community. > > ?Sorry, but for me the way you are proposing to run a "business" is > ?almost the same as the one of a guy selling stolen stuff ... > > ?Regards > ?Jens > > ?On 23.04.2015 14:05, Infinity Telecom SRL wrote: >> ??Hello Gert, >> >> ??"at the transfer services" ?i saw sellers that want 17-20 USD per IP, >> ???this is crazy, do you want forward ? >> >> ??Do you think this is a normal ? >> >> ??If right now they ask soo much even when they know someone like me can >> ??open a new LIR an close after 1 year. >> >> ??What will happen when someone like me will open a LIR and pay 2 yrs >> ??before to move the IPs ?to the old LIR >> >> ??I tell you what will happen, ?the sellers will put another 5-7 USD per >> ??IP, for sure. >> >> ??Most of the guys that are pro this proposal have large blocks for sell.. >> >> ??I dont have large blocks.. i want to keep my IPs and have more resource.. >> >> ??Thank you. >> >> ??/-- >> ??Cu stima, >> ??Gabriel Voitis | Sales Manager >> ??/voitis at infinitytelecom.ro >> >> ??/INFINITY TELECOM SRL ?| ?Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 >> ??Mobil: +40 0725 677 477 ?| ?Tel: +40 021 7808805 ?| ?Fax: +40 021 7808806 >> ??/contact at infinitytelecom.ro >> ??!DSPAM:637,5538e2cc256411567483881! > ?-- > ?Opteamax GmbH - RIPE-Team > ?Jens Ott > > ?Opteamax GmbH > > ?Simrockstr. 4b > ?53619 Rheinbreitbach > > ?Tel.: ?+49 2224 969500 > ?Fax: ??+49 2224 97691059 > ?Email: jo at opteamax.de > > ?HRB: 23144, Amtsgericht Montabaur > ?Umsatzsteuer-ID.: DE264133989 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ripe-wgs at radu-adrian.feurdean.net Thu Apr 23 14:34:50 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 23 Apr 2015 14:34:50 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423122019.GW54385@Space.Net> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> Message-ID: <1429792490.1165841.257603809.3ABCDA79@webmail.messagingengine.com> On Thu, Apr 23, 2015, at 14:20, Gert Doering wrote: > The last /8 is not there to do "business as usual, based on IPv4" - it > is there to enable *new* market entrants to run a few critical things > with IPv4, while the main deployment has to happen on IPv6. This is sliding off-topic, but I don't see lots of new entrants interpreting things this way. For the moment it still is "business as usual based on ipv4" (with *SOME* ipv6 addition) or "no business at all". Besides, with a free pool larger than 12 months ago, larger than in october 2012 and the second largest among RIRs (after AfriNIC), there still is something that could be done for the new players. From swmike at swm.pp.se Thu Apr 23 14:36:38 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 23 Apr 2015 14:36:38 +0200 (CEST) Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3639401429792277@web27g.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <1533248069.20150423150506@infinitytelecom.ro> <5538E519.7010100@opteamax.de> <3639401429792277@web27g.yandex.ru> Message-ID: On Thu, 23 Apr 2015, Vladimir Andreev wrote: >> ?openig a bunch of LIR only for transfering their /22 V4 to another LIR >> ?is - and always was - abusing the policy. > > Any links to documents proving it? Read the mailing list discussions about the last /8 policy. The /22 per LIR was always about having new entrants to the market being able to at least get a little chunk of addresses so they could have NAT444, email servers etc. It was NEVER meant for people to start LIR, get /22, transfer /22, close LIR, start another LIR, get another /22, transer /22, close LIR, repeat again and again. If the community wanted it to work that way, the policy would have been very differently worded. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Thu Apr 23 14:38:11 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 14:38:11 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3584301429791754@web27g.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> Message-ID: <20150423123811.GX54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 03:22:34PM +0300, Vladimir Andreev wrote: > But the proposal doesn't forbid to open many LIRs and then merge them together. Indeed, because that would prevent legitimate business processes. But what it does is making the "open, sell, close" quick cycle less economically interesting. Which is all we can do here. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 vladimir at quick-soft.net Thu Apr 23 14:38:35 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 15:38:35 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <1533248069.20150423150506@infinitytelecom.ro> <5538E519.7010100@opteamax.de> <3639401429792277@web27g.yandex.ru> Message-ID: <3687311429792715@web27g.yandex.ru> I mean official (accepted) documents. For now we also have a discussion :) 23.04.2015, 15:36, "Mikael Abrahamsson" : > On Thu, 23 Apr 2015, Vladimir Andreev wrote: >>> ??openig a bunch of LIR only for transfering their /22 V4 to another LIR >>> ??is - and always was - abusing the policy. >> ?Any links to documents proving it? > > Read the mailing list discussions about the last /8 policy. The /22 per > LIR was always about having new entrants to the market being able to at > least get a little chunk of addresses so they could have NAT444, email > servers etc. > > It was NEVER meant for people to start LIR, get /22, transfer /22, close > LIR, start another LIR, get another /22, transer /22, close LIR, repeat > again and again. If the community wanted it to work that way, the policy > would have been very differently worded. > > -- > Mikael Abrahamsson ???email: swmike at swm.pp.se --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ripe at opteamax.de Thu Apr 23 14:39:32 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 23 Apr 2015 14:39:32 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3639401429792277@web27g.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <1533248069.20150423150506@infinitytelecom.ro> <5538E519.7010100@opteamax.de> <3639401429792277@web27g.yandex.ru> Message-ID: <5538E804.8010606@opteamax.de> On 23.04.2015 14:31, Vladimir Andreev wrote: >> openig a bunch of LIR only for transfering their /22 V4 to another LIR >> is - and always was - abusing the policy. > > Any links to documents proving it? https://www.ripe.net/publications/docs/ripe-643#51 Number 3 > >> but for me the way you are proposing to run a "business" is >> almost the same as the one of a guy selling stolen stuff ... > > Such a comparison is incorrect. Maybe my comparison lacks do to difficulties translating into english: The guy selling the stuff does not (necessarily) know that the one he bought it from stole it. There are some of those shops, everybody know that they not ask where stuff comes from, but nobody can blame the shopowner ... Jens > > 23.04.2015, 15:27, "Opteamax GmbH" : >> Hello Gabriel, >> >> openig a bunch of LIR only for transfering their /22 V4 to another LIR >> is - and always was - abusing the policy. So you acutally don't want to >> speak against the change of Transfer-Policy but want to keep the >> backdoor open. >> >> So if you think the last /8 policy is not OK - where consensus was >> reached - you should stand up and make a change proposal for that. >> >> Knowing the way to bypass policy still does not mean, that it is >> fair/legal. IMHO LIRs which are willingly abusing policies shall get >> their entire resources withdrawn immediately, as they are not willing to >> be part of the community, so shall not profit from community. >> >> Sorry, but for me the way you are proposing to run a "business" is >> almost the same as the one of a guy selling stolen stuff ... >> >> Regards >> Jens >> >> On 23.04.2015 14:05, Infinity Telecom SRL wrote: >>> Hello Gert, >>> >>> "at the transfer services" i saw sellers that want 17-20 USD per IP, >>> this is crazy, do you want forward ? >>> >>> Do you think this is a normal ? >>> >>> If right now they ask soo much even when they know someone like me can >>> open a new LIR an close after 1 year. >>> >>> What will happen when someone like me will open a LIR and pay 2 yrs >>> before to move the IPs to the old LIR >>> >>> I tell you what will happen, the sellers will put another 5-7 USD per >>> IP, for sure. >>> >>> Most of the guys that are pro this proposal have large blocks for sell.. >>> >>> I dont have large blocks.. i want to keep my IPs and have more resource.. >>> >>> Thank you. >>> >>> /-- >>> Cu stima, >>> Gabriel Voitis | Sales Manager >>> /voitis at infinitytelecom.ro >>> >>> /INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 >>> Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 >>> /contact at infinitytelecom.ro >>> >> -- >> Opteamax GmbH - RIPE-Team >> Jens Ott >> >> Opteamax GmbH >> >> Simrockstr. 4b >> 53619 Rheinbreitbach >> >> Tel.: +49 2224 969500 >> Fax: +49 2224 97691059 >> Email: jo at opteamax.de >> >> HRB: 23144, Amtsgericht Montabaur >> Umsatzsteuer-ID.: DE264133989 > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 > > !DSPAM:637,5538e8fa275851377834544! > -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From gert at space.net Thu Apr 23 14:40:07 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 14:40:07 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1429792490.1165841.257603809.3ABCDA79@webmail.messagingengine.com> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <1429792490.1165841.257603809.3ABCDA79@webmail.messagingengine.com> Message-ID: <20150423124007.GY54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 02:34:50PM +0200, Radu-Adrian FEURDEAN wrote: > On Thu, Apr 23, 2015, at 14:20, Gert Doering wrote: > > The last /8 is not there to do "business as usual, based on IPv4" - it > > is there to enable *new* market entrants to run a few critical things > > with IPv4, while the main deployment has to happen on IPv6. > > This is sliding off-topic, but I don't see lots of new entrants > interpreting things this way. For the moment it still is "business as > usual based on ipv4" (with *SOME* ipv6 addition) or "no business at > all". > > Besides, with a free pool larger than 12 months ago, larger than in > october 2012 and the second largest among RIRs (after AfriNIC), there > still is something that could be done for the new players. We're reserving this for new players in 5 or 10 years time. Not for "next month". 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 vladimir at quick-soft.net Thu Apr 23 14:41:10 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 15:41:10 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423123811.GX54385@Space.Net> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> Message-ID: <3705731429792870@web27g.yandex.ru> You say "legitimate" business processes. But how have decided what is "legitimate" and what is not? I see no prohibition in current policies to open, receive /22 and close. So it's also "legitimate" business! And why receiving /22's for own company is "legitimate" and for selling is not? 23.04.2015, 15:38, "Gert Doering" : > Hi, > > On Thu, Apr 23, 2015 at 03:22:34PM +0300, Vladimir Andreev wrote: >> ?But the proposal doesn't forbid to open many LIRs and then merge them together. > > Indeed, because that would prevent legitimate business processes. > > But what it does is making the "open, sell, close" quick cycle > less economically interesting. ?Which is all we can do here. > > Gert Doering > ????????-- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG ???????????????????????Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 ?????????Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen ??????????????????HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 ??????????USt-IdNr.: DE813185279 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From gert at space.net Thu Apr 23 14:43:35 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 14:43:35 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3705731429792870@web27g.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> Message-ID: <20150423124335.GZ54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 03:41:10PM +0300, Vladimir Andreev wrote: > And why receiving /22's for own company is "legitimate" and for selling is not? *one* /22 per LIR is the last-/8 policy not "open lots of LIRs, so a single LIR can have multiple /22s in the end, and circumvent the one-LIR-one-/22-allocated policy". Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 vladimir at quick-soft.net Thu Apr 23 14:44:22 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 15:44:22 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538E804.8010606@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <1533248069.20150423150506@infinitytelecom.ro> <5538E519.7010100@opteamax.de> <3639401429792277@web27g.yandex.ru> <5538E804.8010606@opteamax.de> Message-ID: <3724651429793062@web27g.yandex.ru> > On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: > > The size of the allocation made will be exactly one /22. > > The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). > > The LIR must confirm it will make assignment(s) from the allocation. All this lines relates to receiving /22 from RIPE NCC! Not from other LIRs. Please read all 5.1 st from ripe-643 So merging own LIRs or receiving /22 from other member is not violation. 23.04.2015, 15:39, "Opteamax GmbH" : > On 23.04.2015 14:31, Vladimir Andreev wrote: >>> ??openig a bunch of LIR only for transfering their /22 V4 to another LIR >>> ??is - and always was - abusing the policy. >> ?Any links to documents proving it? > > https://www.ripe.net/publications/docs/ripe-643#51 > > Number 3 >>> ?but for me the way you are proposing to run a "business" is >>> ?almost the same as the one of a guy selling stolen stuff ... >> ?Such a comparison is incorrect. > > Maybe my comparison lacks do to difficulties translating into english: > The guy selling the stuff does not (necessarily) know that the one he > bought it from stole it. There are some of those shops, everybody know > that they not ask where stuff comes from, but nobody can blame the > shopowner ... > > Jens >> ?23.04.2015, 15:27, "Opteamax GmbH" : >>> ??Hello Gabriel, >>> >>> ??openig a bunch of LIR only for transfering their /22 V4 to another LIR >>> ??is - and always was - abusing the policy. So you acutally don't want to >>> ??speak against the change of Transfer-Policy but want to keep the >>> ??backdoor open. >>> >>> ??So if you think the last /8 policy is not OK - where consensus was >>> ??reached - you should stand up and make a change proposal for that. >>> >>> ??Knowing the way to bypass policy still does not mean, that it is >>> ??fair/legal. IMHO LIRs which are willingly abusing policies shall get >>> ??their entire resources withdrawn immediately, as they are not willing to >>> ??be part of the community, so shall not profit from community. >>> >>> ??Sorry, but for me the way you are proposing to run a "business" is >>> ??almost the same as the one of a guy selling stolen stuff ... >>> >>> ??Regards >>> ??Jens >>> >>> ??On 23.04.2015 14:05, Infinity Telecom SRL wrote: >>>> ???Hello Gert, >>>> >>>> ???"at the transfer services" ?i saw sellers that want 17-20 USD per IP, >>>> ????this is crazy, do you want forward ? >>>> >>>> ???Do you think this is a normal ? >>>> >>>> ???If right now they ask soo much even when they know someone like me can >>>> ???open a new LIR an close after 1 year. >>>> >>>> ???What will happen when someone like me will open a LIR and pay 2 yrs >>>> ???before to move the IPs ?to the old LIR >>>> >>>> ???I tell you what will happen, ?the sellers will put another 5-7 USD per >>>> ???IP, for sure. >>>> >>>> ???Most of the guys that are pro this proposal have large blocks for sell.. >>>> >>>> ???I dont have large blocks.. i want to keep my IPs and have more resource.. >>>> >>>> ???Thank you. >>>> >>>> ???/-- >>>> ???Cu stima, >>>> ???Gabriel Voitis | Sales Manager >>>> ???/voitis at infinitytelecom.ro >>>> >>>> ???/INFINITY TELECOM SRL ?| ?Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 >>>> ???Mobil: +40 0725 677 477 ?| ?Tel: +40 021 7808805 ?| ?Fax: +40 021 7808806 >>>> ???/contact at infinitytelecom.ro >>> ??-- >>> ??Opteamax GmbH - RIPE-Team >>> ??Jens Ott >>> >>> ??Opteamax GmbH >>> >>> ??Simrockstr. 4b >>> ??53619 Rheinbreitbach >>> >>> ??Tel.: ?+49 2224 969500 >>> ??Fax: ??+49 2224 97691059 >>> ??Email: jo at opteamax.de >>> >>> ??HRB: 23144, Amtsgericht Montabaur >>> ??Umsatzsteuer-ID.: DE264133989 >> ?-- >> ?With best regards, Vladimir Andreev >> ?General director, QuickSoft LLC >> ?Tel: +7 903 1750503 >> >> ?!DSPAM:637,5538e8fa275851377834544! > > -- > Opteamax GmbH - RIPE-Team > Jens Ott > > Opteamax GmbH > > Simrockstr. 4b > 53619 Rheinbreitbach > > Tel.: ?+49 2224 969500 > Fax: ??+49 2224 97691059 > Email: jo at opteamax.de > > HRB: 23144, Amtsgericht Montabaur > Umsatzsteuer-ID.: DE264133989 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From vladimir at quick-soft.net Thu Apr 23 14:45:56 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 15:45:56 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423124335.GZ54385@Space.Net> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> Message-ID: <3734711429793156@web27g.yandex.ru> > On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: > > The size of the allocation made will be exactly one /22. > > The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). > > The LIR must confirm it will make assignment(s) from the allocation. Please point me where in quoted text you see any prohibition to open and merge LIRs with /22's? 23.04.2015, 15:43, "Gert Doering" : > Hi, > > On Thu, Apr 23, 2015 at 03:41:10PM +0300, Vladimir Andreev wrote: >> ?And why receiving /22's for own company is "legitimate" and for selling is not? > > *one* /22 per LIR is the last-/8 policy > > ?not "open lots of LIRs, so a single LIR can have multiple /22s in the end, > ??????and circumvent the one-LIR-one-/22-allocated policy". > > Gert Doering > ????????-- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG ???????????????????????Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 ?????????Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen ??????????????????HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 ??????????USt-IdNr.: DE813185279 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From vladimir at quick-soft.net Thu Apr 23 14:50:30 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 15:50:30 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538E804.8010606@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <1533248069.20150423150506@infinitytelecom.ro> <5538E519.7010100@opteamax.de> <3639401429792277@web27g.yandex.ru> <5538E804.8010606@opteamax.de> Message-ID: <3762761429793430@web27g.yandex.ru> 3.0 Goals of the Internet Registry System can be treated by a lot of ways. I (personally) doesn't find any prohibition in st. 3.0 to have many /22 per LIR. 23.04.2015, 15:39, "Opteamax GmbH" : > On 23.04.2015 14:31, Vladimir Andreev wrote: >>> ??openig a bunch of LIR only for transfering their /22 V4 to another LIR >>> ??is - and always was - abusing the policy. >> ?Any links to documents proving it? > > https://www.ripe.net/publications/docs/ripe-643#51 > > Number 3 >>> ?but for me the way you are proposing to run a "business" is >>> ?almost the same as the one of a guy selling stolen stuff ... >> ?Such a comparison is incorrect. > > Maybe my comparison lacks do to difficulties translating into english: > The guy selling the stuff does not (necessarily) know that the one he > bought it from stole it. There are some of those shops, everybody know > that they not ask where stuff comes from, but nobody can blame the > shopowner ... > > Jens >> ?23.04.2015, 15:27, "Opteamax GmbH" : >>> ??Hello Gabriel, >>> >>> ??openig a bunch of LIR only for transfering their /22 V4 to another LIR >>> ??is - and always was - abusing the policy. So you acutally don't want to >>> ??speak against the change of Transfer-Policy but want to keep the >>> ??backdoor open. >>> >>> ??So if you think the last /8 policy is not OK - where consensus was >>> ??reached - you should stand up and make a change proposal for that. >>> >>> ??Knowing the way to bypass policy still does not mean, that it is >>> ??fair/legal. IMHO LIRs which are willingly abusing policies shall get >>> ??their entire resources withdrawn immediately, as they are not willing to >>> ??be part of the community, so shall not profit from community. >>> >>> ??Sorry, but for me the way you are proposing to run a "business" is >>> ??almost the same as the one of a guy selling stolen stuff ... >>> >>> ??Regards >>> ??Jens >>> >>> ??On 23.04.2015 14:05, Infinity Telecom SRL wrote: >>>> ???Hello Gert, >>>> >>>> ???"at the transfer services" ?i saw sellers that want 17-20 USD per IP, >>>> ????this is crazy, do you want forward ? >>>> >>>> ???Do you think this is a normal ? >>>> >>>> ???If right now they ask soo much even when they know someone like me can >>>> ???open a new LIR an close after 1 year. >>>> >>>> ???What will happen when someone like me will open a LIR and pay 2 yrs >>>> ???before to move the IPs ?to the old LIR >>>> >>>> ???I tell you what will happen, ?the sellers will put another 5-7 USD per >>>> ???IP, for sure. >>>> >>>> ???Most of the guys that are pro this proposal have large blocks for sell.. >>>> >>>> ???I dont have large blocks.. i want to keep my IPs and have more resource.. >>>> >>>> ???Thank you. >>>> >>>> ???/-- >>>> ???Cu stima, >>>> ???Gabriel Voitis | Sales Manager >>>> ???/voitis at infinitytelecom.ro >>>> >>>> ???/INFINITY TELECOM SRL ?| ?Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 >>>> ???Mobil: +40 0725 677 477 ?| ?Tel: +40 021 7808805 ?| ?Fax: +40 021 7808806 >>>> ???/contact at infinitytelecom.ro >>> ??-- >>> ??Opteamax GmbH - RIPE-Team >>> ??Jens Ott >>> >>> ??Opteamax GmbH >>> >>> ??Simrockstr. 4b >>> ??53619 Rheinbreitbach >>> >>> ??Tel.: ?+49 2224 969500 >>> ??Fax: ??+49 2224 97691059 >>> ??Email: jo at opteamax.de >>> >>> ??HRB: 23144, Amtsgericht Montabaur >>> ??Umsatzsteuer-ID.: DE264133989 >> ?-- >> ?With best regards, Vladimir Andreev >> ?General director, QuickSoft LLC >> ?Tel: +7 903 1750503 >> >> ?!DSPAM:637,5538e8fa275851377834544! > > -- > Opteamax GmbH - RIPE-Team > Jens Ott > > Opteamax GmbH > > Simrockstr. 4b > 53619 Rheinbreitbach > > Tel.: ?+49 2224 969500 > Fax: ??+49 2224 97691059 > Email: jo at opteamax.de > > HRB: 23144, Amtsgericht Montabaur > Umsatzsteuer-ID.: DE264133989 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From swmike at swm.pp.se Thu Apr 23 14:50:46 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 23 Apr 2015 14:50:46 +0200 (CEST) Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3734711429793156@web27g.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> Message-ID: On Thu, 23 Apr 2015, Vladimir Andreev wrote: >> On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: >> >> The size of the allocation made will be exactly one /22. >> >> The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). >> >> The LIR must confirm it will make assignment(s) from the allocation. > > Please point me where in quoted text you see any prohibition to open and merge LIRs with /22's? We can't do that, so what we're trying to do is make it less profitable to do so. But the INTENTION behind the current policy was to allow a new ISP (or other type of entity) a /22 to allow them to participate in IPv4 world 5-10 years down the line. It was NOT to allow people to use administrative tricks to cheaply acquire IPv4 space for use in a single business. From ip at infinitytelecom.ro Thu Apr 23 14:51:18 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Thu, 23 Apr 2015 15:51:18 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538E519.7010100@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <1533248069.20150423150506@infinitytelecom.ro> <5538E519.7010100@opteamax.de> Message-ID: <426953363.20150423155118@infinitytelecom.ro> Hello Opteamax, BTW about "stolen", lets look at transfer list and see companies that have /16 /17 /18 blocks Do you think they ever could explain, so much resources ? In their case, internet activity its very tiny or absent.. but they hold large and very large blocks. How many of them with /16 /17 blocks for sell was ever present in any IX (internet exchange) for example.. How many of them are really in internet business ? The transfer list is one way too look, why IPv4 vanish ! and who make profit.. its so easy.. For sure i dont do any profit.. because i "stole" a /22 for my company ! And i dont have enough money to pay the sellers 2-3 times more.. Maybe i am a newcomer and i dont know too much.. i apologies for this ! -- Cu stima, Gabriel Voitis | Sales Manager voitis at infinitytelecom.ro INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 contact at infinitytelecom.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at opteamax.de Thu Apr 23 14:54:38 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 23 Apr 2015 14:54:38 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3762761429793430@web27g.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <1533248069.20150423150506@infinitytelecom.ro> <5538E519.7010100@opteamax.de> <3639401429792277@web27g.yandex.ru> <5538E804.8010606@opteamax.de> <3762761429793430@web27g.yandex.ru> Message-ID: <5538EB8E.7080604@opteamax.de> On 23.04.2015 14:50, Vladimir Andreev wrote: > 3.0 Goals of the Internet Registry System > > can be treated by a lot of ways. > > I (personally) doesn't find any prohibition in st. 3.0 to have many /22 per LIR. Number 3 after the _link_ not 3.0 (#51 anchor) Number 5.1 paragraph No.3 "The LIR must confirm it will make assignment(s) from the allocation." so the LIR opened and requesting the /22 only for selling does not fullfill the policy. Without a real assignment , the /22 may never be sold, as the LIR first need to fullfill his confirmation > > 23.04.2015, 15:39, "Opteamax GmbH" : >> On 23.04.2015 14:31, Vladimir Andreev wrote: >>>> openig a bunch of LIR only for transfering their /22 V4 to another LIR >>>> is - and always was - abusing the policy. >>> Any links to documents proving it? >> >> https://www.ripe.net/publications/docs/ripe-643#51 >> >> Number 3 >>>> but for me the way you are proposing to run a "business" is >>>> almost the same as the one of a guy selling stolen stuff ... >>> Such a comparison is incorrect. >> >> Maybe my comparison lacks do to difficulties translating into english: >> The guy selling the stuff does not (necessarily) know that the one he >> bought it from stole it. There are some of those shops, everybody know >> that they not ask where stuff comes from, but nobody can blame the >> shopowner ... >> >> Jens >>> 23.04.2015, 15:27, "Opteamax GmbH" : >>>> Hello Gabriel, >>>> >>>> openig a bunch of LIR only for transfering their /22 V4 to another LIR >>>> is - and always was - abusing the policy. So you acutally don't want to >>>> speak against the change of Transfer-Policy but want to keep the >>>> backdoor open. >>>> >>>> So if you think the last /8 policy is not OK - where consensus was >>>> reached - you should stand up and make a change proposal for that. >>>> >>>> Knowing the way to bypass policy still does not mean, that it is >>>> fair/legal. IMHO LIRs which are willingly abusing policies shall get >>>> their entire resources withdrawn immediately, as they are not willing to >>>> be part of the community, so shall not profit from community. >>>> >>>> Sorry, but for me the way you are proposing to run a "business" is >>>> almost the same as the one of a guy selling stolen stuff ... >>>> >>>> Regards >>>> Jens >>>> >>>> On 23.04.2015 14:05, Infinity Telecom SRL wrote: >>>>> Hello Gert, >>>>> >>>>> "at the transfer services" i saw sellers that want 17-20 USD per IP, >>>>> this is crazy, do you want forward ? >>>>> >>>>> Do you think this is a normal ? >>>>> >>>>> If right now they ask soo much even when they know someone like me can >>>>> open a new LIR an close after 1 year. >>>>> >>>>> What will happen when someone like me will open a LIR and pay 2 yrs >>>>> before to move the IPs to the old LIR >>>>> >>>>> I tell you what will happen, the sellers will put another 5-7 USD per >>>>> IP, for sure. >>>>> >>>>> Most of the guys that are pro this proposal have large blocks for sell.. >>>>> >>>>> I dont have large blocks.. i want to keep my IPs and have more resource.. >>>>> >>>>> Thank you. >>>>> >>>>> /-- >>>>> Cu stima, >>>>> Gabriel Voitis | Sales Manager >>>>> /voitis at infinitytelecom.ro >>>>> >>>>> /INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 >>>>> Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 >>>>> /contact at infinitytelecom.ro >>>> -- >>>> Opteamax GmbH - RIPE-Team >>>> Jens Ott >>>> >>>> Opteamax GmbH >>>> >>>> Simrockstr. 4b >>>> 53619 Rheinbreitbach >>>> >>>> Tel.: +49 2224 969500 >>>> Fax: +49 2224 97691059 >>>> Email: jo at opteamax.de >>>> >>>> HRB: 23144, Amtsgericht Montabaur >>>> Umsatzsteuer-ID.: DE264133989 >>> -- >>> With best regards, Vladimir Andreev >>> General director, QuickSoft LLC >>> Tel: +7 903 1750503 >>> >>> >> >> -- >> Opteamax GmbH - RIPE-Team >> Jens Ott >> >> Opteamax GmbH >> >> Simrockstr. 4b >> 53619 Rheinbreitbach >> >> Tel.: +49 2224 969500 >> Fax: +49 2224 97691059 >> Email: jo at opteamax.de >> >> HRB: 23144, Amtsgericht Montabaur >> Umsatzsteuer-ID.: DE264133989 > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 > > !DSPAM:637,5538ed66295344115222871! > -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From gert at space.net Thu Apr 23 14:57:01 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 14:57:01 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3734711429793156@web27g.yandex.ru> References: <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> Message-ID: <20150423125701.GB54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 03:45:56PM +0300, Vladimir Andreev wrote: > > On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: > > > > The size of the allocation made will be exactly one /22. > > > > The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). > > > > The LIR must confirm it will make assignment(s) from the allocation. > > Please point me where in quoted text you see any prohibition to open and merge LIRs with /22's? It is not prohibited, and we're not trying to achieve that - prohibiting is easy, enabling useful processes while discouraging abuse is the tricky part. The spirit of this policy should be very clear to everybody, and we're working on encouraging compliance with the spirit, not finding loopholes in the letters. In other words: we don't really care if your business model suffers if you can't fast-trade /22s anymore - it would be a welcome side effect. 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 vladimir at quick-soft.net Thu Apr 23 14:57:44 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 15:57:44 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> Message-ID: <3809301429793864@web27g.yandex.ru> So you acknowledge that you don't like that people do business? Right? If yes, it's you personal meaning because you are affiliated person (it's pleasant to you to know nobody can earn money such way). I speaking about NOT ACCEPTING proposals which lead to any advantage (including moral delight that other can't do their business) to some group of members (possible little). If such proposal HAS exact reasoning ? OK, let'e discuss! 23.04.2015, 15:50, "Mikael Abrahamsson" : > On Thu, 23 Apr 2015, Vladimir Andreev wrote: >>> ?On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: >>> >>> ?The size of the allocation made will be exactly one /22. >>> >>> ?The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). >>> >>> ?The LIR must confirm it will make assignment(s) from the allocation. >> ?Please point me where in quoted text you see any prohibition to open and merge LIRs with /22's? > > We can't do that, so what we're trying to do is make it less profitable to > do so. > > But the INTENTION behind the current policy was to allow a new ISP (or > other type of entity) a /22 to allow them to participate in IPv4 world > 5-10 years down the line. It was NOT to allow people to use administrative > tricks to cheaply acquire IPv4 space for use in a single business. --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ripe at opteamax.de Thu Apr 23 14:59:14 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 23 Apr 2015 14:59:14 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3734711429793156@web27g.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> Message-ID: <5538ECA2.2020304@opteamax.de> On 23.04.2015 14:45, Vladimir Andreev wrote: >> The LIR must confirm it will make assignment(s) from the >> allocation. > > Please point me where in quoted text you see any prohibition to > open and merge LIRs with /22's? Buying and merging is not prohibited, _but_ opening LIR, requesting /22 and selling /22 and closing LIR ist probibited, as the LIR did not fullfil his confirmed will to make assignments!! BR Jens > > 23.04.2015, 15:43, "Gert Doering" : >> Hi, >> >> On Thu, Apr 23, 2015 at 03:41:10PM +0300, Vladimir Andreev >> wrote: >>> And why receiving /22's for own company is "legitimate" and for >>> selling is not? >> >> *one* /22 per LIR is the last-/8 policy >> >> not "open lots of LIRs, so a single LIR can have multiple /22s in >> the end, and circumvent the one-LIR-one-/22-allocated policy". >> >> Gert Doering -- APWG chair -- have you enabled IPv6 on something >> today...? >> >> SpaceNet AG Vorstand: Sebastian v. >> Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >> Grundner-Culemann D-80807 Muenchen HRB: 136055 >> (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: >> DE813185279 > > -- With best regards, Vladimir Andreev General director, QuickSoft > LLC Tel: +7 903 1750503 > > > !DSPAM:637,5538ec5f290721315150076! > -- Jens Ott - Gesch?ftsf?hrer - Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Gesch?ftsf?hrer: Jens Ott Umsatzsteuer-ID.: DE264133989 -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From vladimir at quick-soft.net Thu Apr 23 15:00:42 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 16:00:42 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538EB8E.7080604@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <1533248069.20150423150506@infinitytelecom.ro> <5538E519.7010100@opteamax.de> <3639401429792277@web27g.yandex.ru> <5538E804.8010606@opteamax.de> <3762761429793430@web27g.yandex.ru> <5538EB8E.7080604@opteamax.de> Message-ID: <3827991429794042@web27g.yandex.ru> As variant: 1. I receive /22 2. I create 2 x inetnum with type ASSIGNED PA 3. I announced it for about 1 month 4. I sell it Such way I fully correspond to 5.* statements. 23.04.2015, 15:54, "Opteamax GmbH" : > On 23.04.2015 14:50, Vladimir Andreev wrote: >> ?3.0 Goals of the Internet Registry System >> >> ?can be treated by a lot of ways. >> >> ?I (personally) doesn't find any prohibition in st. 3.0 to have many /22 per LIR. > > Number 3 after the _link_ not 3.0 (#51 anchor) > > Number 5.1 paragraph No.3 > > "The LIR must confirm it will make assignment(s) from the allocation." > > so the LIR opened and requesting the /22 only for selling does not > fullfill the policy. Without a real assignment , the /22 may never be > sold, as the LIR first need to fullfill his confirmation >> ?23.04.2015, 15:39, "Opteamax GmbH" : >>> ?On 23.04.2015 14:31, Vladimir Andreev wrote: >>>>> ???openig a bunch of LIR only for transfering their /22 V4 to another LIR >>>>> ???is - and always was - abusing the policy. >>>> ??Any links to documents proving it? >>> ?https://www.ripe.net/publications/docs/ripe-643#51 >>> >>> ?Number 3 >>>>> ??but for me the way you are proposing to run a "business" is >>>>> ??almost the same as the one of a guy selling stolen stuff ... >>>> ??Such a comparison is incorrect. >>> ?Maybe my comparison lacks do to difficulties translating into english: >>> ?The guy selling the stuff does not (necessarily) know that the one he >>> ?bought it from stole it. There are some of those shops, everybody know >>> ?that they not ask where stuff comes from, but nobody can blame the >>> ?shopowner ... >>> >>> ?Jens >>>> ??23.04.2015, 15:27, "Opteamax GmbH" : >>>>> ???Hello Gabriel, >>>>> >>>>> ???openig a bunch of LIR only for transfering their /22 V4 to another LIR >>>>> ???is - and always was - abusing the policy. So you acutally don't want to >>>>> ???speak against the change of Transfer-Policy but want to keep the >>>>> ???backdoor open. >>>>> >>>>> ???So if you think the last /8 policy is not OK - where consensus was >>>>> ???reached - you should stand up and make a change proposal for that. >>>>> >>>>> ???Knowing the way to bypass policy still does not mean, that it is >>>>> ???fair/legal. IMHO LIRs which are willingly abusing policies shall get >>>>> ???their entire resources withdrawn immediately, as they are not willing to >>>>> ???be part of the community, so shall not profit from community. >>>>> >>>>> ???Sorry, but for me the way you are proposing to run a "business" is >>>>> ???almost the same as the one of a guy selling stolen stuff ... >>>>> >>>>> ???Regards >>>>> ???Jens >>>>> >>>>> ???On 23.04.2015 14:05, Infinity Telecom SRL wrote: >>>>>> ????Hello Gert, >>>>>> >>>>>> ????"at the transfer services" ?i saw sellers that want 17-20 USD per IP, >>>>>> ?????this is crazy, do you want forward ? >>>>>> >>>>>> ????Do you think this is a normal ? >>>>>> >>>>>> ????If right now they ask soo much even when they know someone like me can >>>>>> ????open a new LIR an close after 1 year. >>>>>> >>>>>> ????What will happen when someone like me will open a LIR and pay 2 yrs >>>>>> ????before to move the IPs ?to the old LIR >>>>>> >>>>>> ????I tell you what will happen, ?the sellers will put another 5-7 USD per >>>>>> ????IP, for sure. >>>>>> >>>>>> ????Most of the guys that are pro this proposal have large blocks for sell.. >>>>>> >>>>>> ????I dont have large blocks.. i want to keep my IPs and have more resource.. >>>>>> >>>>>> ????Thank you. >>>>>> >>>>>> ????/-- >>>>>> ????Cu stima, >>>>>> ????Gabriel Voitis | Sales Manager >>>>>> ????/voitis at infinitytelecom.ro >>>>>> >>>>>> ????/INFINITY TELECOM SRL ?| ?Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 >>>>>> ????Mobil: +40 0725 677 477 ?| ?Tel: +40 021 7808805 ?| ?Fax: +40 021 7808806 >>>>>> ????/contact at infinitytelecom.ro >>>>> ???-- >>>>> ???Opteamax GmbH - RIPE-Team >>>>> ???Jens Ott >>>>> >>>>> ???Opteamax GmbH >>>>> >>>>> ???Simrockstr. 4b >>>>> ???53619 Rheinbreitbach >>>>> >>>>> ???Tel.: ?+49 2224 969500 >>>>> ???Fax: ??+49 2224 97691059 >>>>> ???Email: jo at opteamax.de >>>>> >>>>> ???HRB: 23144, Amtsgericht Montabaur >>>>> ???Umsatzsteuer-ID.: DE264133989 >>>> ??-- >>>> ??With best regards, Vladimir Andreev >>>> ??General director, QuickSoft LLC >>>> ??Tel: +7 903 1750503 >>> ?-- >>> ?Opteamax GmbH - RIPE-Team >>> ?Jens Ott >>> >>> ?Opteamax GmbH >>> >>> ?Simrockstr. 4b >>> ?53619 Rheinbreitbach >>> >>> ?Tel.: ?+49 2224 969500 >>> ?Fax: ??+49 2224 97691059 >>> ?Email: jo at opteamax.de >>> >>> ?HRB: 23144, Amtsgericht Montabaur >>> ?Umsatzsteuer-ID.: DE264133989 >> ?-- >> ?With best regards, Vladimir Andreev >> ?General director, QuickSoft LLC >> ?Tel: +7 903 1750503 >> >> ?!DSPAM:637,5538ed66295344115222871! > > -- > Opteamax GmbH - RIPE-Team > Jens Ott > > Opteamax GmbH > > Simrockstr. 4b > 53619 Rheinbreitbach > > Tel.: ?+49 2224 969500 > Fax: ??+49 2224 97691059 > Email: jo at opteamax.de > > HRB: 23144, Amtsgericht Montabaur > Umsatzsteuer-ID.: DE264133989 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From vladimir at quick-soft.net Thu Apr 23 15:02:26 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 16:02:26 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538ECA2.2020304@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538ECA2.2020304@opteamax.de> Message-ID: <3839241429794146@web27g.yandex.ru> I answered to this question in another thread. I can announce my /22 for some time. And after that sell it 23.04.2015, 15:59, "Opteamax GmbH" : > On 23.04.2015 14:45, Vladimir Andreev wrote: >>> ?The LIR must confirm it will make assignment(s) from the >>> ?allocation. >> ?Please point me where in quoted text you see any prohibition to >> ?open and merge LIRs with /22's? > > Buying and merging is not prohibited, _but_ opening LIR, requesting > /22 and selling /22 and closing LIR ist probibited, as the LIR did not > fullfil his confirmed will to make assignments!! > > BR > Jens >> ?23.04.2015, 15:43, "Gert Doering" : >>> ?Hi, >>> >>> ?On Thu, Apr 23, 2015 at 03:41:10PM +0300, Vladimir Andreev >>> ?wrote: >>>> ?And why receiving /22's for own company is "legitimate" and for >>>> ?selling is not? >>> ?*one* /22 per LIR is the last-/8 policy >>> >>> ?not "open lots of LIRs, so a single LIR can have multiple /22s in >>> ?the end, and circumvent the one-LIR-one-/22-allocated policy". >>> >>> ?Gert Doering -- APWG chair -- have you enabled IPv6 on something >>> ?today...? >>> >>> ?SpaceNet AG ???????????????????????Vorstand: Sebastian v. >>> ?Bomhard Joseph-Dollinger-Bogen 14 ?????????Aufsichtsratsvors.: A. >>> ?Grundner-Culemann D-80807 Muenchen ??????????????????HRB: 136055 >>> ?(AG Muenchen) Tel: +49 (0)89/32356-444 ??????????USt-IdNr.: >>> ?DE813185279 >> ?-- With best regards, Vladimir Andreev General director, QuickSoft >> ?LLC Tel: +7 903 1750503 >> >> ?!DSPAM:637,5538ec5f290721315150076! > > -- > Jens Ott > - Gesch?ftsf?hrer - > > Opteamax GmbH > > Simrockstr. 4b > 53619 Rheinbreitbach > > Tel.: ?+49 2224 969500 > Fax: ??+49 2224 97691059 > Email: jo at opteamax.de > > HRB: 23144, Amtsgericht Montabaur > Gesch?ftsf?hrer: Jens Ott > Umsatzsteuer-ID.: DE264133989 > > -- > Opteamax GmbH - RIPE-Team > Jens Ott > > Opteamax GmbH > > Simrockstr. 4b > 53619 Rheinbreitbach > > Tel.: ?+49 2224 969500 > Fax: ??+49 2224 97691059 > Email: jo at opteamax.de > > HRB: 23144, Amtsgericht Montabaur > Umsatzsteuer-ID.: DE264133989 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ip at infinitytelecom.ro Thu Apr 23 15:02:54 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Thu, 23 Apr 2015 16:02:54 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538ECA2.2020304@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538ECA2.2020304@opteamax.de> Message-ID: <673847425.20150423160254@infinitytelecom.ro> Hello Opteamax, And if i dont sell the IPv4 ? And its just for my company its prohibited ? Its prohibited because i dont have enough money to buy from sellers ? Thank you. -- Cu stima, Gabriel Voitis | Sales Manager voitis at infinitytelecom.ro INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 contact at infinitytelecom.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at quick-soft.net Thu Apr 23 15:05:46 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 16:05:46 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423125701.GB54385@Space.Net> References: <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> Message-ID: <3861051429794346@web27g.yandex.ru> OK. Let's it's welcome side effect. Please answer me the following question: What reasoning (not purpose) has current proposal? 23.04.2015, 15:57, "Gert Doering" : > Hi, > > On Thu, Apr 23, 2015 at 03:45:56PM +0300, Vladimir Andreev wrote: >>> ?On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: >>> >>> ?The size of the allocation made will be exactly one /22. >>> >>> ?The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). >>> >>> ?The LIR must confirm it will make assignment(s) from the allocation. >> ?Please point me where in quoted text you see any prohibition to open and merge LIRs with /22's? > > It is not prohibited, and we're not trying to achieve that - prohibiting > is easy, enabling useful processes while discouraging abuse is the > tricky part. > > The spirit of this policy should be very clear to everybody, and we're > working on encouraging compliance with the spirit, not finding loopholes > in the letters. > > In other words: we don't really care if your business model suffers if > you can't fast-trade /22s anymore - it would be a welcome side effect. > > 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 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From gert at space.net Thu Apr 23 15:12:28 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 15:12:28 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3861051429794346@web27g.yandex.ru> References: <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> Message-ID: <20150423131228.GC54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 04:05:46PM +0300, Vladimir Andreev wrote: > OK. Let's it's welcome side effect. > > Please answer me the following question: > > What reasoning (not purpose) has current proposal? "The RIPE NCC discovered that people are abusing the current policy" Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 ripe at opteamax.de Thu Apr 23 15:20:49 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 23 Apr 2015 15:20:49 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <673847425.20150423160254@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538ECA2.2020304@opteamax.de> <673847425.20150423160254@infinitytelecom.ro> Message-ID: <5538F1B1.1000805@opteamax.de> As mentioned in other mails, creating a LIR to optain /22 V4 without needing it (for that LIR) is the abuse of policy ... So you get an advantage against competitors which respect the last /8 policy and it's intention ... BR Jens On 23.04.2015 15:02, Infinity Telecom SRL wrote: > Hello Opteamax, > > > And if i dont sell the IPv4 ? > And its just for my company its prohibited ? > Its prohibited because i dont have enough money to buy from sellers ? > > Thank you. > > > /-- > Cu stima, > Gabriel Voitis | Sales Manager > /voitis at infinitytelecom.ro > > /INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 > Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 > /contact at infinitytelecom.ro > !DSPAM:637,5538f04a306641225810352! -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From vladimir at quick-soft.net Thu Apr 23 15:22:51 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 16:22:51 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423131228.GC54385@Space.Net> References: <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> Message-ID: <3970461429795371@web27g.yandex.ru> What from this quotation is? Please give me a link. And what statement exactly of the current policy is abusing? Also I would like to receive concrete answer to the question: Why using multiple /22's for own company is not abusing but selling is abusing? If anybody from members want to forbid /22 selling let's forbid multiple /22 receiving at all! It would be fair regarding all other members! And because current proposal REMAINS hole for receiving ANY number of /22 for own company I have all reasons to think that current proposal has it's ONLY aim to make life harder for members that want to sell their /22's. 23.04.2015, 16:12, "Gert Doering" : > ?Hi, > > ?On Thu, Apr 23, 2015 at 04:05:46PM +0300, Vladimir Andreev wrote: >> ??OK. Let's it's welcome side effect. >> >> ??Please answer me the following question: >> >> ??What reasoning (not purpose) has current proposal? > ?"The RIPE NCC discovered that people are abusing the current policy" > > ?Gert Doering > ?????????-- APWG chair > ?-- > ?have you enabled IPv6 on something today...? > > ?SpaceNet AG ???????????????????????Vorstand: Sebastian v. Bomhard > ?Joseph-Dollinger-Bogen 14 ?????????Aufsichtsratsvors.: A. Grundner-Culemann > ?D-80807 Muenchen ??????????????????HRB: 136055 (AG Muenchen) > ?Tel: +49 (0)89/32356-444 ??????????USt-IdNr.: DE813185279 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ak at list.ak.cx Thu Apr 23 15:25:14 2015 From: ak at list.ak.cx (Andre Keller) Date: Thu, 23 Apr 2015 15:25:14 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423131228.GC54385@Space.Net> References: <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> Message-ID: <5538F2BA.6000007@list.ak.cx> Hi, I guess there is not much point in discussing this any further atm, as the positions are pretty clear. Just repeating ones arguments over and over does not make them more or less valid. Cant we just wait for the impact analysis to be published and then consult for (rough) consensous? Regards Andr? From noc at ntx.ru Thu Apr 23 15:28:32 2015 From: noc at ntx.ru (NTX NOC) Date: Thu, 23 Apr 2015 16:28:32 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <015101d07dbc$7d127670$77376350$@a2b-internet.com> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> Message-ID: <5538F380.9030103@ntx.ru> Nothing bad in the things when people need IPs and get them. IPs should cost nothing. It's just numbers. The luck of IPs - it's the RIPEs falt I guese. As far as we see a lot of IPs are not routed and not used. But some small companies own a lot of IPs space never realy used. Another one trick - that FREE IPs number is growing. https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph https://labs.ripe.net/statistics - LIR number grows becouse it's not other way to get some IPs. So the most profit comes to RIPE, but we still have the same LIR fees, they are not going down as the number of real companys that use RIPE services. Vadim On 23.04.2015 14:55, Erik Bais wrote: > Re: [address-policy-wg] Transfer Requirements for IPv4 Allocations > > Hi Gabriel, > > I agree with you that it might satisfy a specific need for a company > at a certain time to open a new LIR.. > > I?ve seen LIR?s request for a /22 that didn?t even knew they could > still get a free /22 from the RIPE NCC. . . . > > The goal of this proposal is to stop the abuse of opening a new LIR, > transferring the /22 for profit to another LIR and close the LIR. > > As it is against the original intent of the final /8 last /22 > procedure (https://www.ripe.net/publications/docs/ripe-643#51 ) > > And specifically : > > Point 3 : The LIR must confirm it will make assignment(s) from the > allocation. > > The intention of the current policy and why it was made as it was in > the past, is to give EVERY LIR 1 additional /22 ? and also have enough > for new entries in the market ( looking at the new sign-ups of LIR > typically in the market, if you look at how that number grew over the > last couple years.. ) for at least 5 to 6 years ? > > Point 3 doesn?t say .. The LIR must confirm it will make assignment(s) > from the allocation or transfer parts or the complete allocation for > profit to another LIR. > > This policy text was never intended to have new LIR?s being setup and > closed just to get cheap IP?s ? And I?m pretty sure that if that was > foreseen at the time, that the respective author would have closed > that gap at the time ? > > As that is in the past ? and this is currently being abused .. It is > time to fix this and close this gap. > > Regards, > > Erik Bais > > *Van:*address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] > *Namens *Infinity Telecom SRL > *Verzonden:* donderdag 23 april 2015 13:41 > *Aan:* Erik Bais; address-policy-wg at ripe.net > *Onderwerp:* Re: [address-policy-wg] Transfer Requirements for IPv4 > Allocations > > Hello Erik, > > > Why someone will come to me to get new IPs, when they can open a LIR > by them self ? Without extra cost ? > > I think everyone that open a LIR right now its because they dont have > any chance to BUY from sellers.. > > > Thank you. > > > /-- > Cu stima, > Gabriel Voitis | Sales Manager > /voitis at infinitytelecom.ro > > /INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 > Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 > /contact at infinitytelecom.ro > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ak at list.ak.cx Thu Apr 23 15:33:26 2015 From: ak at list.ak.cx (Andre Keller) Date: Thu, 23 Apr 2015 15:33:26 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538F380.9030103@ntx.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <5538F380.9030103@ntx.ru> Message-ID: <5538F4A6.6020800@list.ak.cx> Hi, On 23.04.2015 15:28, NTX NOC wrote: > So the most profit comes to RIPE, but we still have the same LIR fees, Thats just not true. Regards Andr? From gert at space.net Thu Apr 23 15:35:33 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 15:35:33 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3970461429795371@web27g.yandex.ru> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> Message-ID: <20150423133533.GD54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 04:22:51PM +0300, Vladimir Andreev wrote: > What from this quotation is? Please give me a link. > And what statement exactly of the current policy is abusing? Stop turning in circles. This question has been answered before. > Also I would like to receive concrete answer to the question: > Why using multiple /22's for own company is not abusing but selling is abusing? Because the policy says "one /22 per 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 Apr 23 15:38:59 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 15:38:59 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538F2BA.6000007@list.ak.cx> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <5538F2BA.6000007@list.ak.cx> Message-ID: <20150423133859.GE54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 03:25:14PM +0200, Andre Keller wrote: > Cant we just wait for the impact analysis to be published and then > consult for (rough) consensous? This is actually an important aspect: this discussion right now is interesting, without any doubt, but as far as consensus building for the proposal under discussion, it does not exist(!). The proposal is right now neither in disussion phase (done, chairs decided that there is enough support to go ahead) nor in review phase (starts when the impact analysis is published and Marco formally announces the new phase). So, whatever you say before the review phase starts has no formal effect on the WG chair decision on whether or not we have consensus. (And be warned, even after review phase starts, statements of the sort "THIS WILL RUIN MY BUSINESS!" will not be given very much weight, as we all know the numbers - and *any* business that still relies on IPv4-only is going to face rough waters) 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 vladimir at quick-soft.net Thu Apr 23 15:39:49 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 16:39:49 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423133533.GD54385@Space.Net> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> Message-ID: <4065141429796389@web27g.yandex.ru> > Because the policy says "one /22 per LIR". Policy sets this rule only for /22's received from RIPE NCC. Indeed, RIPE NCC will not allocate you several /22. I have tested it :) The only way is to receive allocations from other LIR (own or belonging to other companies). An such order doesn't abuse any policies. If we suppose having multiple /22 per LIR is abusing then main "abuser" is RIPE NCC since RIPE NCC makes transfers and LIR merging allowing to receive second /22 etc. 23.04.2015, 16:35, "Gert Doering" : > Hi, > > On Thu, Apr 23, 2015 at 04:22:51PM +0300, Vladimir Andreev wrote: >> ?What from this quotation is? Please give me a link. >> ?And what statement exactly of the current policy is abusing? > > Stop turning in circles. ?This question has been answered before. >> ?Also I would like to receive concrete answer to the question: >> ?Why using multiple /22's for own company is not abusing but selling is abusing? > > Because the policy says "one /22 per 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 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From vladimir at quick-soft.net Thu Apr 23 15:43:06 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 16:43:06 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <4065141429796389@web27g.yandex.ru> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> Message-ID: <4084541429796586@web27g.yandex.ru> Resuming my position is: - Current proposal doesn't aim effect it was created for (/22 receiving is possible, transfer due to merger/acquisition is possible) - Current proposal has not clear reasoning (according to my calculations, exhaustion due to having multiple /22's per LIR is not so serious) - Opening multiple LIR's and having multiple /22 is not abusing (because policies don't contain any statements prohibiting this) So I haven't ANY reason to support this proposal. 23.04.2015, 16:39, "Vladimir Andreev" : >> ?Because the policy says "one /22 per LIR". > > Policy sets this rule only for /22's received from RIPE NCC. > > Indeed, RIPE NCC will not allocate you several /22. I have tested it :) > > The only way is to receive allocations from other LIR (own or belonging to other companies). An such order doesn't abuse any policies. > > If we suppose having multiple /22 per LIR is abusing then main "abuser" is RIPE NCC since RIPE NCC makes transfers and LIR merging allowing to receive second /22 etc. > > 23.04.2015, 16:35, "Gert Doering" : >> ?Hi, >> >> ?On Thu, Apr 23, 2015 at 04:22:51PM +0300, Vladimir Andreev wrote: >>> ??What from this quotation is? Please give me a link. >>> ??And what statement exactly of the current policy is abusing? >> ?Stop turning in circles. ?This question has been answered before. >>> ??Also I would like to receive concrete answer to the question: >>> ??Why using multiple /22's for own company is not abusing but selling is abusing? >> ?Because the policy says "one /22 per 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 > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ripe at opteamax.de Thu Apr 23 15:49:38 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 23 Apr 2015 15:49:38 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <4065141429796389@web27g.yandex.ru> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> Message-ID: <5538F872.90900@opteamax.de> On 23.04.2015 15:39, Vladimir Andreev wrote: > > If we suppose having multiple /22 per LIR is abusing then main > "abuser" is RIPE NCC since RIPE NCC makes transfers and LIR merging > allowing to receive second /22 etc. > So you agree my initial reply that actually the change does not go far enough, it'd be better to completely prohibited selling IP (v4) and instead enforce withdrawing of not announced IP-Space aand returning it into the pool? That way I am pretty sure we could quickly loosen the current /8 policy and return to a policy allowing requests of more then one /22 if need is shown .... and need may NOT be selling, but that'd be forbidden anyway then ;) BR Jens -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From vladimir at quick-soft.net Thu Apr 23 16:07:37 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 17:07:37 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538F872.90900@opteamax.de> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F872.90900@opteamax.de> Message-ID: <4158851429798057@web13g.yandex.ru> It's was just a logical chain. Prerequisite is "having multiple /22 in LIR is abusing". In my opinion members that open multiple LIR's and sell received /22's are not abusers and RIPE NCC is not abuser. But if anybody says " abuses policies" that man have to declare "RIPE NCC is also abusing policies". 23.04.2015, 16:49, "Opteamax GmbH" : > ?On 23.04.2015 15:39, Vladimir Andreev wrote: >> ??If we suppose having multiple /22 per LIR is abusing then main >> ??"abuser" is RIPE NCC since RIPE NCC makes transfers and LIR merging >> ??allowing to receive second /22 etc. > ?So you agree my initial reply that actually the change does not go far > ?enough, it'd be better to completely prohibited selling IP (v4) and > ?instead enforce withdrawing of not announced IP-Space aand returning > ?it into the pool? > > ?That way I am pretty sure we could quickly loosen the current /8 > ?policy and return to a policy allowing requests of more then one /22 > ?if need is shown .... and need may NOT be selling, but that'd be > ?forbidden anyway then ;) > > ?BR Jens > > ?-- > ?Opteamax GmbH - RIPE-Team > ?Jens Ott > > ?Opteamax GmbH > > ?Simrockstr. 4b > ?53619 Rheinbreitbach > > ?Tel.: ?+49 2224 969500 > ?Fax: ??+49 2224 97691059 > ?Email: jo at opteamax.de > > ?HRB: 23144, Amtsgericht Montabaur > ?Umsatzsteuer-ID.: DE264133989 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From jo at opteamax.de Thu Apr 23 14:51:40 2015 From: jo at opteamax.de (Jens Ott - Opteamax GmbH) Date: Thu, 23 Apr 2015 14:51:40 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3734711429793156@web27g.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> Message-ID: <5538EADC.2070008@opteamax.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 23.04.2015 14:45, Vladimir Andreev wrote: >> The LIR must confirm it will make assignment(s) from the >> allocation. > > Please point me where in quoted text you see any prohibition to > open and merge LIRs with /22's? Buying and merging is not prohibited, _but_ opening LIR, requesting /22 and selling /22 and closing LIR ist probibited, as the LIR did not fullfil his confirmed will to make assignments!! BR Jens > > 23.04.2015, 15:43, "Gert Doering" : >> Hi, >> >> On Thu, Apr 23, 2015 at 03:41:10PM +0300, Vladimir Andreev >> wrote: >>> And why receiving /22's for own company is "legitimate" and for >>> selling is not? >> >> *one* /22 per LIR is the last-/8 policy >> >> not "open lots of LIRs, so a single LIR can have multiple /22s in >> the end, and circumvent the one-LIR-one-/22-allocated policy". >> >> Gert Doering -- APWG chair -- have you enabled IPv6 on something >> today...? >> >> SpaceNet AG Vorstand: Sebastian v. >> Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >> Grundner-Culemann D-80807 Muenchen HRB: 136055 >> (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: >> DE813185279 > > -- With best regards, Vladimir Andreev General director, QuickSoft > LLC Tel: +7 903 1750503 > > > !DSPAM:637,5538ec5f290721315150076! > - -- Jens Ott - - Gesch?ftsf?hrer - Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Gesch?ftsf?hrer: Jens Ott Umsatzsteuer-ID.: DE264133989 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVOOrXAAoJECrmRJLVnvx6HRcIAK+EIe7EU2OCDjNC1f5v1JKd xEIBbGiQN7k1TeQI2lPbW1WLZHGxHrFp9PCTHnT+T9uihIdnaj+O9Zv/Bq6MCy9r qNopxk5DYOaljxcsiPuDHDNj1jvxbOmkSVSbaoZJ5VFlm4qLhZSOjvMJnYGvzBR8 e/qX00EQAncyXSU4Iq59D9BK43iyYqvY/8Bvr1f7PSbNluEHM4zl6jHUoJR0WtDd 8hlpWpjxz+tWtW9XhZm6EzzCwlnwrhdfTUr6sTA+f9pXJF2ypLf8SMJavi+Of2zi MXzCrgO+GJzvIkcqxfjpzyQuoDNesN8fI9KrLk0Q1PYTv7MXZQquwVLbwx+79zc= =LVL7 -----END PGP SIGNATURE----- From jo at opteamax.de Thu Apr 23 15:46:45 2015 From: jo at opteamax.de (Jens Ott - Opteamax GmbH) Date: Thu, 23 Apr 2015 15:46:45 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <4065141429796389@web27g.yandex.ru> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> Message-ID: <5538F7C5.5060005@opteamax.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 23.04.2015 15:39, Vladimir Andreev wrote: > > If we suppose having multiple /22 per LIR is abusing then main > "abuser" is RIPE NCC since RIPE NCC makes transfers and LIR merging > allowing to receive second /22 etc. > So you agree my initial reply that actually the change does not go far enough, it'd be better to completely prohibited selling IP (v4) and instead enforce withdrawing of not announced IP-Space aand returning it into the pool? That way I am pretty sure we could quickly loosen the current /8 policy and return to a policy allowing requests of more then one /22 if need is shown .... and need may NOT be selling, but that'd be forbidden anyway then ;) BR - -- Jens Ott - - Gesch?ftsf?hrer - Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Gesch?ftsf?hrer: Jens Ott Umsatzsteuer-ID.: DE264133989 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVOPfFAAoJECrmRJLVnvx6y/YH/0kKU6Utix3nbuwi3rs8TwMn LvrVbuzRosgU78LlNc+0rfY/BFCKPLQF0WFm5bCHn5ZkRH21jr8ETkSGWgnGCge2 LuboUF5E9cPpcahMJw4ZP6WNyfZkNQzzXckaALqmN8j2snIfmfutvoiZY6zkjW+7 cLu0ePgnsN4ZeopMSDsRubY65oChrhmKfA5dTvB6sQdEsjmj7jL1dAGVx5A74NTH 2Z4a52c/VGccs+/wPDyaqLc9RL5if3gqg6Om0IB7bJglmcKaVoxESyDmb3heFXNP 0YT3Psl/ySTGPlspUztuMyefektjedB4ndmoId5n5Zjxd/bI3XKmeBAPyKTdxTE= =MjkK -----END PGP SIGNATURE----- From vladimir at quick-soft.net Thu Apr 23 16:13:44 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 17:13:44 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538EADC.2070008@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538EADC.2070008@opteamax.de> Message-ID: <4082911429798424@web22j.yandex.ru> OK. I explain this one more time :) Just after receiving /22 you should create 2 x "inetnum" (each /23) with type ASSIGNED PA. Formally you are right since you have made assignments. Furthermore you can create "route" object and announce your /22. In such case nobody can say "you don't use you allocation" or "you didn't make assignments". 23.04.2015, 17:08, "Jens Ott - Opteamax GmbH" : > On 23.04.2015 14:45, Vladimir Andreev wrote: >>> ?The LIR must confirm it will make assignment(s) from the >>> ?allocation. >> ?Please point me where in quoted text you see any prohibition to >> ?open and merge LIRs with /22's? > > Buying and merging is not prohibited, _but_ opening LIR, requesting > /22 and selling /22 and closing LIR ist probibited, as the LIR did not > fullfil his confirmed will to make assignments!! > > BR > Jens >> ?23.04.2015, 15:43, "Gert Doering" : >>> ?Hi, >>> >>> ?On Thu, Apr 23, 2015 at 03:41:10PM +0300, Vladimir Andreev >>> ?wrote: >>>> ?And why receiving /22's for own company is "legitimate" and for >>>> ?selling is not? >>> ?*one* /22 per LIR is the last-/8 policy >>> >>> ?not "open lots of LIRs, so a single LIR can have multiple /22s in >>> ?the end, and circumvent the one-LIR-one-/22-allocated policy". >>> >>> ?Gert Doering -- APWG chair -- have you enabled IPv6 on something >>> ?today...? >>> >>> ?SpaceNet AG ???????????????????????Vorstand: Sebastian v. >>> ?Bomhard Joseph-Dollinger-Bogen 14 ?????????Aufsichtsratsvors.: A. >>> ?Grundner-Culemann D-80807 Muenchen ??????????????????HRB: 136055 >>> ?(AG Muenchen) Tel: +49 (0)89/32356-444 ??????????USt-IdNr.: >>> ?DE813185279 >> ?-- With best regards, Vladimir Andreev General director, QuickSoft >> ?LLC Tel: +7 903 1750503 >> >> ?!DSPAM:637,5538ec5f290721315150076! > > - -- > Jens Ott > - - Gesch?ftsf?hrer - > > Opteamax GmbH > > Simrockstr. 4b > 53619 Rheinbreitbach > > Tel.: ?+49 2224 969500 > Fax: ??+49 2224 97691059 > Email: jo at opteamax.de > > HRB: 23144, Amtsgericht Montabaur > Gesch?ftsf?hrer: Jens Ott > Umsatzsteuer-ID.: DE264133989 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQEcBAEBCAAGBQJVOOrXAAoJECrmRJLVnvx6HRcIAK+EIe7EU2OCDjNC1f5v1JKd >> xEIBbGiQN7k1TeQI2lPbW1WLZHGxHrFp9PCTHnT+T9uihIdnaj+O9Zv/Bq6MCy9r >> qNopxk5DYOaljxcsiPuDHDNj1jvxbOmkSVSbaoZJ5VFlm4qLhZSOjvMJnYGvzBR8 >> e/qX00EQAncyXSU4Iq59D9BK43iyYqvY/8Bvr1f7PSbNluEHM4zl6jHUoJR0WtDd >> 8hlpWpjxz+tWtW9XhZm6EzzCwlnwrhdfTUr6sTA+f9pXJF2ypLf8SMJavi+Of2zi >> MXzCrgO+GJzvIkcqxfjpzyQuoDNesN8fI9KrLk0Q1PYTv7MXZQquwVLbwx+79zc= >> =LVL7 >> -----END PGP SIGNATURE----- --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From koszik at atw.hu Thu Apr 23 15:57:33 2015 From: koszik at atw.hu (Matyas Koszik) Date: Thu, 23 Apr 2015 15:57:33 +0200 (CEST) Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538F872.90900@opteamax.de> Message-ID: On Thu, 23 Apr 2015, Opteamax GmbH wrote: > On 23.04.2015 15:39, Vladimir Andreev wrote: > > > > If we suppose having multiple /22 per LIR is abusing then main > > "abuser" is RIPE NCC since RIPE NCC makes transfers and LIR merging > > allowing to receive second /22 etc. > > > > So you agree my initial reply that actually the change does not go far > enough, it'd be better to completely prohibited selling IP (v4) and > instead enforce withdrawing of not announced IP-Space aand returning > it into the pool? > > That way I am pretty sure we could quickly loosen the current /8 > policy and return to a policy allowing requests of more then one /22 > if need is shown .... and need may NOT be selling, but that'd be > forbidden anyway then ;) Announcing globally was never a requirement to receive IP addresses from RIPE, and changing policy retroactively is not a nice thing to do. And you wouldn't deter this kind of 'abuse' at all, if you're in the internet business I'm sure you know how easy it is to set up an announcement for a prefix. Matyas From alexlh at funk.org Thu Apr 23 16:18:54 2015 From: alexlh at funk.org (Alex Le Heux) Date: Thu, 23 Apr 2015 16:18:54 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <4065141429796389@web27g.yandex.ru> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> Message-ID: <6F626DDB-418F-4664-B6E5-90314C3906A5@funk.org> This thread is just... wow... Maybe we should review what the Last /8 Policy is all about... > On Apr 23, 2015, at 15:39 , Vladimir Andreev wrote: > >> Because the policy says "one /22 per LIR". > > Policy sets this rule only for /22's received from RIPE NCC. > > Indeed, RIPE NCC will not allocate you several /22. I have tested it :) > > The only way is to receive allocations from other LIR (own or belonging to other companies). An such order doesn't abuse any policies. > > If we suppose having multiple /22 per LIR is abusing then main "abuser" is RIPE NCC since RIPE NCC makes transfers and LIR merging allowing to receive second /22 etc. Actually, this very much is abuse. The Last /8 Policy is intended to provide for two things: 1. A single small block of IPs (/22) for new organisations who join the internet. 2. A single small block of IPs (/22) for existing organisations who didn't plan for the end of IPv4 very well so they could deploy some kind of 6-to-4-whatever in that /22. Because businesses merge and do take-overs and that kind of thing in the normal course of existing, transfers related to mergers and acquisitions have to be possible. Anything else than the above is abuse of the Last /8 Policy and no amount of semantic masturbation is going to change that. If a business needs to abuse this policy to survive, it has no right to exist. And if you really do need more addresses to survive, IPv4 is over guys, deal with it. As always, time will tell if this proposal will stop this kind of abuse, but it's a step in the right direction. Alex Le Heux Rakuten Inc > 23.04.2015, 16:35, "Gert Doering" : >> Hi, >> >> On Thu, Apr 23, 2015 at 04:22:51PM +0300, Vladimir Andreev wrote: >>> What from this quotation is? Please give me a link. >>> And what statement exactly of the current policy is abusing? >> >> Stop turning in circles. This question has been answered before. >>> Also I would like to receive concrete answer to the question: >>> Why using multiple /22's for own company is not abusing but selling is abusing? >> >> Because the policy says "one /22 per 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 > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 > From vladimir at quick-soft.net Thu Apr 23 16:24:12 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 17:24:12 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <5538F872.90900@opteamax.de> Message-ID: <4132851429799052@web22j.yandex.ru> I am just speaking about how easy requirement about making assignments can be passed. 23.04.2015, 17:19, "Matyas Koszik" : > On Thu, 23 Apr 2015, Opteamax GmbH wrote: >> ?On 23.04.2015 15:39, Vladimir Andreev wrote: >>> ?If we suppose having multiple /22 per LIR is abusing then main >>> ?"abuser" is RIPE NCC since RIPE NCC makes transfers and LIR merging >>> ?allowing to receive second /22 etc. >> ?So you agree my initial reply that actually the change does not go far >> ?enough, it'd be better to completely prohibited selling IP (v4) and >> ?instead enforce withdrawing of not announced IP-Space aand returning >> ?it into the pool? >> >> ?That way I am pretty sure we could quickly loosen the current /8 >> ?policy and return to a policy allowing requests of more then one /22 >> ?if need is shown .... and need may NOT be selling, but that'd be >> ?forbidden anyway then ;) > > Announcing globally was never a requirement to receive IP addresses from > RIPE, and changing policy retroactively is not a nice thing to do. And you > wouldn't deter this kind of 'abuse' at all, if you're in the internet > business I'm sure you know how easy it is to set up an announcement for a > prefix. > > Matyas --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ripe-wgs at radu-adrian.feurdean.net Thu Apr 23 16:33:29 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 23 Apr 2015 16:33:29 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5538F7C5.5060005@opteamax.de> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> Message-ID: <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> On Thu, Apr 23, 2015, at 15:46, Jens Ott - Opteamax GmbH wrote: > So you agree my initial reply that actually the change does not go far > enough, it'd be better to completely prohibited selling IP (v4) and > instead enforce withdrawing of not announced IP-Space aand returning > it into the pool? > > That way I am pretty sure we could quickly loosen the current /8 > policy and return to a policy allowing requests of more then one /22 > if need is shown .... and need may NOT be selling, but that'd be > forbidden anyway then ;) While some people agree with the concept, I'm not sure that the community in its whole (or majority) will agree with rolling-back several years of (already-established) policies. This definitely needs more discussion (maybe during a meeting): - restore needs-based allocation (which has been "abolished" in order to legitimate already widespread but not really appreciated practice- lying about "needs" and "use") - soften the "last /8" policy - between 2010 and now the situation changed, and things will change even more in the upcoming years. Not to mention that now we have some real-life experience. From aleksbulgakov at gmail.com Thu Apr 23 16:29:11 2015 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Thu, 23 Apr 2015 17:29:11 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <4132851429799052@web22j.yandex.ru> References: <5538F872.90900@opteamax.de> <4132851429799052@web22j.yandex.ru> Message-ID: Vladimir, +1 23 ??? 2015 ?. 17:24 ???????????? "Vladimir Andreev" < vladimir at quick-soft.net> ???????: > I am just speaking about how easy requirement about making assignments can > be passed. > > 23.04.2015, 17:19, "Matyas Koszik" : > > On Thu, 23 Apr 2015, Opteamax GmbH wrote: > >> On 23.04.2015 15:39, Vladimir Andreev wrote: > >>> If we suppose having multiple /22 per LIR is abusing then main > >>> "abuser" is RIPE NCC since RIPE NCC makes transfers and LIR merging > >>> allowing to receive second /22 etc. > >> So you agree my initial reply that actually the change does not go far > >> enough, it'd be better to completely prohibited selling IP (v4) and > >> instead enforce withdrawing of not announced IP-Space aand returning > >> it into the pool? > >> > >> That way I am pretty sure we could quickly loosen the current /8 > >> policy and return to a policy allowing requests of more then one /22 > >> if need is shown .... and need may NOT be selling, but that'd be > >> forbidden anyway then ;) > > > > Announcing globally was never a requirement to receive IP addresses from > > RIPE, and changing policy retroactively is not a nice thing to do. And > you > > wouldn't deter this kind of 'abuse' at all, if you're in the internet > > business I'm sure you know how easy it is to set up an announcement for a > > prefix. > > > > Matyas > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at opteamax.de Thu Apr 23 16:35:46 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 23 Apr 2015 16:35:46 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <4082911429798424@web22j.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538EADC.2070008@opteamax.de> <4082911429798424@web22j.yandex.ru> Message-ID: <55390342.7060501@opteamax.de> On 23.04.2015 16:13, Vladimir Andreev wrote: > OK. I explain this one more time :) > > Just after receiving /22 you should create 2 x "inetnum" (each /23) with type ASSIGNED PA. Formally you are right since you have made assignments. Which is not the intention. but I agree, obviously we need to clarify what an assignment is. Please refer to chapter 6 of ripe-643. ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. So "making an assignment" does *not* mean create a /23 inetnum in RIPE-DB. If this is your understanding of what an LIR does ... no further comment. BR Jens > > Furthermore you can create "route" object and announce your /22. In such case nobody can say "you don't use you allocation" or "you didn't make assignments". > > 23.04.2015, 17:08, "Jens Ott - Opteamax GmbH" : >> On 23.04.2015 14:45, Vladimir Andreev wrote: >>>> The LIR must confirm it will make assignment(s) from the >>>> allocation. >>> Please point me where in quoted text you see any prohibition to >>> open and merge LIRs with /22's? >> >> Buying and merging is not prohibited, _but_ opening LIR, requesting >> /22 and selling /22 and closing LIR ist probibited, as the LIR did not >> fullfil his confirmed will to make assignments!! >> >> BR >> Jens >>> 23.04.2015, 15:43, "Gert Doering" : >>>> Hi, >>>> >>>> On Thu, Apr 23, 2015 at 03:41:10PM +0300, Vladimir Andreev >>>> wrote: >>>>> And why receiving /22's for own company is "legitimate" and for >>>>> selling is not? >>>> *one* /22 per LIR is the last-/8 policy >>>> >>>> not "open lots of LIRs, so a single LIR can have multiple /22s in >>>> the end, and circumvent the one-LIR-one-/22-allocated policy". >>>> >>>> Gert Doering -- APWG chair -- have you enabled IPv6 on something >>>> today...? >>>> >>>> SpaceNet AG Vorstand: Sebastian v. >>>> Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >>>> Grundner-Culemann D-80807 Muenchen HRB: 136055 >>>> (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: >>>> DE813185279 >>> -- With best regards, Vladimir Andreev General director, QuickSoft >>> LLC Tel: +7 903 1750503 >>> >>> >> >> - -- >> Jens Ott >> - - Gesch?ftsf?hrer - >> >> Opteamax GmbH >> >> Simrockstr. 4b >> 53619 Rheinbreitbach >> >> Tel.: +49 2224 969500 >> Fax: +49 2224 97691059 >> Email: jo at opteamax.de >> >> HRB: 23144, Amtsgericht Montabaur >> Gesch?ftsf?hrer: Jens Ott >> Umsatzsteuer-ID.: DE264133989 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2 >>> >>> iQEcBAEBCAAGBQJVOOrXAAoJECrmRJLVnvx6HRcIAK+EIe7EU2OCDjNC1f5v1JKd >>> xEIBbGiQN7k1TeQI2lPbW1WLZHGxHrFp9PCTHnT+T9uihIdnaj+O9Zv/Bq6MCy9r >>> qNopxk5DYOaljxcsiPuDHDNj1jvxbOmkSVSbaoZJ5VFlm4qLhZSOjvMJnYGvzBR8 >>> e/qX00EQAncyXSU4Iq59D9BK43iyYqvY/8Bvr1f7PSbNluEHM4zl6jHUoJR0WtDd >>> 8hlpWpjxz+tWtW9XhZm6EzzCwlnwrhdfTUr6sTA+f9pXJF2ypLf8SMJavi+Of2zi >>> MXzCrgO+GJzvIkcqxfjpzyQuoDNesN8fI9KrLk0Q1PYTv7MXZQquwVLbwx+79zc= >>> =LVL7 >>> -----END PGP SIGNATURE----- > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 > > > !DSPAM:637,553900f431041558355978! > -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From ripe at opteamax.de Thu Apr 23 16:37:53 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 23 Apr 2015 16:37:53 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> Message-ID: <553903C1.8000201@opteamax.de> On 23.04.2015 16:33, Radu-Adrian FEURDEAN wrote: > - soften the "last /8" policy - between 2010 and now the situation > changed, and things will change even more in the upcoming years. Not to > mention that now we have some real-life experience. Don't get me wrong, I don't want to soften the "last /8" policy ... as Alex already mentioned. A business which needs IPv4 to survive does something wrong ... BR Jens -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From ripe-wgs at radu-adrian.feurdean.net Thu Apr 23 16:41:05 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 23 Apr 2015 16:41:05 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <55390342.7060501@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538EADC.2070008@opteamax.de> <4082911429798424@web22j.yandex.ru> <55390342.7060501@opteamax.de> Message-ID: <1429800065.1200025.257662061.4A8D44A4@webmail.messagingengine.com> On Thu, Apr 23, 2015, at 16:35, Opteamax GmbH wrote: > So "making an assignment" does *not* mean create a /23 inetnum in RIPE-DB. No, but creating an inetnum is pretty much the only way to verify that an assignment has been made (even it it is not true). Point is : we want to prevent abuse, but there seems to be no real way to do it in real-life. From poty at iiat.ru Thu Apr 23 16:44:35 2015 From: poty at iiat.ru (poty at iiat.ru) Date: Thu, 23 Apr 2015 14:44:35 +0000 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <673847425.20150423160254@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538ECA2.2020304@opteamax.de> <673847425.20150423160254@infinitytelecom.ro> Message-ID: <38A326B32984534586F211FB04239BF842D809C6@Win2008R2.office.iiat> IF you don't have money it does not mean you are allowed to steal them. You MAY cheat a policy, but you must not prevent the community to guard the spirit of it by eliminating the ways of cheating. I'm clearly FOR the proposal! Regards, Vladislav Potapov From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Infinity Telecom SRL Sent: Thursday, April 23, 2015 4:03 PM To: Opteamax GmbH; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Transfer Requirements for IPv4 Allocations Hello Opteamax, And if i dont sell the IPv4 ? And its just for my company its prohibited ? Its prohibited because i dont have enough money to buy from sellers ? Thank you. -- Cu stima, Gabriel Voitis | Sales Manager voitis at infinitytelecom.ro INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 contact at infinitytelecom.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at quick-soft.net Thu Apr 23 16:45:00 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 17:45:00 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <55390342.7060501@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538EADC.2070008@opteamax.de> <4082911429798424@web22j.yandex.ru> <55390342.7060501@opteamax.de> Message-ID: <4216351429800300@web22j.yandex.ru> I 'm explaining you from RIPE NCC point of view. > If this is your understanding of what an LIR does ... no > further comment. Please be more polite. 23.04.2015, 17:35, "Opteamax GmbH" : > On 23.04.2015 16:13, Vladimir Andreev wrote: >> ?OK. I explain this one more time :) >> >> ?Just after receiving /22 you should create 2 x "inetnum" (each /23) with type ASSIGNED PA. Formally you are right since you have made assignments. > > Which is not the intention. but I agree, obviously we need to clarify > what an assignment is. Please refer to chapter 6 of ripe-643. > > ASSIGNED PA: This address space has been assigned to an End User for use > with services provided by the issuing LIR. It cannot be kept when > terminating services provided by the LIR. > > So "making an assignment" does *not* mean create a /23 inetnum in > RIPE-DB. If this is your understanding of what an LIR does ... no > further comment. > > BR Jens >> ?Furthermore you can create "route" object and announce your /22. In such case nobody can say "you don't use you allocation" or "you didn't make assignments". >> >> ?23.04.2015, 17:08, "Jens Ott - Opteamax GmbH" : >>> ?On 23.04.2015 14:45, Vladimir Andreev wrote: >>>>> ??The LIR must confirm it will make assignment(s) from the >>>>> ??allocation. >>>> ??Please point me where in quoted text you see any prohibition to >>>> ??open and merge LIRs with /22's? >>> ?Buying and merging is not prohibited, _but_ opening LIR, requesting >>> ?/22 and selling /22 and closing LIR ist probibited, as the LIR did not >>> ?fullfil his confirmed will to make assignments!! >>> >>> ?BR >>> ?Jens >>>> ??23.04.2015, 15:43, "Gert Doering" : >>>>> ??Hi, >>>>> >>>>> ??On Thu, Apr 23, 2015 at 03:41:10PM +0300, Vladimir Andreev >>>>> ??wrote: >>>>>> ??And why receiving /22's for own company is "legitimate" and for >>>>>> ??selling is not? >>>>> ??*one* /22 per LIR is the last-/8 policy >>>>> >>>>> ??not "open lots of LIRs, so a single LIR can have multiple /22s in >>>>> ??the end, and circumvent the one-LIR-one-/22-allocated policy". >>>>> >>>>> ??Gert Doering -- APWG chair -- have you enabled IPv6 on something >>>>> ??today...? >>>>> >>>>> ??SpaceNet AG ???????????????????????Vorstand: Sebastian v. >>>>> ??Bomhard Joseph-Dollinger-Bogen 14 ?????????Aufsichtsratsvors.: A. >>>>> ??Grundner-Culemann D-80807 Muenchen ??????????????????HRB: 136055 >>>>> ??(AG Muenchen) Tel: +49 (0)89/32356-444 ??????????USt-IdNr.: >>>>> ??DE813185279 >>>> ??-- With best regards, Vladimir Andreev General director, QuickSoft >>>> ??LLC Tel: +7 903 1750503 >>> ?- -- >>> ?Jens Ott >>> ?- - Gesch?ftsf?hrer - >>> >>> ?Opteamax GmbH >>> >>> ?Simrockstr. 4b >>> ?53619 Rheinbreitbach >>> >>> ?Tel.: ?+49 2224 969500 >>> ?Fax: ??+49 2224 97691059 >>> ?Email: jo at opteamax.de >>> >>> ?HRB: 23144, Amtsgericht Montabaur >>> ?Gesch?ftsf?hrer: Jens Ott >>> ?Umsatzsteuer-ID.: DE264133989 >>>> ?-----BEGIN PGP SIGNATURE----- >>>> ?Version: GnuPG v2 >>>> >>>> ?iQEcBAEBCAAGBQJVOOrXAAoJECrmRJLVnvx6HRcIAK+EIe7EU2OCDjNC1f5v1JKd >>>> ?xEIBbGiQN7k1TeQI2lPbW1WLZHGxHrFp9PCTHnT+T9uihIdnaj+O9Zv/Bq6MCy9r >>>> ?qNopxk5DYOaljxcsiPuDHDNj1jvxbOmkSVSbaoZJ5VFlm4qLhZSOjvMJnYGvzBR8 >>>> ?e/qX00EQAncyXSU4Iq59D9BK43iyYqvY/8Bvr1f7PSbNluEHM4zl6jHUoJR0WtDd >>>> ?8hlpWpjxz+tWtW9XhZm6EzzCwlnwrhdfTUr6sTA+f9pXJF2ypLf8SMJavi+Of2zi >>>> ?MXzCrgO+GJzvIkcqxfjpzyQuoDNesN8fI9KrLk0Q1PYTv7MXZQquwVLbwx+79zc= >>>> ?=LVL7 >>>> ?-----END PGP SIGNATURE----- >> ?-- >> ?With best regards, Vladimir Andreev >> ?General director, QuickSoft LLC >> ?Tel: +7 903 1750503 >> >> ?!DSPAM:637,553900f431041558355978! > > -- > Opteamax GmbH - RIPE-Team > Jens Ott > > Opteamax GmbH > > Simrockstr. 4b > 53619 Rheinbreitbach > > Tel.: ?+49 2224 969500 > Fax: ??+49 2224 97691059 > Email: jo at opteamax.de > > HRB: 23144, Amtsgericht Montabaur > Umsatzsteuer-ID.: DE264133989 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ripe-ml-2015 at ssd.axu.tm Thu Apr 23 16:43:00 2015 From: ripe-ml-2015 at ssd.axu.tm (Aleksi Suhonen) Date: Thu, 23 Apr 2015 17:43:00 +0300 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <553904F4.7090706@ssd.axu.tm> Hello, On 04/14/2015 03:52 PM, Marco Schmidt wrote: > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. James Kennedy! You are my hero! I support the spirit of the proposal, but I haven't read the text yet. -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail From ripe-wgs at radu-adrian.feurdean.net Thu Apr 23 17:04:54 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 23 Apr 2015 17:04:54 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <553903C1.8000201@opteamax.de> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> <553903C1.8000201@opteamax.de> Message-ID: <1429801494.1207756.257665669.28E2FD4C@webmail.messagingengine.com> On Thu, Apr 23, 2015, at 16:37, Opteamax GmbH wrote: > Don't get me wrong, I don't want to soften the "last /8" policy ... as > Alex already mentioned. A business which needs IPv4 to survive does > something wrong ... Today, 23/04/2015, a business *DOES* need IPv4 to survive. IPv6 is still seen as a "geek thing", and a lot of things are still badly implemented (if implemented at all) over IPv6. The policy, the way it is, just keps the agony going on for a very long time, at least in RIPE-land. From ip at infinitytelecom.ro Thu Apr 23 17:08:47 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Thu, 23 Apr 2015 18:08:47 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <38A326B32984534586F211FB04239BF842D809C6@Win2008R2.office.iiat> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538ECA2.2020304@opteamax.de> <673847425.20150423160254@infinitytelecom.ro> <38A326B32984534586F211FB04239BF842D809C6@Win2008R2.office.iiat> Message-ID: <1422494941.20150423180847@infinitytelecom.ro> Hello Poty, There is no more room to cheat.. stay calm. The sellers are too angry because little companies can get /22 And sellers are greedy.. they want more and more. Someone should think to help the little companies.. not to point to the sellers.. "deal with it" Like, if a company have multiple connections.. multiple presents in IX around the globe.. can get a little extra.. i just say.. -- Cu stima, Gabriel Voitis | Sales Manager voitis at infinitytelecom.ro INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 contact at infinitytelecom.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.baeza at tvt-datos.es Thu Apr 23 17:16:42 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Thu, 23 Apr 2015 17:16:42 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423114348.GT54385@Space.Net> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> Message-ID: <55390CDA.2000303@tvt-datos.es> Hi, El 23/04/2015 a las 13:43, Gert Doering escribi?: > ... and the community is free to declare that "Make another LIR and move > resources to old LIR (right away)" is considered abuse of the last /8 > policy, and dis-incentivize it... Sure we are. But I always have seen a problem with this kind of proposals and the community. The problem is that lot of members of the community are IP Trader/Broker/Sellers so, a policy such this one are VERY GOOD for them while is VERY BAD for the new lirs that only hold a /22. The community should be objetive, and Im pretty sure it isnt. Why Elvis, a well know IP Broker from V4Escrow, proposed this instead of "Unused space should be returned to RIPE"??? Did the community think about if all the offers in the Listing Service are reclaimed from RIPE, the IPv4 Exhaustion "dissapear"? Why nobody in the community proposed it? Regards, -- 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 tom at kebab.org.pl Thu Apr 23 17:20:24 2015 From: tom at kebab.org.pl (-TOM-) Date: Thu, 23 Apr 2015 17:20:24 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <55390342.7060501@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538EADC.2070008@opteamax.de> <4082911429798424@web22j.yandex.ru> <55390342.7060501@opteamax.de> Message-ID: <55390DB8.1040108@kebab.org.pl> W dniu 2015-04-23 o 16:35, Opteamax GmbH pisze: > On 23.04.2015 16:13, Vladimir Andreev wrote: >> OK. I explain this one more time :) >> >> Just after receiving /22 you should create 2 x "inetnum" (each /23) with type ASSIGNED PA. Formally you are right since you have made assignments. > Which is not the intention. but I agree, obviously we need to clarify > what an assignment is. Please refer to chapter 6 of ripe-643. > > ASSIGNED PA: This address space has been assigned to an End User for use > with services provided by the issuing LIR. It cannot be kept when > terminating services provided by the LIR. > > So "making an assignment" does *not* mean create a /23 inetnum in > RIPE-DB. You can create 2x /23 or 4 x/24, describe them as John Smith or ACME INC., put them on a VPS or even ordinary switch connected to the Internet, announce the space, make it pingable and after 1 or 2 months dismount all this mess and sell it. In such case *all* currently requirements of "assignment" are fulfilled. Many years ago (before Sept 2012) lot of LIR's made such masquerades to present "depletion" of their allocations and asked for so much new space, as they can obtain from RIPE, and stockpiled them. > If this is your understanding of what an LIR does ... no > further comment. Over described situation is not significantly different from real user assignment. How to distinguish them? Send auditors? Best regards Tomasz ?l?ski From ripe at opteamax.de Thu Apr 23 17:20:50 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 23 Apr 2015 17:20:50 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1429801494.1207756.257665669.28E2FD4C@webmail.messagingengine.com> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> <553903C1.8000201@opteamax.de> <1429801494.1207756.257665669.28E2FD4C@webmail.messagingengine.com> Message-ID: <55390DD2.4000104@opteamax.de> On 23.04.2015 17:04, Radu-Adrian FEURDEAN wrote: > On Thu, Apr 23, 2015, at 16:37, Opteamax GmbH wrote: >> Don't get me wrong, I don't want to soften the "last /8" policy ... as >> Alex already mentioned. A business which needs IPv4 to survive does >> something wrong ... > > Today, 23/04/2015, a business *DOES* need IPv4 to survive. IPv6 is still > seen as a "geek thing", and a lot of things are still badly implemented > (if implemented at all) over IPv6. > The policy, the way it is, just keps the agony going on for a very long > time, at least in RIPE-land. Yes, you need IPv4, but you'd don't need *more* IPv4. At least not more as you can legally receive from RIPE without cheating. Techniques like 6to4, CGN etc. exist ... for a business to survive, it actually is enough to rollout these things... But I agree - and see it almost daily with my customers - in a lot of heads rolling out V6 and using the mentioned things ends in: "we fear to rollout V6, it is working with V4 so we don't want to spend time to test if V6 is working properly" ... and then, one day and as unforseeable as Christmas coming end of December, they discover they'd need more V4 to grow but can't get and suddenly they need to hurry, they make mistakes in implementing as they are in hurry and they shout out "you see, IPv6 integration is bullshit" only because they forgot some config-changes. BR Jens -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From ip at infinitytelecom.ro Thu Apr 23 17:21:08 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Thu, 23 Apr 2015 18:21:08 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <55390CDA.2000303@tvt-datos.es> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> Message-ID: <1351581137.20150423182108@infinitytelecom.ro> Hello Daniel, Finally, someone said the word ! " Why Elvis, a well know IP Broker from V4Escrow, proposed this instead of "Unused space should be returned to RIPE"??? " Thank you ! -- Best regards, Gabriel Voitis -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at quick-soft.net Thu Apr 23 17:23:56 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 18:23:56 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <55390CDA.2000303@tvt-datos.es> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> Message-ID: <4358421429802636@web22j.yandex.ru> +1000 23.04.2015, 18:17, "Daniel Baeza (Red y Sistemas TVT)" : > Hi, > > El 23/04/2015 a las 13:43, Gert Doering escribi?: >> ?... and the community is free to declare that "Make another LIR and move >> ?resources to old LIR (right away)" is considered abuse of the last /8 >> ?policy, and dis-incentivize it... > > Sure we are. But I always have seen a problem with this kind of > proposals and the community. > The problem is that lot of members of the community are IP > Trader/Broker/Sellers so, a policy such this one are VERY GOOD for them > while is VERY BAD for the new lirs that only hold a /22. > The community should be objetive, and Im pretty sure it isnt. > > Why Elvis, a well know IP Broker from V4Escrow, proposed this instead of > "Unused space should be returned to RIPE"??? > > Did the community think about if all the offers in the Listing Service > are reclaimed from RIPE, the IPv4 Exhaustion "dissapear"? > > Why nobody in the community proposed it? > > Regards, > > -- > 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. --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ak at list.ak.cx Thu Apr 23 17:27:52 2015 From: ak at list.ak.cx (Andre Keller) Date: Thu, 23 Apr 2015 17:27:52 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <55390CDA.2000303@tvt-datos.es> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> Message-ID: <55390F78.9060606@list.ak.cx> Hi, On 23.04.2015 17:16, Daniel Baeza (Red y Sistemas TVT) wrote: > The community should be objetive, and Im pretty sure it isnt. I'm not so sure about that. But maybe it would be better to promote RIPE PDP at your local user groups (xNOG), so that more people get involved in the process. If you just look at the member count of RIPE (and no, you do not have to be a member to participate in the PDP) and the members involved in the address policy working group there is a huge gap. So either people do not care at all, or they can live with the policies that other members of the community come up with. And IP Brokers ARE part of the community if you like it or not. > > Why Elvis, a well know IP Broker from V4Escrow, proposed this instead > of "Unused space should be returned to RIPE"??? > Well I can only speak for myself. For me it is important that the RIPE database is as accurate as possible. I'm pretty sure "Unused space should be returned to RIPE" is just not gonna happen, even if this ends up in a policy. When we allow transfers, we have a better chance that the records are kept up to date. Regards Andr? From vladimir at quick-soft.net Thu Apr 23 17:31:05 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 18:31:05 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <4358421429802636@web22j.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> <4358421429802636@web22j.yandex.ru> Message-ID: <4380181429803065@web22j.yandex.ru> I tried to speak that current proposal aimed to satisfy somebody's interests (maybe brokers'). It's not legal to introduce such proposals. Does Elvis think that some time ago I (or other member) will offer another propose which forbid some other things which is important for brokers? It's better to respect interests of each other and don't do bad things (such this proposal)! 23.04.2015, 18:23, "Vladimir Andreev" : > +1000 > > 23.04.2015, 18:17, "Daniel Baeza (Red y Sistemas TVT)" : >> ?Hi, >> >> ?El 23/04/2015 a las 13:43, Gert Doering escribi?: >>> ??... and the community is free to declare that "Make another LIR and move >>> ??resources to old LIR (right away)" is considered abuse of the last /8 >>> ??policy, and dis-incentivize it... >> ?Sure we are. But I always have seen a problem with this kind of >> ?proposals and the community. >> ?The problem is that lot of members of the community are IP >> ?Trader/Broker/Sellers so, a policy such this one are VERY GOOD for them >> ?while is VERY BAD for the new lirs that only hold a /22. >> ?The community should be objetive, and Im pretty sure it isnt. >> >> ?Why Elvis, a well know IP Broker from V4Escrow, proposed this instead of >> ?"Unused space should be returned to RIPE"??? >> >> ?Did the community think about if all the offers in the Listing Service >> ?are reclaimed from RIPE, the IPv4 Exhaustion "dissapear"? >> >> ?Why nobody in the community proposed it? >> >> ?Regards, >> >> ?-- >> ?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. > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From aleksbulgakov at gmail.com Thu Apr 23 17:31:13 2015 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Thu, 23 Apr 2015 18:31:13 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1351581137.20150423182108@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> <1351581137.20150423182108@infinitytelecom.ro> Message-ID: Bingo!! 2015-04-23 18:21 GMT+03:00 Infinity Telecom SRL : > Hello Daniel, > > > > Finally, someone said the word ! > > " Why Elvis, a well know IP Broker from V4Escrow, proposed this instead of > "Unused space should be returned to RIPE"??? " > > > Thank you ! > > -- > Best regards, > Gabriel Voitis -- ---------- Best regards, Aleksey Bulgakov Tel.: +7 (926)690-87-29 From sergey at devnull.ru Thu Apr 23 17:33:07 2015 From: sergey at devnull.ru (Sergey Myasoedov) Date: Thu, 23 Apr 2015 17:33:07 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <4380181429803065@web22j.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> <4358421429802636@web22j.yandex.ru> <4380181429803065@web22j.yandex.ru> Message-ID: <76004999.20150423173307@devnull.ru> Hi Vladimir, all, Thursday, April 23, 2015, 5:31:05 PM, you wrote: VA> It's not legal to introduce such proposals. Why do you think so? -- Sergey From vladimir at quick-soft.net Thu Apr 23 17:33:58 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 18:33:58 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <76004999.20150423173307@devnull.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> <4358421429802636@web22j.yandex.ru> <4380181429803065@web22j.yandex.ru> <76004999.20150423173307@devnull.ru> Message-ID: <4388751429803238@web22j.yandex.ru> Not that word. Not "legal" but "disreputably". 23.04.2015, 18:32, "Sergey Myasoedov" : > Hi Vladimir, all, > > Thursday, April 23, 2015, 5:31:05 PM, you wrote: > VA> It's not legal to introduce such proposals. > > Why do you think so? > > -- > Sergey --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From koszik at atw.hu Thu Apr 23 17:37:40 2015 From: koszik at atw.hu (Matyas Koszik) Date: Thu, 23 Apr 2015 17:37:40 +0200 (CEST) Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <4358421429802636@web22j.yandex.ru> Message-ID: -1000 If there's incentive to lie about the usage of the addresses then people will just lie. Same as how some LIRs got their (still unused) large swaths of netblocks in the first place. Please try to be a bit more realistic. Matyas On Thu, 23 Apr 2015, Vladimir Andreev wrote: > +1000 > > 23.04.2015, 18:17, "Daniel Baeza (Red y Sistemas TVT)" : > > Hi, > > > > El 23/04/2015 a las 13:43, Gert Doering escribi??: > >> ??... and the community is free to declare that "Make another LIR and move > >> ??resources to old LIR (right away)" is considered abuse of the last /8 > >> ??policy, and dis-incentivize it... > > > > Sure we are. But I always have seen a problem with this kind of > > proposals and the community. > > The problem is that lot of members of the community are IP > > Trader/Broker/Sellers so, a policy such this one are VERY GOOD for them > > while is VERY BAD for the new lirs that only hold a /22. > > The community should be objetive, and Im pretty sure it isnt. > > > > Why Elvis, a well know IP Broker from V4Escrow, proposed this instead of > > "Unused space should be returned to RIPE"??? > > > > Did the community think about if all the offers in the Listing Service > > are reclaimed from RIPE, the IPv4 Exhaustion "dissapear"? > > > > Why nobody in the community proposed it? > > > > Regards, > > > > -- > > 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. > > --?? > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 > > From ebais at a2b-internet.com Thu Apr 23 17:38:14 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 23 Apr 2015 17:38:14 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: <553904F4.7090706@ssd.axu.tm> References: <553904F4.7090706@ssd.axu.tm> Message-ID: <028e01d07ddb$8b2ee300$a18ca900$@a2b-internet.com> This made me smile while reading all the other emails on the AP-WG list today :) >On 04/14/2015 03:52 PM, Marco Schmidt wrote: >> A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > >is now available for discussion. >James Kennedy! You are my hero! >I support the spirit of the proposal, but I haven't read the text yet. Especially that last bit :) Regards, Erik Bais From ripe at opteamax.de Thu Apr 23 17:39:06 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Thu, 23 Apr 2015 17:39:06 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <55390DB8.1040108@kebab.org.pl> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538EADC.2070008@opteamax.de> <4082911429798424@web22j.yandex.ru> <55390342.7060501@opteamax.de> <55390DB8.1040108@kebab.org.pl> Message-ID: <5539121A.60902@opteamax.de> On 23.04.2015 17:20, -TOM- wrote: > > Over described situation is not significantly different from real user > assignment. How to distinguish them? Send auditors? > So if I get you right only because it is impossible to check, it is ok to cheat? And only because others do it, it's ok to do it? So porting this arguement into "real-live" would come to the conclusion: "it's fully ok to remove your license-plate, wear some mask over your face, fill your car at the gas-station and drive away without paying, because it can not be validated who it was?" So even that it is possible, it is still IMHO not ok ... wondering if it's today understood as acceptable and ok to cheat and find as many backdoors as possible to have a personal advantage, no matter that the rules and policy says differently, only because it's hard to validate ... BR Jens From ip at infinitytelecom.ro Thu Apr 23 17:41:45 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Thu, 23 Apr 2015 18:41:45 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <4358421429802636@web22j.yandex.ru> Message-ID: <924507895.20150423184145@infinitytelecom.ro> Hello Matyas, "Same as how some LIRs got their (still unused) large swaths of netblocks in the first place." Yes, they are at the base of today IP marketplace, the list of transfer its full with them.. -- Best regards, Gabriel Voitis -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Thu Apr 23 17:53:21 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 23 Apr 2015 17:53:21 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <55390DD2.4000104@opteamax.de> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> <553903C1.8000201@opteamax.de> <1429801494.1207756.257665669.28E2FD4C@webmail.messagingengine.com> <55390DD2.4000104@opteamax.de> Message-ID: <1429804401.1220848.257687561.403F9753@webmail.messagingengine.com> On Thu, Apr 23, 2015, at 17:20, Opteamax GmbH wrote: > Yes, you need IPv4, but you'd don't need *more* IPv4. At least not more > as you can legally receive from RIPE without cheating. Yes, you do. From the last 4 companies I worked for, 2 of them wouldn't be in business anymore if they were limited to a /22. The 4th one is still too new to suffer. The 3rd was the only one OK with that. Most impacted are the "server hosting" providers. > Techniques like 6to4, CGN etc. exist ... for a business to survive, it > actually is enough to rollout these things... Nice competitive disadvantage. I will have my own answers and field experience on the subject in less than 1 year. Do you ? > if V6 is working properly" ... and then, one day and as unforseeable as > Christmas coming end of December, they discover they'd need more V4 to Some of them don't. For the moment NAT seems to be more easier to deal with then switching to IPv6. 192.168.1.100 is still easier to understand than fe80::224:9bff:fe0d:beef (and the 9 other GUAs I have on my computer right now). This is valid for the CxOs and for the guys that write software, not the ones that run a network. From tom at kebab.org.pl Thu Apr 23 17:55:41 2015 From: tom at kebab.org.pl (-TOM-) Date: Thu, 23 Apr 2015 17:55:41 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <5539121A.60902@opteamax.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <3484611429790874@web27g.yandex.ru> <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <5538EADC.2070008@opteamax.de> <4082911429798424@web22j.yandex.ru> <55390342.7060501@opteamax.de> <55390DB8.1040108@kebab.org.pl> <5539121A.60902@opteamax.de> Message-ID: <553915FD.2080903@kebab.org.pl> W dniu 2015-04-23 o 17:39, Opteamax GmbH pisze: > On 23.04.2015 17:20, -TOM- wrote: >> Over described situation is not significantly different from real user >> assignment. How to distinguish them? Send auditors? >> > So if I get you right only because it is impossible to check, it is ok > to cheat? And only because others do it, it's ok to do it? Of course I do not support such behavior, but the facts are, that the people always find a backdoor. Especially if there is money behind it... Best regards Tomasz ?l?ski From ripe-ml-2015 at ssd.axu.tm Thu Apr 23 17:56:31 2015 From: ripe-ml-2015 at ssd.axu.tm (Aleksi Suhonen) Date: Thu, 23 Apr 2015 18:56:31 +0300 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: <028e01d07ddb$8b2ee300$a18ca900$@a2b-internet.com> References: <553904F4.7090706@ssd.axu.tm> <028e01d07ddb$8b2ee300$a18ca900$@a2b-internet.com> Message-ID: <5539162F.4030407@ssd.axu.tm> Hello, On 04/23/2015 06:38 PM, Erik Bais wrote: > This made me smile while reading all the other emails on the AP-WG list > today :) >> I support the spirit of the proposal, but I haven't read the text yet. > > Especially that last bit :) Well I had 92 other messages on the list to wade through before I got around to reading the text. I now support the text too. :-) -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail From mueller at syr.edu Thu Apr 23 17:32:24 2015 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 23 Apr 2015 15:32:24 +0000 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <015101d07dbc$7d127670$77376350$@a2b-internet.com> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> Message-ID: <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> Erik: Have you responded to the analysis of Vladimir Andreev which shows that the impact of this practice is minimal? From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Erik Bais The goal of this proposal is to stop the abuse of opening a new LIR, transferring the /22 for profit to another LIR and close the LIR. As it is against the original intent of the final /8 last /22 procedure (https://www.ripe.net/publications/docs/ripe-643#51 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at kebab.org.pl Thu Apr 23 18:16:42 2015 From: tom at kebab.org.pl (-TOM-) Date: Thu, 23 Apr 2015 18:16:42 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <55390CDA.2000303@tvt-datos.es> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> Message-ID: <55391AEA.4030601@kebab.org.pl> W dniu 2015-04-23 o 17:16, Daniel Baeza (Red y Sistemas TVT) pisze: > > Why Elvis, a well know IP Broker from V4Escrow, proposed this instead > of "Unused space should be returned to RIPE"??? > Yessss!!! There are tons of unused /16's and even RIPE after ERX and LEGACY actions has currently no contact or confirmations to many of their holders. Thus the database is still full of garbage leaving people who need IPv4 to be potential fraud victim. Moreover, I think that the depletion of IPv4 space in RIPE region may not be real. IMO all the legacy space, that has not been confirmed in use (for example no contact with legitimate holder, no route objects within it) in next .... 6-12(?) months should be implicitly returned to the free pool. > Did the community think about if all the offers in the Listing Service > are reclaimed from RIPE, the IPv4 Exhaustion "dissapear"? > > Why nobody in the community proposed it? > Let's make the proposal. Best regards Tomasz ?l?ski From vladimir at quick-soft.net Thu Apr 23 18:26:38 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Thu, 23 Apr 2015 19:26:38 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3006371429788031@web27m.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <3006371429788031@web27m.yandex.ru> Message-ID: <4786361429806398@web26g.yandex.ru> One correction: Not > Total count of allocated blocks can be calculated (approximately) as A * B where A and B are octets in allocation address 185.A.B.0/22. > Octet A can be named "series" and B / 4 is possible block count in each "series". > > B is always 64 and A (for now) is 97. Thus totally allocated T2 = 97 * 64 = 6208 blocks from last /8. But > Total count of allocated blocks can be calculated (approximately) as A * B / 4 where A and B are octets in allocation address 185.A.B.0/22. > Octet A can be named "series" and B / 4 is possible block count in each "series". > > B is always 128 and A (for now) is 97. Thus totally allocated T2 = 97 * 128 / 4 = 6208 blocks from last /8. Final digits are the same. 23.04.2015, 14:20, "Vladimir Andreev" : > Hi, All! > > I decided to express my opinion regarding this proposal. > > As appears from the proposal summary it pursues the following goals: > > 1. prevent opening LIR, receiving /22 and selling it > 2. prevent making a financial profit from st. 1 > 3. save IPv4 space from exhaustion > > Looking at listed items I can suppose either Elvis is angry at people earning money or really /22 reselling is bad for RIPE and its community. > At half part of my letter I prove that /22 reselling has negligible impact on community. > > As a way to achieve the goals the proposal offer to substitute st. 5.5 from ripe-623 for: > > "LIRs that receive an allocation from the RIPE NCC or a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation." > > If pointed change to st. 5.5 is accepted we will face with the following: > > - Black market of /22 transfers will grow rapidly. Companies wishing to acquire IPv4 space can compose fake papers with sellers regarding merging/acquisition and send it to RIPE NCC (like IPv4 PI space as it was till recently). Also it should be noted that RIPE NCC can't forbid transfers which are under merging/acquisition since such transfers only reflect internal company(is) structure. > - Companies wishing to sell /22 can just wait for 24 months (if they have enough patience of course). > - The policy doesn't prevent opening multiple LIR's, merging LIR's together and then using received /22's for own company needs. > > In other words the policy doesn't introduce sufficient arrangements to achieve set goals. I.e. in current view the policy is inoperative. > > --------------------------------------------------------------------------------------------- > > Let's calculate what ratio of transferred /22's from last /8 (T1) to total count of allocated /22's (T2) is. > > At https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers page type into filter "185.0". > After that go to web browser console and type: $('#transfers-table-allocations tr').length > > For 23 April 2015 we have T1 = 237. > > Total count of allocated blocks can be calculated (approximately) as A * B where A and B are octets in allocation address 185.A.B.0/22. > Octet A can be named "series" and B is possible block count in each "series". > > B is always 64 and A (for now) is 97. Thus totally allocated T2 = 97 * 64 = 6208 blocks from last /8. > > Ratio of transferred blocks is 237 / 6208 * 100 ~ 3.81% > > From my point of view it's NOT SIGNIFICANT number at all. > > --------------------------------------------------------------------------------------------- > > Let's also calculate how /22 reselling impact on IPv4 exhaustion. > > RIPE NCC allocate approximately 10-15 /22's per day of 40-60 /22's per week (S). Averaging will receive S = 50. > > Sold /22's have sped up IPV4 exhaustion only for T1 / S = 237 / 50 = 4.74 weeks. > > I.e. /22 reselling impact is just 1 MONTH of exhaustion! > > --------------------------------------------------------------------------------------------- > > Summarizing I would like to say that the proposal has questionable reasons of its introduction, also questionable goals and offer inoperative changes to RIPE NCC policy. > > Also I believe that listed arguments will help WG to make Impact Analysis. > > 23.04.2015, 13:29, "Infinity Telecom SRL" : >> ??Hello, >> >> ??If this proposal will be accepted: https://www.ripe.net/participate/policies/proposals/2015-01 >> >> ??The price per IP found at "IPv4 Transfer Listing Service" ?will be double or even worst. >> >> ??Little companies will be out of business.. and we will be one of them. >> >> ??To pay double or even more for some spammed IP.. ?its not a good choice.. only because smart guys with no real internet business hold very large blocks >> >> ??This proposal should have more time, its not like any other proposal, this can affect activity for a lot of small companies. >> >> ??Thank you. >> >> ??-- >> ??Cu stima, >> ??Gabriel Voitis | Sales Manager >> ??voitis at infinitytelecom.ro >> >> ??INFINITY TELECOM SRL ?| ?Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 >> ??Mobil: +40 0725 677 477 ?| ?Tel: +40 021 7808805 ?| ?Fax: +40 021 7808806 >> ??contact at infinitytelecom.ro > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From jkennedy at libertyglobal.com Thu Apr 23 18:32:42 2015 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Thu, 23 Apr 2015 16:32:42 +0000 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: <028e01d07ddb$8b2ee300$a18ca900$@a2b-internet.com> References: <553904F4.7090706@ssd.axu.tm>, <028e01d07ddb$8b2ee300$a18ca900$@a2b-internet.com> Message-ID: <66230795-2CA8-4CAD-AD11-8E7B1F7B68B2@upcbroadband.com> Lol, me too :) Glad 2015-02 hasn't ruffled so many feathers. Thanks for the support. Regards, James Sent from my iPhone > On 23 Apr 2015, at 17:38, "Erik Bais" wrote: > > This made me smile while reading all the other emails on the AP-WG list > today :) > >>> On 04/14/2015 03:52 PM, Marco Schmidt wrote: >>> A proposed change to RIPE Document "IPv6 Address Allocation and > Assignment Policy" >>> is now available for discussion. > >> James Kennedy! You are my hero! > >> I support the spirit of the proposal, but I haven't read the text yet. > > Especially that last bit :) > > Regards, > Erik Bais > > > From ebais at a2b-internet.com Thu Apr 23 18:33:15 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 23 Apr 2015 18:33:15 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> Message-ID: <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> Hi Milton, > Erik: > Have you responded to the analysis of Vladimir Andreev which shows that the impact of this practice is minimal? > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Erik Bais > The goal of this proposal is to stop the abuse of opening a new LIR, transferring the /22 for profit to another LIR and close the LIR. > As it is against the original intent of the final /8 last /22 procedure ?(https://www.ripe.net/publications/docs/ripe-643#51 ) But I'll gladly reply to it .. His analyses goes wrong at the following line : > Looking at listed items I can suppose either Elvis is angry at people earning money or really /22 reselling is bad for RIPE and its community. That is a false assumption and an incorrect stab in the back at Elvis, a well known community member, who stepped up at the last RIPE meeting and offered to write the proposal after the RIPE NCC pointed out that they have seen an increase in this practice and are warning about this as a new practice which is against the intent of the actual policy. As a broker and a community member myself, having written several policies myself, what one might do for the community, may not always align with someone their business processes. I've written the policy to allow RPKI for NON-Members .. A policy to remove the multi-homing requirement for PI IPv6 .. a policy to allow the transfer of IPv6 prefixes .. I think that I can safely say that it is a cheap stab in the back to even HINT ... that personal agenda's are behind this proposal .. There is more at stake here than a the business we do (out-side the RIPE mailing list or RIPE meetings.. ) and the one that is paying our mortgage ... either as an ISP or a broker. . . Stating that brokers are behind it ... and that getting IP's via a sign-up of a new LIR is something that is hurting the broker business ... that is just false. I know most of the brokers in the community ... and I agree with Vladimir in his analysis .. this has less than minimal impact ... ( as I see it with a broker hat on .. ) The intent for the reservation from the final /8 is for new companies to start an ISP in the next 6 to 10 years .. is why this was put into the policy ... Because it is close to impossible to start without ANY ipv4 .. And as a bit it more than nothing .. that is why this has been put into policy .. Simply because you can't do any CGNAT .. if you don't have ANY IPv4 ... This way at least you have an option .. besides building a v6 only network. The fact that Vladimir points out that the policy CURRENTLY may not be abused as much as one might think ... that does not mean that for the cases where it is clearly abused... it didn't happen. I think that reading the discussion at the mailing list .. that the intent of some of the people in this community as different as one might hope for.. Personally I don't care if people are going to open a new LIR for themselves or if they are going to use the gained resources in order to sell them ... What I do care about is that the reason why the initial reservation was done in the first place .. from that final /8.. with all good and noble intentions of the proposers at that time ... has now become a cheap loophole for some to be used for their own benefit, with the possible side-effect that others in this very same community will be left out in the future, because we did plan for new entries .. but didn't care enough to fix the loopholes we noticed down the line. Will this proposal fix the issue to dis-allow a second /22 from the final /8 in the same LIR ? Nope. It is still possible to get a /22 transferred into an LIR that already holds a /22 from the final /8. And it is will also still be possible to do a M&A of an LIR into another LIR .. and then you will also have 2 * a /22 from the final /8 ... So is it perfect ? No ... But .. will it make the initial intent of the policy more clear ? or will it move the policy into the right direction ? YES ... Will this have a significant impact on slowing down the consumption rate of the actual reserved pool in the final /8 ? Not really .. Similar as proposing to revoke all un-routed IPv4 space back to the RIR .. and start re-issuing it ... That only delays the inevitable .... APNIC is out, RIPE is out ... ARIN is down to the last .23 of their final /8 ... There is no future in IPv4 beyond 7 years ... ( Is my humble guess.. ) Who knows .. the next Whatsapp or Twitter might come from that one company that registers as an LIR in that delayed 4 weeks because of this proposal ... So, to close of the argument here .. kudo's to Elvis for writing the proposal .. I'm glad to see that it is going to be fixed, because it is the right thing to do.. Please let me know if you have any additional questions. Regards, Erik Bais From Ian.Dickinson at sky.uk Thu Apr 23 18:39:22 2015 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Thu, 23 Apr 2015 16:39:22 +0000 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE4B019E51@WPMBX010.bskyb.com> Well said Erik, and +1 to the proposal Ian -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Erik Bais Sent: 23 April 2015 17:33 To: 'Milton L Mueller'; address-policy-wg at ripe.net; 'Vladimir Andreev' Subject: Re: [address-policy-wg] Transfer Requirements for IPv4 Allocations Hi Milton, > Erik: > Have you responded to the analysis of Vladimir Andreev which shows that the impact of this practice is minimal? > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Erik Bais > The goal of this proposal is to stop the abuse of opening a new LIR, transferring the /22 for profit to another LIR and close the LIR. > As it is against the original intent of the final /8 last /22 procedure (https://www.ripe.net/publications/docs/ripe-643#51 ) But I'll gladly reply to it .. His analyses goes wrong at the following line : > Looking at listed items I can suppose either Elvis is angry at people earning money or really /22 reselling is bad for RIPE and its community. That is a false assumption and an incorrect stab in the back at Elvis, a well known community member, who stepped up at the last RIPE meeting and offered to write the proposal after the RIPE NCC pointed out that they have seen an increase in this practice and are warning about this as a new practice which is against the intent of the actual policy. As a broker and a community member myself, having written several policies myself, what one might do for the community, may not always align with someone their business processes. I've written the policy to allow RPKI for NON-Members .. A policy to remove the multi-homing requirement for PI IPv6 .. a policy to allow the transfer of IPv6 prefixes .. I think that I can safely say that it is a cheap stab in the back to even HINT ... that personal agenda's are behind this proposal .. There is more at stake here than a the business we do (out-side the RIPE mailing list or RIPE meetings.. ) and the one that is paying our mortgage ... either as an ISP or a broker. . . Stating that brokers are behind it ... and that getting IP's via a sign-up of a new LIR is something that is hurting the broker business ... that is just false. I know most of the brokers in the community ... and I agree with Vladimir in his analysis .. this has less than minimal impact ... ( as I see it with a broker hat on .. ) The intent for the reservation from the final /8 is for new companies to start an ISP in the next 6 to 10 years .. is why this was put into the policy ... Because it is close to impossible to start without ANY ipv4 .. And as a bit it more than nothing .. that is why this has been put into policy .. Simply because you can't do any CGNAT .. if you don't have ANY IPv4 ... This way at least you have an option .. besides building a v6 only network. The fact that Vladimir points out that the policy CURRENTLY may not be abused as much as one might think ... that does not mean that for the cases where it is clearly abused... it didn't happen. I think that reading the discussion at the mailing list .. that the intent of some of the people in this community as different as one might hope for.. Personally I don't care if people are going to open a new LIR for themselves or if they are going to use the gained resources in order to sell them ... What I do care about is that the reason why the initial reservation was done in the first place .. from that final /8.. with all good and noble intentions of the proposers at that time ... has now become a cheap loophole for some to be used for their own benefit, with the possible side-effect that others in this very same community will be left out in the future, because we did plan for new entries .. but didn't care enough to fix the loopholes we noticed down the line. Will this proposal fix the issue to dis-allow a second /22 from the final /8 in the same LIR ? Nope. It is still possible to get a /22 transferred into an LIR that already holds a /22 from the final /8. And it is will also still be possible to do a M&A of an LIR into another LIR .. and then you will also have 2 * a /22 from the final /8 ... So is it perfect ? No ... But .. will it make the initial intent of the policy more clear ? or will it move the policy into the right direction ? YES ... Will this have a significant impact on slowing down the consumption rate of the actual reserved pool in the final /8 ? Not really .. Similar as proposing to revoke all un-routed IPv4 space back to the RIR .. and start re-issuing it ... That only delays the inevitable .... APNIC is out, RIPE is out ... ARIN is down to the last .23 of their final /8 ... There is no future in IPv4 beyond 7 years ... ( Is my humble guess.. ) Who knows .. the next Whatsapp or Twitter might come from that one company that registers as an LIR in that delayed 4 weeks because of this proposal ... So, to close of the argument here .. kudo's to Elvis for writing the proposal .. I'm glad to see that it is going to be fixed, because it is the right thing to do.. Please let me know if you have any additional questions. Regards, Erik Bais Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From aleksbulgakov at gmail.com Thu Apr 23 19:04:57 2015 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Thu, 23 Apr 2015 20:04:57 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE4B019E51@WPMBX010.bskyb.com> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <9B3BFE0A18160E40BAF1950414D10FAE4B019E51@WPMBX010.bskyb.com> Message-ID: Relatively high price kept /8 from exhaustion. But if the proposal will be approved, resellers can change their business and start to consult providers about IPv4 receiving that accelerate exhaustion and new internet businesses won't have enough IPv4 allocations. Surely it will stimulate to implement IPv6 networks. But the process is very slow. And many higher providers still use IPv4 equipment. What do you think about it? 2015-04-23 19:39 GMT+03:00 Dickinson, Ian : > Well said Erik, and +1 to the proposal > > Ian > > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Erik Bais > Sent: 23 April 2015 17:33 > To: 'Milton L Mueller'; address-policy-wg at ripe.net; 'Vladimir Andreev' > Subject: Re: [address-policy-wg] Transfer Requirements for IPv4 Allocations > > Hi Milton, > >> Erik: >> Have you responded to the analysis of Vladimir Andreev which shows that > the impact of this practice is minimal? > >> From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Erik Bais >> The goal of this proposal is to stop the abuse of opening a new LIR, > transferring the /22 for profit to another LIR and close the LIR. >> As it is against the original intent of the final /8 last /22 procedure > (https://www.ripe.net/publications/docs/ripe-643#51 ) > > But I'll gladly reply to it .. > > His analyses goes wrong at the following line : > >> Looking at listed items I can suppose either Elvis is angry at people > earning money or really /22 reselling is bad for RIPE and its community. > > That is a false assumption and an incorrect stab in the back at Elvis, a > well known community member, who stepped up at the last RIPE meeting and > offered to write the proposal after the RIPE NCC pointed out that they have > seen an increase in this practice and are warning about this as a new > practice which is against the intent of the actual policy. > > As a broker and a community member myself, having written several policies > myself, what one might do for the community, may not always align with > someone their business processes. > I've written the policy to allow RPKI for NON-Members .. A policy to remove > the multi-homing requirement for PI IPv6 .. a policy to allow the transfer > of IPv6 prefixes .. > I think that I can safely say that it is a cheap stab in the back to even > HINT ... that personal agenda's are behind this proposal .. There is more at > stake here than a the business we do (out-side the RIPE mailing list or RIPE > meetings.. ) and the one that is paying our mortgage ... either as an ISP > or a broker. . . > > Stating that brokers are behind it ... and that getting IP's via a sign-up > of a new LIR is something that is hurting the broker business ... that is > just false. > I know most of the brokers in the community ... and I agree with Vladimir in > his analysis .. this has less than minimal impact ... ( as I see it with a > broker hat on .. ) > > The intent for the reservation from the final /8 is for new companies to > start an ISP in the next 6 to 10 years .. is why this was put into the > policy ... Because it is close to impossible to start without ANY ipv4 .. > And as a bit it more than nothing .. that is why this has been put into > policy .. Simply because you can't do any CGNAT .. if you don't have ANY > IPv4 ... This way at least you have an option .. besides building a v6 only > network. > > The fact that Vladimir points out that the policy CURRENTLY may not be > abused as much as one might think ... that does not mean that for the cases > where it is clearly abused... it didn't happen. > > I think that reading the discussion at the mailing list .. that the intent > of some of the people in this community as different as one might hope for.. > > Personally I don't care if people are going to open a new LIR for themselves > or if they are going to use the gained resources in order to sell them ... > > What I do care about is that the reason why the initial reservation was done > in the first place .. from that final /8.. with all good and noble > intentions of the proposers at that time ... has now become a cheap loophole > for some to be used for their own benefit, with the possible side-effect > that others in this very same community will be left out in the future, > because we did plan for new entries .. but didn't care enough to fix the > loopholes we noticed down the line. > > Will this proposal fix the issue to dis-allow a second /22 from the final /8 > in the same LIR ? Nope. It is still possible to get a /22 transferred into > an LIR that already holds a /22 from the final /8. > And it is will also still be possible to do a M&A of an LIR into another LIR > .. and then you will also have 2 * a /22 from the final /8 ... > > So is it perfect ? No ... > > But .. will it make the initial intent of the policy more clear ? or will it > move the policy into the right direction ? YES ... > Will this have a significant impact on slowing down the consumption rate of > the actual reserved pool in the final /8 ? Not really .. Similar as > proposing to revoke all un-routed IPv4 space back to the RIR .. and start > re-issuing it ... > That only delays the inevitable .... APNIC is out, RIPE is out ... ARIN is > down to the last .23 of their final /8 ... There is no future in IPv4 beyond > 7 years ... ( Is my humble guess.. ) > > Who knows .. the next Whatsapp or Twitter might come from that one company > that registers as an LIR in that delayed 4 weeks because of this proposal > ... > > So, to close of the argument here .. kudo's to Elvis for writing the > proposal .. I'm glad to see that it is going to be fixed, because it is the > right thing to do.. > > Please let me know if you have any additional questions. > > Regards, > Erik Bais > > > > > > > > > Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. > -- ---------- Best regards, Aleksey Bulgakov Tel.: +7 (926)690-87-29 From tom at kebab.org.pl Thu Apr 23 19:24:21 2015 From: tom at kebab.org.pl (-TOM-) Date: Thu, 23 Apr 2015 19:24:21 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <9B3BFE0A18160E40BAF1950414D10FAE4B019E51@WPMBX010.bskyb.com> Message-ID: <55392AC5.9020101@kebab.org.pl> W dniu 2015-04-23 o 19:04, Aleksey Bulgakov pisze: > Surely it will stimulate to implement IPv6 networks. But the process > is very slow. And many higher providers still use IPv4 equipment. > IMO the first big stimulation point to speed-up the IPv6 roll-out was in February 2011, the "last call" was in September 2012. And after nearly 3 years there is no revolution. Still pure V6 networks without any piece of V4 are practically unusable. best regards Tomasz ?l?ski From tore at fud.no Thu Apr 23 20:03:15 2015 From: tore at fud.no (Tore Anderson) Date: Thu, 23 Apr 2015 20:03:15 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> Message-ID: <20150423200315.73691998@envy.fud.no> * Radu-Adrian FEURDEAN > While some people agree with the concept, I'm not sure that the > community in its whole (or majority) will agree with rolling-back > several years of (already-established) policies. This definitely needs > more discussion (maybe during a meeting): > - restore needs-based allocation (which has been "abolished" in order > to legitimate already widespread but not really appreciated practice- > lying about "needs" and "use") > - soften the "last /8" policy - between 2010 and now the situation > changed, and things will change even more in the upcoming years. Not to > mention that now we have some real-life experience. Hello Radu-Adrian, It was the ?last /8 policy? itself that abolished needs-based allocation, actually. After its implementation in autumn 2012, each LIR gets only a single /22, regardless of its actual need (which could be both larger or smaller than a /22). The rationale for this policy was not at all to ?legitimate lying?, but to attempt to ensure that new entrants would still be able to get hold of a little bit of IPv4 five or maybe even ten years after depletion. If we re-instate needs-based allocation, I'd expect that the RIPE NCC's remaining IPv4 pool would evaporate completely more or less over-night. The ~18 million IPv4 addresses in the RIPE NCC's pool are likely not nearly enough to cover the latent unmet need that has been building in the region since the ?last /8 policy? was implemented. Tore From swmike at swm.pp.se Thu Apr 23 20:12:45 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 23 Apr 2015 20:12:45 +0200 (CEST) Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423200315.73691998@envy.fud.no> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> <20150423200315.73691998@envy.fud.no> Message-ID: On Thu, 23 Apr 2015, Tore Anderson wrote: > If we re-instate needs-based allocation, I'd expect that the RIPE NCC's > remaining IPv4 pool would evaporate completely more or less over-night. > The ~18 million IPv4 addresses in the RIPE NCC's pool are likely not > nearly enough to cover the latent unmet need that has been building in > the region since the ?last /8 policy? was implemented. Looking at http://www.potaroo.net/tools/ipv4/ (figure 28e) the RIPE allocation rate was around 2-3 /8:s per year at the time of the last /8 policy kicked into effect, so the ~18 million addresses would be gone in a matter of days, at the same rate that LIRs could create applications and send them in. So apart from a few people, most of us agree that any attempt at changing policy in the more liberal direction is doomed to fail miserably. -- Mikael Abrahamsson email: swmike at swm.pp.se From gert at space.net Thu Apr 23 20:20:00 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 20:20:00 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> References: <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> Message-ID: <20150423182000.GO54385@Space.Net> Hi, this thread has drifted quite far, but a few comments need to be made: On Thu, Apr 23, 2015 at 04:33:29PM +0200, Radu-Adrian FEURDEAN wrote: > While some people agree with the concept, I'm not sure that the > community in its whole (or majority) will agree with rolling-back > several years of (already-established) policies. This definitely needs > more discussion (maybe during a meeting): It definitely is way outside the scope of this proposal. Bringing back needs based allocation, removing the last-/8 policy, or changing the size of the last-/8 allocation would have to be a separate policy proposal. > - restore needs-based allocation (which has been "abolished" in order > to legitimate already widespread but not really appreciated practice- > lying about "needs" and "use") Actually if you go back and actually read the discussion concerning that proposal, it has been abolished because there is nothing left to allocate based on "need" - if I need a /8, and you need a /20, we both get a /22, so where's the benefit in having a complex system that will lead to the same result anyway, no matter how big your need is? > - soften the "last /8" policy - between 2010 and now the situation > changed, and things will change even more in the upcoming years. Not to > mention that now we have some real-life experience. In which way has the situation changed, except that we're now very close to *3* RIRs having run out of IPv4 addresses (and/or are in the "last /8" phase)? Has someone discovered a magic store of IPv4 addresses that we can use to return to the time of large pools and /10 allocations to big telcos? I'm sure you understand that there's thousands of RIPE LIRs out there that *all* want IPv4 space - so if you loosen up the policy too far, RIPE NCC will dry out in a few months, and nothing will be left. This is what ARIN (consciously) did, not having a soft-landing / last-/8 policy, and we decided that we want to have a long tail of "some leftover bits of addresses to hand to newcomers in the market, 5 or 10 years hence". 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 sebastian at karotte.org Thu Apr 23 21:09:03 2015 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Thu, 23 Apr 2015 21:09:03 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <55390CDA.2000303@tvt-datos.es> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> Message-ID: <20150423190903.GA21587@danton.fire-world.de> * Daniel Baeza (Red y Sistemas TVT) [2015-04-23 17:21]: > >... and the community is free to declare that "Make another LIR and move > >resources to old LIR (right away)" is considered abuse of the last /8 > >policy, and dis-incentivize it... > > Sure we are. But I always have seen a problem with this kind of > proposals and the community. > The problem is that lot of members of the community are IP > Trader/Broker/Sellers so, a policy such this one are VERY GOOD for > them while is VERY BAD for the new lirs that only hold a /22. > The community should be objetive, and Im pretty sure it isnt. I don't think that "a lot" of the community are IP traders (and by that I mean companies that make profit by buying/selling IPv4). They are one part of the community. > Why Elvis, a well know IP Broker from V4Escrow, proposed this > instead of "Unused space should be returned to RIPE"??? Because he was the one who actually submitted the proposal. More people agreed that this proposal would be useful (me among them). > Did the community think about if all the offers in the Listing > Service are reclaimed from RIPE, the IPv4 Exhaustion "dissapear"? No, the IPv4 exhaustion will not "disappear". :) Please stop spreading such an urban myth. You can be proven wrong by simple mathematics. > Why nobody in the community proposed it? Because it is nonsense. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 616 bytes Desc: Digital signature URL: From leo.vegoda at icann.org Thu Apr 23 21:53:10 2015 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 23 Apr 2015 19:53:10 +0000 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423190903.GA21587@danton.fire-world.de> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> <20150423190903.GA21587@danton.fire-world.de> Message-ID: Sebastian Wiesinger wrote: [...] > I don't think that "a lot" of the community are IP traders (and by > that I mean companies that make profit by buying/selling IPv4). They > are one part of the community. The RIPE NCC helpfully publishes a list of brokers that have signed up to its Recognized IPv4 Transfer Agreement: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4 -transfers/brokers Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4968 bytes Desc: not available URL: From aleksbulgakov at gmail.com Thu Apr 23 22:10:59 2015 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Thu, 23 Apr 2015 23:10:59 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> <20150423190903.GA21587@danton.fire-world.de> Message-ID: So what is the benefit for Elvis, who is the broker? If he found 2 sides who make the transfer he will lose the part of clients. If this proposal doesn't affect him all resellers will be brokers. 23 ??? 2015 ?. 22:53 ???????????? "Leo Vegoda" ???????: > Sebastian Wiesinger wrote: > > [...] > > > I don't think that "a lot" of the community are IP traders (and by > > that I mean companies that make profit by buying/selling IPv4). They > > are one part of the community. > > The RIPE NCC helpfully publishes a list of brokers that have signed up to > its Recognized IPv4 Transfer Agreement: > > > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4 > -transfers/brokers > > Regards, > > Leo Vegoda > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Apr 23 23:16:23 2015 From: gert at space.net (Gert Doering) Date: Thu, 23 Apr 2015 23:16:23 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> <20150423190903.GA21587@danton.fire-world.de> Message-ID: <20150423211623.GQ54385@Space.Net> Hi, On Thu, Apr 23, 2015 at 11:10:59PM +0300, Aleksey Bulgakov wrote: > So what is the benefit for Elvis, who is the broker? > > If he found 2 sides who make the transfer he will lose the part of clients. > If this proposal doesn't affect him all resellers will be brokers. If you read the minutes of the APWG meeting at the previous RIPE meeting, you can see that the issue was brought up by the RIPE NCC. The group in the room decided that it would be good to do something about it, and Elvis volunteered to write up something formal to get the discussion going. It's not like Elvis made this up to further his business. (And, as a call for order: further personal attacks on the personal integrity of a proposer will not help bring forward your argument. If you do not like a proposal, bring forth factual arguments that people can answer - personal attacks will just disqualify your voice when the chairs go about judging consensus) 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 aleksbulgakov at gmail.com Fri Apr 24 00:40:19 2015 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Fri, 24 Apr 2015 01:40:19 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423211623.GQ54385@Space.Net> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> <20150423190903.GA21587@danton.fire-world.de> <20150423211623.GQ54385@Space.Net> Message-ID: I don't attack anybody, I am just interesting 24 ??? 2015 ?. 0:16 ???????????? "Gert Doering" ???????: > Hi, > > On Thu, Apr 23, 2015 at 11:10:59PM +0300, Aleksey Bulgakov wrote: > > So what is the benefit for Elvis, who is the broker? > > > > If he found 2 sides who make the transfer he will lose the part of > clients. > > If this proposal doesn't affect him all resellers will be brokers. > > If you read the minutes of the APWG meeting at the previous RIPE meeting, > you can see that the issue was brought up by the RIPE NCC. The group > in the room decided that it would be good to do something about it, and > Elvis volunteered to write up something formal to get the discussion going. > > It's not like Elvis made this up to further his business. > > (And, as a call for order: further personal attacks on the personal > integrity of a proposer will not help bring forward your argument. If > you do not like a proposal, bring forth factual arguments that people > can answer - personal attacks will just disqualify your voice when the > chairs go about judging consensus) > > 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 -------------- An HTML attachment was scrubbed... URL: From modonovan at btireland.net Fri Apr 24 14:08:57 2015 From: modonovan at btireland.net (Mick O Donovan) Date: Fri, 24 Apr 2015 13:08:57 +0100 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150423211623.GQ54385@Space.Net> References: <1579994104.20150423131841@infinitytelecom.ro> <20150423111216.GS54385@Space.Net> <788721892.20150423143855@infinitytelecom.ro> <20150423114348.GT54385@Space.Net> <55390CDA.2000303@tvt-datos.es> <20150423190903.GA21587@danton.fire-world.de> <20150423211623.GQ54385@Space.Net> Message-ID: <20150424120856.GB5829@carra.btireland.net> Hi all, I said I'd stay out of this "discussion" as there was a lot of back and forth on it and it seems to have been getting quite heated. That said ... On Thu, Apr 23, 2015 at 11:16:23PM +0200, Gert Doering wrote: > (And, as a call for order: further personal attacks on the personal > integrity of a proposer will not help bring forward your argument. If > you do not like a proposal, bring forth factual arguments that people > can answer - personal attacks will just disqualify your voice when the > chairs go about judging consensus) I have to endorse this statement fully. As a relative newbie participant in the APWG, I think this has to be the most important point. If someone brings a proposal to the community (for whatever their reason) it shouldn't give people the right to defame or question their integrity. Certainly question the proposal and write a counter proposal but why choose to single out the individual that's raise the proposal to question their intent. You/we either agree with the proposal or we don't. Simple - that's how I see it anyway. Peace out... -- Mick O'Donovan | Network Engineer | BT Ireland | Website: http://www.btireland.net Looking Glass: http://lg.as2110.net Peering Record: http://as2110.peeringdb.com AS-SET Macro: AS-BTIRE | ASN: 2110 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: Digital signature URL: From ripe-wgs at radu-adrian.feurdean.net Fri Apr 24 16:29:38 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 24 Apr 2015 16:29:38 +0200 Subject: [address-policy-wg] "needs", last /8, ... (Was: Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150423182000.GO54385@Space.Net> References: <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> <20150423182000.GO54385@Space.Net> Message-ID: <1429885778.1593177.258087117.2DF6AF54@webmail.messagingengine.com> On Thu, Apr 23, 2015, at 20:20, Gert Doering wrote: > Hi, > > this thread has drifted quite far, but a few comments need to be made: Hence the subject change.... > It definitely is way outside the scope of this proposal. Bringing back > needs based allocation, removing the last-/8 policy, or changing the > size of the last-/8 allocation would have to be a separate policy > proposal. I agree with this. The real question is : do we need any of these changes or not ? If yes, which of them and in which form. I preffer some discussion before trying to propose anything. > proposal, it has been abolished because there is nothing left to allocate > based on "need" - if I need a /8, and you need a /20, we both get a /22, Some don't even "need" a /22. But they can get it (and then sell it). Before, you had to provide some explanation on why do you need your last /22. Now you don't - you just promise to make allocations out of it. > so where's the benefit in having a complex system that will lead to the > same result anyway, no matter how big your need is? The "same result" is the part I don't fully agree with. > In which way has the situation changed, except that we're now very close > to *3* RIRs having run out of IPv4 addresses (and/or are in the "last /8" > phase)? Today's state of fact: - APNIC : last /8 policy since 2011. LIRs can get one /22 from the "103-pool" and one /22 fron the "non-103" pool, which only exists sicne 2014. "needs-based". - LACNIC : phase 2 (of 3) of the run-out plan since 06/2014, companies can get a /22 every 6 months, until the reserves fall to a /11 (phase 3, where strictly one /22 will be available). Gradual enforcement of the needs-checking. - ARIN : last /8, phase 4 since 04/2014 - members("LIRs") can get as much as whey "need", with the chacking of actual needs being reinforced. - AfriNIC : "peace and love", 2.6 /8s available. About 2 years ahead before entering in any form of "last /8". - RIPE NCC: "last /8" since 09/2012. As of 04/2015 (more than 30 months later) the free pool is *bigger* than a /8, due to recovered and re-allocated space from IANA). No needs policy. Exactly one /22 per LIR, but with a backdoor (several LIRs). Short : the situation changed by the fact that now RIPE has a bigger pool than at the time of actication of the "last /8" policy. Yes, after 2.5 years, RIPE has more free space. Second RIR in terms of "free stock" and the most conservative at the same time. > Has someone discovered a magic store of IPv4 addresses that we > can use to return to the time of large pools and /10 allocations to big > telcos? There is a huge distance between /22 and /10. Some people would be more than happy with a /20, which is probably what some big telcos would be able to recover just by recovering space provisioned for "no longer clients". Some strict needs-based allocation should be able to help some small players to get to a decent situation. We basically have almost 3 years worth of /22 available via "returned space" that could be re-distributed : - based on valid/validated needs - from the IANA recovered space allocated to RIPE NCC - only to players below a certain threshold (like the ones having only received a /22 from the 185-pool, or the ones that never received more than a /20 or /21) - extra allocation possible X months after the "185-pool allocation" , X to be defined (?? 12 ?? 24 ??) - second and possibly third allocation, if still available after another Y months (Y = ?? 12 ?? 24 ?? 30 ?? 36 ??) Those are just ideas, not all of them need to be transposed into policy text (if policy will be). > I'm sure you understand that there's thousands of RIPE LIRs out there > that *all* want IPv4 space - so if you loosen up the policy too far, RIPE NCC No, they don't *ALL* want IPv4 space, and amongst the ones that do want, not all of them want it today. Hell, there's some of then that only wanted a /24 or /23 PI space ! > will dry out in a few months, and nothing will be left. This is what ARIN > (consciously) did, not having a soft-landing / last-/8 policy, and we > decided that we want to have a long tail of "some leftover bits of addresses > to hand to newcomers in the market, 5 or 10 years hence". 5-10 years since when ? since 09/2012 ? At the current rate we will do the 5 years (2017) without any problems, and still have enough space. We will most probably do the 10 years (2022) and still have some space. On the other hand, how do you really expect people to take IPv6 seriously when you plan on having "just enough" free IPv4 space by 2020 ? Did you disqualify any vendor because of lack of IPv6 support ? Becasue of improper IPv6 support ? Because of impossibility to function without IPv4 ? I expect *you* did it at least once, but how many people didn't because, "nah, we can sill have some IPv4, more than enough if we count the RFC1918" ? Provider-wise, you need IPv4 for lots of things, unless you do it "corporate-style" (RFC1918 everywhere, with the risk of "my 10.1.1.2 must send data to your 10.1.1.2"). So no, softening the "last /8 policy" does not necesarily mean giving big allocations to everyone and burning out ressources in 2 months. And shortening the life of the "free pool" by a few years isn't necesarily such a bad thing in the global context. Besides, we just won 2.5 years recently. Also imagine the posibilities of what might happen when ARIN will be totally out of stock (most probably before the end of the year) if US companies start opening subsidiaries in Europe just in order to have some more small chunks of IPv4; because there's no needs checking. Do we want ot handle those situations in a reactive manner (like this open-transfer-close issue) or in a more pro-active one ? > have you enabled IPv6 on something today...? No, had to fix broken IPv6 things. -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Fri Apr 24 17:16:31 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 24 Apr 2015 17:16:31 +0200 Subject: [address-policy-wg] "needs", last /8, ... (Was: Transfer Requirements for IPv4 Allocations) In-Reply-To: References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> <20150423200315.73691998@envy.fud.no> Message-ID: <1429888591.1606063.258136725.40C7B1CD@webmail.messagingengine.com> On Thu, Apr 23, 2015, at 20:12, Mikael Abrahamsson wrote: > On Thu, 23 Apr 2015, Tore Anderson wrote: > > > If we re-instate needs-based allocation, I'd expect that the RIPE NCC's > > remaining IPv4 pool would evaporate completely more or less over-night. > > The ~18 million IPv4 addresses in the RIPE NCC's pool are likely not > > nearly enough to cover the latent unmet need that has been building in > > the region since the ?last /8 policy? was implemented. > > Looking at http://www.potaroo.net/tools/ipv4/ (figure 28e) the RIPE > allocation rate was around 2-3 /8:s per year at the time of the last /8 > policy kicked into effect, so the ~18 million addresses would be gone in a > matter of days, at the same rate that LIRs could create applications and > send them in. "Needs based" starts with "you don't get anything if you don't acutally have a need for". I suppose that "selling" does not qualify as "need". And "needs-based" doesn't imply "you get all that you need". For me an "you get what is available *IF* you need something" (and some other conditions) still counts as "needs-based". The problem now (Elvis' policy is just one more proof) is that LIRs can get space even if they don't actually need it: 1. Ask for "your space", *promise* to make allocations, get "your" space. 2. [Optional] Bring up a new instace of "you" and go to step 1. > So apart from a few people, most of us agree that any attempt at changing > policy in the more liberal direction is doomed to fail miserably. Again, *more* liberal, does not mean *most* liberal. There's a huge gap between the policies in force 13/09/2012 and before and the ones in force 14/09/2012 and after. This what I would like to see fixed. Could any of you have your company survive with only a /22 (and 10-15 $/IP extra, 256/512/1024 packs towards 15$/IP) ? From apwg at c4inet.net Fri Apr 24 18:07:07 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Fri, 24 Apr 2015 17:07:07 +0100 Subject: [address-policy-wg] "needs", last /8, ... (Was: Transfer Requirements for IPv4 Allocations) In-Reply-To: <1429888591.1606063.258136725.40C7B1CD@webmail.messagingengine.com> References: <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> <20150423200315.73691998@envy.fud.no> <1429888591.1606063.258136725.40C7B1CD@webmail.messagingengine.com> Message-ID: <20150424160707.GA35191@cilantro.c4inet.net> On Fri, Apr 24, 2015 at 05:16:31PM +0200, Radu-Adrian FEURDEAN wrote: >> So apart from a few people, most of us agree that any attempt at changing >> policy in the more liberal direction is doomed to fail miserably. > >Again, *more* liberal, does not mean *most* liberal. There's a huge gap >between the policies in force 13/09/2012 and before and the ones in >force 14/09/2012 and after. This what I would like to see fixed. >Could any of you have your company survive with only a /22 (and 10-15 >$/IP extra, 256/512/1024 packs towards 15$/IP) ? > If the community expended half as much effort on deploying IPv6 as it does on rationing the remaining shreds of ipv4, this problem wouldn't exist. rgds, Sascha Luck From swmike at swm.pp.se Fri Apr 24 21:57:29 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 24 Apr 2015 21:57:29 +0200 (CEST) Subject: [address-policy-wg] "needs", last /8, ... (Was: Transfer Requirements for IPv4 Allocations) In-Reply-To: <1429888591.1606063.258136725.40C7B1CD@webmail.messagingengine.com> References: <20150423122019.GW54385@Space.Net> <3584301429791754@web27g.yandex.ru> <20150423123811.GX54385@Space.Net> <3705731429792870@web27g.yandex.ru> <20150423124335.GZ54385@Space.Net> <3734711429793156@web27g.yandex.ru> <20150423125701.GB54385@Space.Net> <3861051429794346@web27g.yandex.ru> <20150423131228.GC54385@Space.Net> <3970461429795371@web27g.yandex.ru> <20150423133533.GD54385@Space.Net> <4065141429796389@web27g.yandex.ru> <5538F7C5.5060005@opteamax.de> <1429799609.1198299.257653517.21188FB0@webmail.messagingengine.com> <20150423200315.73691998@envy.fud.no> <1429888591.1606063.258136725.40C7B1CD@webmail.messagingengine.com> Message-ID: On Fri, 24 Apr 2015, Radu-Adrian FEURDEAN wrote: > Again, *more* liberal, does not mean *most* liberal. There's a huge gap > between the policies in force 13/09/2012 and before and the ones in > force 14/09/2012 and after. This what I would like to see fixed. Could > any of you have your company survive with only a /22 (and 10-15 $/IP > extra, 256/512/1024 packs towards 15$/IP) ? It all depends on the size of the company. You can comfortably serve around 50-100 residential customers per IPv4 address behind NAT444. Let's say you give each customer 512 ports, that gives you around 120 users per IPv4 address. Let's now say you allocate 3 /24:s for this use, meaning you can service 75-80k users out of this space that you acquired for a total TCO for 3 years of (if I remember correctly, 6kEUR in LIR costs). I'd say that if you can't bear 6kEUR over 3 years for 75k users, you're doing something wrong. The same model of course doesn't work if you're a VPS provider and require a unique IPv4 address per customer server. Then you're going to have to buy addresses to get what you need if you're any significant size. So whilst I do appreciate that you have actually presented something resembling a beginning of a proposal (compared to a lot of other people earlier in this thread), your model needs a cut-off somewhere where the company size "need" is now less valuable than the small company "need". Where do you draw the line? How do you define need? With the current policy we have reached consensus that we'll allow a /22 for new entrants, and if you need more, then you need to buy the addresses on the market. This means someone really small might get too many addresses, correct, and it means someone who is growing, will soon join the larger players in having to cope with "lack of enough IPv4 space". Yes, just like the housing market, it is unfair that the 80 year old lady is sitting in a 3 bedroom apartment with no mortgage whilst the family of four where both parents are working have to make do with a 1 bedroom apartment because they can't afford to buy a larger one. Unfortunately, there is no great way to handle this unfairness. So, your skeleton of a proposal needs a bit more thought and meat on the bone before we can actually discuss it. Where do you draw the line? How do we make sure small new entrants can still get IPv4 space in 5-10 years (because there is consensus that we want this to be possible), while still making current policy more permissive to handing smallish blocks on "needs" basis (whatever that might be). Also take into account the generally there is consensus that we don't want people to be able to use administrative loopholes in order to get themselves more IPv4 addresses for instance through multiple LIRs and other methods, at least not substantially under current market prices for IPv4 addresses. -- Mikael Abrahamsson email: swmike at swm.pp.se From springer at inlandnet.com Sat Apr 25 00:59:48 2015 From: springer at inlandnet.com (John Springer) Date: Fri, 24 Apr 2015 15:59:48 -0700 (PDT) Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> Message-ID: Hi Erik, Well stated. I also congratulate Elvis for volunteering to do this work for the community. John Springer On Thu, 23 Apr 2015, Erik Bais wrote: > Hi Milton, > >> Erik: >> Have you responded to the analysis of Vladimir Andreev which shows that > the impact of this practice is minimal? > >> From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Erik Bais >> The goal of this proposal is to stop the abuse of opening a new LIR, > transferring the /22 for profit to another LIR and close the LIR. >> As it is against the original intent of the final /8 last /22 procedure > ?(https://www.ripe.net/publications/docs/ripe-643#51 ) > > But I'll gladly reply to it .. > > His analyses goes wrong at the following line : > >> Looking at listed items I can suppose either Elvis is angry at people > earning money or really /22 reselling is bad for RIPE and its community. > > That is a false assumption and an incorrect stab in the back at Elvis, a > well known community member, who stepped up at the last RIPE meeting and > offered to write the proposal after the RIPE NCC pointed out that they have > seen an increase in this practice and are warning about this as a new > practice which is against the intent of the actual policy. > > As a broker and a community member myself, having written several policies > myself, what one might do for the community, may not always align with > someone their business processes. > I've written the policy to allow RPKI for NON-Members .. A policy to remove > the multi-homing requirement for PI IPv6 .. a policy to allow the transfer > of IPv6 prefixes .. > I think that I can safely say that it is a cheap stab in the back to even > HINT ... that personal agenda's are behind this proposal .. There is more at > stake here than a the business we do (out-side the RIPE mailing list or RIPE > meetings.. ) and the one that is paying our mortgage ... either as an ISP > or a broker. . . > > Stating that brokers are behind it ... and that getting IP's via a sign-up > of a new LIR is something that is hurting the broker business ... that is > just false. > I know most of the brokers in the community ... and I agree with Vladimir in > his analysis .. this has less than minimal impact ... ( as I see it with a > broker hat on .. ) > > The intent for the reservation from the final /8 is for new companies to > start an ISP in the next 6 to 10 years .. is why this was put into the > policy ... Because it is close to impossible to start without ANY ipv4 .. > And as a bit it more than nothing .. that is why this has been put into > policy .. Simply because you can't do any CGNAT .. if you don't have ANY > IPv4 ... This way at least you have an option .. besides building a v6 only > network. > > The fact that Vladimir points out that the policy CURRENTLY may not be > abused as much as one might think ... that does not mean that for the cases > where it is clearly abused... it didn't happen. > > I think that reading the discussion at the mailing list .. that the intent > of some of the people in this community as different as one might hope for.. > > Personally I don't care if people are going to open a new LIR for themselves > or if they are going to use the gained resources in order to sell them ... > > What I do care about is that the reason why the initial reservation was done > in the first place .. from that final /8.. with all good and noble > intentions of the proposers at that time ... has now become a cheap loophole > for some to be used for their own benefit, with the possible side-effect > that others in this very same community will be left out in the future, > because we did plan for new entries .. but didn't care enough to fix the > loopholes we noticed down the line. > > Will this proposal fix the issue to dis-allow a second /22 from the final /8 > in the same LIR ? Nope. It is still possible to get a /22 transferred into > an LIR that already holds a /22 from the final /8. > And it is will also still be possible to do a M&A of an LIR into another LIR > .. and then you will also have 2 * a /22 from the final /8 ... > > So is it perfect ? No ... > > But .. will it make the initial intent of the policy more clear ? or will it > move the policy into the right direction ? YES ... > Will this have a significant impact on slowing down the consumption rate of > the actual reserved pool in the final /8 ? Not really .. Similar as > proposing to revoke all un-routed IPv4 space back to the RIR .. and start > re-issuing it ... > That only delays the inevitable .... APNIC is out, RIPE is out ... ARIN is > down to the last .23 of their final /8 ... There is no future in IPv4 beyond > 7 years ... ( Is my humble guess.. ) > > Who knows .. the next Whatsapp or Twitter might come from that one company > that registers as an LIR in that delayed 4 weeks because of this proposal > ... > > So, to close of the argument here .. kudo's to Elvis for writing the > proposal .. I'm glad to see that it is going to be fixed, because it is the > right thing to do.. > > Please let me know if you have any additional questions. > > Regards, > Erik Bais > > > > > > > > > > > From ip at infinitytelecom.ro Sat Apr 25 12:13:45 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Sat, 25 Apr 2015 13:13:45 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> Message-ID: <465190781.20150425131345@infinitytelecom.ro> Hello John, >> The goal of this proposal is to stop the abuse of opening a new LIR, > transferring the /22 for profit to another LIR and close the LIR. How do you know that ? If i transfer to someone else or just to my old LIR ? Where its the profit ? >> Looking at listed items I can suppose either Elvis is angry at people > earning money or really /22 reselling is bad for RIPE and its community. Yes, Elvis its angry, he earn money through this, its a broker. he will be happy if everyone go to sellers instead RIPE.. > for their own benefit, with the possible side-effect > that others in this very same community will be left out in the future Oh John, but i was left.. long time ago ! You know why ? RIPE NCC should NOT let LIRs without restricted audit to get almost unlimited IPv4 resources.. just because they said "we are cute and we need more IPv4" And RIPE NCC kindly at that time offered /16 /15 /14 /13 to anyone.. I really think this was the side-effect that we all see it to day very clear. You talk about today community ? What community ? Today community its same community from 2010-2011.. with hands full with IPv4.. and here i talk about transfer list.. How its possible to ask RIPE NCC in 2010-2011 to give you bunch of /15 /16 /17 and to day.. your company not need it any more.. Very hard to understand this.. Right now i should find a why to help new LIRs or old LIRs, but truly companies not ghosts that want to make profit ! Thank you ! -- Best regards, Gabriel Voitis -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Sat Apr 25 14:42:14 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 25 Apr 2015 14:42:14 +0200 (CEST) Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <465190781.20150425131345@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> Message-ID: On Sat, 25 Apr 2015, Infinity Telecom SRL wrote: > How its possible to ask RIPE NCC in 2010-2011 to give you bunch of /15 > /16 /17 and to day.. your company not need it any more.. Some people have started putting their customer base behind NAT44(4) to shift IPv4 address usage from a customer base that will not complain too loudly to end up behind NAT44(4), to a customer base where NAT44(4) would cause a lot of problem. So this "need" is always relative. I don't know if you're trying to claim that the providers didn't need these addresses? After the investment in NAT44 has been taken (which might have involved hundreds of thousands or millions of EUR), some might discover that they actually can do without some IPv4 addresses they needed before, and thus they might put it on the market because it makes business sense. This doesn't mean they didn't need it, and these addresses can always be proven to be needed, it's just that if the market price for IPv4 addresses is high enough, then it makes sense to sell. It's like my old chairs I have in the corner, that I use occasionally. If I get enough money for them, I might sell them. Does this mean I do not need them? Well, I can prove to you that I do use them (thus I have some kind of need for them), but I can find alternatives if I get enough money. This is a grey area, not black and white. > Very hard to understand this.. > > Right now i should find a why to help new LIRs or old LIRs, but truly > companies not ghosts that want to make profit ! That's what the current policy proposal change is all about, to make sure that the business case for "start LIR, get /22, transfer /22, shut down LIR" isn't too much better than the market price for IPv4 addresses. Exactly to stop people absuing the system for profit. Yes, it's profit even if you keep it for yourself and don't sell it, because you've now lowered your cost, acquiring a resource at a lower price than you would have if you followed the intent of the policy. You seem to mix up intent of policy, and what the policy actually says. The intent has always been to assure available IPv4 space to new entrants to the market, so they can get started. So if you did the "start LIR, get /22, transfer /22, shut down LIR" then you might not have violated the policy, but you were not following the intent of why the policy is the way it is. So that's why the policy is now proposed to be changed, so that it more closely follows the intent behind it. -- Mikael Abrahamsson email: swmike at swm.pp.se From vladimir at quick-soft.net Sat Apr 25 15:22:15 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Sat, 25 Apr 2015 16:22:15 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> Message-ID: <3121571429968135@web8m.yandex.ru> I think you mix "preventing making profit" and "assure available IPv4 space to new entrants". As I calculated (and presented my results some days ago) reselling has low impact on IPv4 exhaustion. So the only reason (as I see it) is just to prevent earning money. Therefore I have reasonable question: why do some members worry about someone's profit? And PLEASE don't tell me about "abusing". As somebody said earlier in current discussion there are big IP-blocks allocated before Sep. 2012 without real need. Just because "we used all previously allocated space". Holders of such blocks are much strong "abusers". 25.04.2015, 15:42, "Mikael Abrahamsson" : > ?On Sat, 25 Apr 2015, Infinity Telecom SRL wrote: >> ??How its possible to ask RIPE NCC in 2010-2011 to give you bunch of /15 >> ??/16 /17 and to day.. your company not need it any more.. > ?Some people have started putting their customer base behind NAT44(4) to > ?shift IPv4 address usage from a customer base that will not complain too > ?loudly to end up behind NAT44(4), to a customer base where NAT44(4) would > ?cause a lot of problem. > > ?So this "need" is always relative. I don't know if you're trying to claim > ?that the providers didn't need these addresses? > > ?After the investment in NAT44 has been taken (which might have involved > ?hundreds of thousands or millions of EUR), some might discover that they > ?actually can do without some IPv4 addresses they needed before, and thus > ?they might put it on the market because it makes business sense. This > ?doesn't mean they didn't need it, and these addresses can always be proven > ?to be needed, it's just that if the market price for IPv4 addresses is > ?high enough, then it makes sense to sell. > > ?It's like my old chairs I have in the corner, that I use occasionally. If > ?I get enough money for them, I might sell them. Does this mean I do not > ?need them? Well, I can prove to you that I do use them (thus I have some > ?kind of need for them), but I can find alternatives if I get enough money. > ?This is a grey area, not black and white. >> ??Very hard to understand this.. >> >> ??Right now i should find a why to help new LIRs or old LIRs, but truly >> ??companies not ghosts that want to make profit ! > ?That's what the current policy proposal change is all about, to make sure > ?that the business case for "start LIR, get /22, transfer /22, shut down > ?LIR" isn't too much better than the market price for IPv4 addresses. > ?Exactly to stop people absuing the system for profit. > > ?Yes, it's profit even if you keep it for yourself and don't sell it, > ?because you've now lowered your cost, acquiring a resource at a lower > ?price than you would have if you followed the intent of the policy. > > ?You seem to mix up intent of policy, and what the policy actually says. > ?The intent has always been to assure available IPv4 space to new entrants > ?to the market, so they can get started. So if you did the "start LIR, get > ?/22, transfer /22, shut down LIR" then you might not have violated the > ?policy, but you were not following the intent of why the policy is the way > ?it is. So that's why the policy is now proposed to be changed, so that it > ?more closely follows the intent behind it. > > ?-- > ?Mikael Abrahamsson ???email: swmike at swm.pp.se --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From gert at space.net Sat Apr 25 15:28:25 2015 From: gert at space.net (Gert Doering) Date: Sat, 25 Apr 2015 15:28:25 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3121571429968135@web8m.yandex.ru> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> Message-ID: <20150425132825.GH54385@Space.Net> Hi, On Sat, Apr 25, 2015 at 04:22:15PM +0300, Vladimir Andreev wrote: > I think you mix "preventing making profit" and "assure available IPv4 space to new entrants". > > As I calculated (and presented my results some days ago) reselling has low impact on IPv4 exhaustion. > > So the only reason (as I see it) is just to prevent earning money. > > Therefore I have reasonable question: why do some members worry about someone's profit? Because it's a common good, and not there to further individual members' profit. Or, as your mother might have said every now and then, "just imagine what happens if everyone did this". But you can stop this discussion now. First, because it happens outside the formal process anyway, so whatever is said is not relevant for the proposal anyway. Second, because you've made your point fairly clear. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 vladimir at quick-soft.net Sat Apr 25 15:32:14 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Sat, 25 Apr 2015 16:32:14 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150425132825.GH54385@Space.Net> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> Message-ID: <3133401429968734@web8m.yandex.ru> I can't remain indifferent to such interesting proposal :) So I have to continue (no matter has it formal impact or not). 25.04.2015, 16:28, "Gert Doering" : > Hi, > > On Sat, Apr 25, 2015 at 04:22:15PM +0300, Vladimir Andreev wrote: >> ?I think you mix "preventing making profit" and "assure available IPv4 space to new entrants". >> >> ?As I calculated (and presented my results some days ago) reselling has low impact on IPv4 exhaustion. >> >> ?So the only reason (as I see it) is just to prevent earning money. >> >> ?Therefore I have reasonable question: why do some members worry about someone's profit? > > Because it's a common good, and not there to further individual members' > profit. ?Or, as your mother might have said every now and then, "just > imagine what happens if everyone did this". > > But you can stop this discussion now. > > First, because it happens outside the formal process anyway, so whatever is > said is not relevant for the proposal anyway. > > Second, because you've made your point fairly clear. > > Gert Doering > ????????-- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG ???????????????????????Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 ?????????Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen ??????????????????HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 ??????????USt-IdNr.: DE813185279 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From gert at space.net Sat Apr 25 15:44:30 2015 From: gert at space.net (Gert Doering) Date: Sat, 25 Apr 2015 15:44:30 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <3133401429968734@web8m.yandex.ru> References: <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> <3133401429968734@web8m.yandex.ru> Message-ID: <20150425134430.GI54385@Space.Net> Hi, On Sat, Apr 25, 2015 at 04:32:14PM +0300, Vladimir Andreev wrote: > I can't remain indifferent to such interesting proposal :) > > So I have to continue (no matter has it formal impact or not). No, you haven't. This is not your list, and if the chair asks you politely to stop, because everything that needed saying has been made abundantly clear, please *stop*. Repeating the same thing 10+ times is no longer "expressing an opinion", it becomes "just adding noise to the list", and after a certain point, this cannot be tolerated. Of course, new arguments are welcome. But this doesn't mean "the same argument in other words". Gert Doering -- AWPG 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 ip at infinitytelecom.ro Sat Apr 25 15:52:06 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Sat, 25 Apr 2015 16:52:06 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150425132825.GH54385@Space.Net> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> Message-ID: <1605979109.20150425165206@infinitytelecom.ro> Hello Gert, We can stop this discuss, yes. But not the RIPE NCC will be the winner here, Elvis and his guys (sellers) should start this proposal: - returned not used space. - put a tax on each IP, LIR with no used IP, will be forced to return IPs or just sell quickly at a lower price.. Thank you. -- Best regards, Gabriel Voitis -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at quick-soft.net Sat Apr 25 15:55:02 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Sat, 25 Apr 2015 16:55:02 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1605979109.20150425165206@infinitytelecom.ro> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> <1605979109.20150425165206@infinitytelecom.ro> Message-ID: <2451621429970102@web26o.yandex.ru> An HTML attachment was scrubbed... URL: From petr at fast-telecom.net Sat Apr 25 18:13:09 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sat, 25 Apr 2015 19:13:09 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations Message-ID: <126731429978389@web18g.yandex.ru> Hi everybody. Let me tell some words about current proposal. Many providers (among them is our company) need to get (e.g.) /20 subnet (not 4 x /22). If we ask the RIPE NCC to allocate 4 x /22, we can get next variants: 1. /20 2. 2 x /21 from different subnets 3. /22, /21, /22 There is only one chance to get /20 100% - make request for 7 x /22 (if the tickets will be processed together). But in this case we will have unwanted 3 x /22 which we can transfer to other LIRs to minimize our expenses. And also we can get different separate 4 x /22 (the worst case) and we have to transfer such blocks and make new request. If this proposal will be agreed, many providers (new and old) will have material losses. So I can't support this proposal. -- Kind regards, Techincal Director FastTelecom Petr Umelov From ebais at a2b-internet.com Sat Apr 25 21:34:53 2015 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Sat, 25 Apr 2015 21:34:53 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <126731429978389@web18g.yandex.ru> References: <126731429978389@web18g.yandex.ru> Message-ID: Hi Petr, Besides the fact that all discussion and input on the named policy is currently out-side the discusssion phase.. So the input can't be taken into account ... Could you provide insight in which universe the RIPE NCC is still allocating /20's ? I am aware that the IPRA's are trying to aggregate connected prefixes if possible .. Is that what you are trying to do in getting a /20 ? ... Open 4 or more lir's and issue the tickets for the IPv4 /22's at the same time in hope to get them allocated together from the same block ... So you can aggregate them after a transfer or M&A ? What you are saying here .... IS the reason why the community is looking at this policy proposal ... If you need more than a /22 the only way is to get this from the market ... I wonder why people still think that they can or will get IPv4 from the Ripe NCC ... Erik Bais > Op 25 apr. 2015 om 18:13 heeft Petr Umelov het volgende geschreven: > > Hi everybody. > > Let me tell some words about current proposal. > > Many providers (among them is our company) need to get (e.g.) /20 subnet (not 4 x /22). If we ask the RIPE NCC to allocate 4 x /22, we can get next variants: > 1. /20 > 2. 2 x /21 from different subnets > 3. /22, /21, /22 > > There is only one chance to get /20 100% - make request for 7 x /22 (if the tickets will be processed together). But in this case we will have unwanted 3 x /22 which we can transfer to other LIRs to minimize our expenses. > And also we can get different separate 4 x /22 (the worst case) and we have to transfer such blocks and make new request. > > If this proposal will be agreed, many providers (new and old) will have material losses. So I can't support this proposal. > > -- > Kind regards, > Techincal Director FastTelecom > Petr Umelov > From gert at space.net Sat Apr 25 23:07:17 2015 From: gert at space.net (Gert Doering) Date: Sat, 25 Apr 2015 23:07:17 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1605979109.20150425165206@infinitytelecom.ro> References: <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> <1605979109.20150425165206@infinitytelecom.ro> Message-ID: <20150425210717.GJ54385@Space.Net> Hi, On Sat, Apr 25, 2015 at 04:52:06PM +0300, Infinity Telecom SRL wrote: > But not the RIPE NCC will be the winner here, Elvis and his guys (sellers) should start this proposal: > > - returned not used space. > - put a tax on each IP, LIR with no used IP, will be forced to return IPs or just sell quickly at a lower price.. If you want to see a different proposal discussed, submit it to the PDP. Every member of the RIPE community is free to submit policy proposals, see https://www.ripe.net/participate/policies (Though technically, the "put a recurring price on each IP address" would not be handled by the address policy working group and the PDP, because that is something the RIPE general meeting (=members) needs to decide) 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 petr at fast-telecom.net Sun Apr 26 19:09:31 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sun, 26 Apr 2015 20:09:31 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150425210717.GJ54385@Space.Net> References: <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> <1605979109.20150425165206@infinitytelecom.ro> <20150425210717.GJ54385@Space.Net> Message-ID: <329311430068171@web6j.yandex.ru> Hello, Gert. Tell me please, how long do you plan to make the impact analysis? 26.04.2015, 00:07, "Gert Doering" : > Hi, > > On Sat, Apr 25, 2015 at 04:52:06PM +0300, Infinity Telecom SRL wrote: >> ?But not the RIPE NCC will be the winner here, Elvis and his guys (sellers) should start this proposal: >> >> ?- returned not used space. >> ?- put a tax on each IP, ?LIR with no used IP, ?will be forced to return IPs or just sell quickly at a lower price.. > > If you want to see a different proposal discussed, submit it to the PDP. > > Every member of the RIPE community is free to submit policy proposals, > see https://www.ripe.net/participate/policies > > (Though technically, the "put a recurring price on each IP address" would > not be handled by the address policy working group and the PDP, because > that is something the RIPE general meeting (=members) needs to decide) > > 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 --? Kind regards, Petr Umelov From mail at danrl.de Sun Apr 26 19:15:49 2015 From: mail at danrl.de (=?utf-8?Q?Dan_L=C3=BCdtke?=) Date: Sun, 26 Apr 2015 19:15:49 +0200 Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: <552E17BA.9060003@inex.ie> Message-ID: <0BC5075A-1118-4F2C-9080-28EC1560BADC@danrl.de> I would like to express my support for this proposal. Dan > On 15 Apr 2015, at 11:10, LIR (BIT I 5) wrote: > > I also would support this proposal. > Regards > Carsten > > > -----Urspr?ngliche Nachricht----- > Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Nick Hilliard > Gesendet: Mittwoch, 15. April 2015 09:48 > An: address-policy-wg at ripe.net > Betreff: Re: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) > > Looks good to me. Support. > > Nick > > On 14/04/2015 14:52, Marco Schmidt wrote: >> Dear colleagues, >> >> A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" >> is now available for discussion. >> >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2015-02 >> >> We encourage you to review this proposal and send your comments to >> before 13 May 2015. >> >> Regards >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> > > From gert at space.net Sun Apr 26 21:12:01 2015 From: gert at space.net (Gert Doering) Date: Sun, 26 Apr 2015 21:12:01 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <329311430068171@web6j.yandex.ru> References: <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> <1605979109.20150425165206@infinitytelecom.ro> <20150425210717.GJ54385@Space.Net> <329311430068171@web6j.yandex.ru> Message-ID: <20150426191201.GQ54385@Space.Net> Hi, On Sun, Apr 26, 2015 at 08:09:31PM +0300, Petr Umelov wrote: > Tell me please, how long do you plan to make the impact analysis? I don't do anything here, the IA is done by the RIPE NCC. Marco said he hopes to have it ready before the RIPE meeting, so we can have a good (and informed!) discussion there. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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 ripe-wgs at radu-adrian.feurdean.net Sun Apr 26 22:54:08 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sun, 26 Apr 2015 22:54:08 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150425210717.GJ54385@Space.Net> References: <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> <1605979109.20150425165206@infinitytelecom.ro> <20150425210717.GJ54385@Space.Net> Message-ID: <1430081648.1263274.258826193.3BC69F3E@webmail.messagingengine.com> On Sat, Apr 25, 2015, at 23:07, Gert Doering wrote: > (Though technically, the "put a recurring price on each IP address" would > not be handled by the address policy working group and the PDP, because > that is something the RIPE general meeting (=members) needs to decide) ... And rejected a few times in different forms. Not to mention NCC's desire to avoid explicit "price per IP" for (non-)tax reasons. From elvis at v4escrow.net Mon Apr 27 10:29:58 2015 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 27 Apr 2015 01:29:58 -0700 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150426191201.GQ54385@Space.Net> References: <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> <1605979109.20150425165206@infinitytelecom.ro> <20150425210717.GJ54385@Space.Net> <329311430068171@web6j.yandex.ru> <20150426191201.GQ54385@Space.Net> Message-ID: <553DF386.9000506@v4escrow.net> Hello everyone, in a previous message I did say that I expected to see a few flying tomatoes towards me, just because I am a broker of IP addresses when coming up with this proposal. However, the low level of personal attacks I have seen on this mailing list in the past few weeks have made me wonder how pathetic some people can actually be... I would like to thank everyone that defended me on the mailing list, people that do understand why I have sent in this policy proposal, people that know me since I first joined this community more than 10 years ago. I would also like to thank the chairs for stepping in to stop the pathetic attacks to my person and to my business. Because some have questioned why I have sent in this request, I would like to clarify some things: 1. IPv4 Brokers do not make their money from the /22s they broker. Actually, we sometimes broker /22s (or smaller prefixes) even if we lose money just to help a customer. We normally make a commission from the total transaction price and brokering anything below a /21 means (most of the times) working for free or for a loss. My business has nothing to do with this policy proposal. Actually, if I would care for my business and for making a profit from anything, I should oppose to such a proposal. This policy proposal has been sent because for more than 7 years I have worked at the RIPE NCC and they have injected me with some kind of serum that 'forces' me to do good deeds for the community and for the well being of the Internet :-) 2. This policy proposal has been made after the lengthy discussion at the RIPE Meeting in London and after noticing that the RIPE NCC keeps presenting to the AP-WG that the 'last /8 policy' is being abused by a handful of people. In a previous message I have already pointed to the recordings of those discussions and Andrea's presentation. 3. This policy proposal does not attempt to fix the 'bug' that allows a company/person to open multiple LIRs and receive multiple /22s (by way of merger). This bug exists and is well know. It was even mentioned in the rationale and the impact analysis of '2010-02 - the last /8 policy proposal' [1]. 4. This policy proposal attempts to fix the problem raised by the RIPE NCC where a company/person opens an LIR, receives a /22, transfers the /22 and restarts the process, thus requesting the /22 with the only purpose to 'transfer' it. The usage of the /22s should be restricted - as the 'last /8 policy proposal aimed' - to the companies that need a bit of IP addresses to operate in a 'still predominant' IPv4 world. I have seen cases where the /22 from the last /8 has been received and transferred in the same day. This 'business style' not only violates the RIPE Policies and the spirit of the 'last /8 policy proposal' [1] but also shows that some only want to make money by abusing the system. This must stop and that is why this policy proposal was sent in. 5. I am upset to see that a co-national (mr Gabriel Voitis from Infinity Telecom) has decided to publicly attack me on this mailing list and I have decided to basically ignore all of his messages, I will not respond to his pathetic attacks. I believe that a company founded in 2011 (with 0 employees since) should just be ignored. Actually, I would like to ask the Chair of the WG to request the removal of Mr Gabriel Voitis (or anyone else that lowers himself at that level) from the mailing list if he continues with his personal attacks towards me or towards my business. 6. I am also awaiting Marco's Impact Analysis to discuss this policy proposal further. This will be my last message before the Impact Analysis is published. 7. Lastly, I welcome the discussion about the size of the allocation from the last /8. I have actually asked Gert to give us a few minutes during the AP-WG meeting in Amsterdam to discuss further. Radu, I will try to get in contact with you as I like most of the ideas you have sent to this mailing list and maybe we can come up with a nice presentation for RIPE70. Kind regards, Elvis [1] https://www.ripe.net/participate/policies/proposals/2010-02 -- 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 petr at fast-telecom.net Mon Apr 27 11:11:56 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Mon, 27 Apr 2015 12:11:56 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <553DF386.9000506@v4escrow.net> References: <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> <1605979109.20150425165206@infinitytelecom.ro> <20150425210717.GJ54385@Space.Net> <329311430068171@web6j.yandex.ru> <20150426191201.GQ54385@Space.Net> <553DF386.9000506@v4escrow.net> Message-ID: <1002571430125916@web2h.yandex.ru> Hi, everybody. As we see some people decided to ignore others who want to tell their opposition opinion and welcome those, who agree. I thought the RIPE NCC is community, expressing all people position. But I was wrong. Could you explain how do resellers abuse the system? Why don't you return unused allocations, which are more than all /8? You may ask to delete me from this mail list, but it will confirm my words. 27.04.2015, 11:31, "Elvis Daniel Velea" : > Hello everyone, > > in a previous message I did say that I expected to see a few flying tomatoes towards me, just because I am a broker of IP addresses when coming up with this proposal. > However, the low level of personal attacks I have seen on this mailing list in the past few weeks have made me wonder how pathetic some people can actually be... > > I would like to thank everyone that defended me on the mailing list, people that do understand why I have sent in this policy proposal, people that know me since I first joined this community more than 10 years ago. I would also like to thank the chairs for stepping in to stop the pathetic attacks to my person and to my business. > > Because some have questioned why I have sent in this request, I would like to clarify some things: > > 1. IPv4 Brokers do not make their money from the /22s they broker. Actually, we sometimes broker /22s (or smaller prefixes) even if we lose money just to help a customer. We normally make a commission from the total transaction price and brokering anything below a /21 means (most of the times) working for free or for a loss. My business has nothing to do with this policy proposal. Actually, if I would care for my business and for making a profit from anything, I should oppose to such a proposal. This policy proposal has been sent because for more than 7 years I have worked at the RIPE NCC and they have injected me with some kind of serum that 'forces' me to do good deeds for the community and for the well being of the Internet :-) > > 2. This policy proposal has been made after the lengthy discussion at the RIPE Meeting in London and after noticing that the RIPE NCC keeps presenting to the AP-WG that the 'last /8 policy' is being abused by a handful of people. In a previous message I have already pointed to the recordings of those discussions and Andrea's presentation. > > 3. This policy proposal does not attempt to fix the 'bug' that allows a company/person to open multiple LIRs and receive multiple /22s (by way of merger). This bug exists and is well know. It was even mentioned in the rationale and the impact analysis of '2010-02 - the last /8 policy proposal' [1]. > > 4. This policy proposal attempts to fix the problem raised by the RIPE NCC where a company/person opens an LIR, receives a /22, transfers the /22 and restarts the process, thus requesting the /22 with the only purpose to 'transfer' it. The usage of the /22s should be restricted - as the 'last /8 policy proposal aimed' - to the companies that need a bit of IP addresses to operate in a 'still predominant' IPv4 world. I have seen cases where the /22 from the last /8 has been received and transferred in the same day. This 'business style' not only violates the RIPE Policies and the spirit of the 'last /8 policy proposal' [1] but also shows that some only want to make money by abusing the system. This must stop and that is why this policy proposal was sent in. > > 5. I am upset to see that a co-national (mr Gabriel Voitis from Infinity Telecom) has decided to publicly attack me on this mailing list and I have decided to basically ignore all of his messages, I will not respond to his pathetic attacks. I believe that a company founded in 2011 (with 0 employees since) should just be ignored. Actually, I would like to ask the Chair of the WG to request the removal of Mr Gabriel Voitis (or anyone else that lowers himself at that level) from the mailing list if he continues with his personal attacks towards me or towards my business. > > 6. I am also awaiting Marco's Impact Analysis to discuss this policy proposal further. This will be my last message before the Impact Analysis is published. > > 7. Lastly, I welcome the discussion about the size of the allocation from the last /8. I have actually asked Gert to give us a few minutes during the AP-WG meeting in Amsterdam to discuss further. Radu, I will try to get in contact with you as I like most of the ideas you have sent to this mailing list and maybe we can come up with a nice presentation for RIPE70. > > Kind regards, > Elvis > > [1] https://www.ripe.net/participate/policies/proposals/2010-02 > > -- > > 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. --? Kind regards, Petr Umelov From apwg at c4inet.net Mon Apr 27 11:13:45 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 27 Apr 2015 10:13:45 +0100 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> Message-ID: <20150427091345.GB35191@cilantro.c4inet.net> On Thu, Apr 23, 2015 at 01:34:43PM +0200, Erik Bais wrote: >This policy is not keep people from opening a new LIR .. it is to keep >people from opening a new LIR and transfer the IP range for profit to >someone else and shutdown the LIR within the first year... In all the recent 'upheaval' it may have escaped notice that the proposal *still* does not address the non-speculative case of a LIR being bought / merged before the 24 month holding period expires. rgds, Sascha Luck From gert at space.net Mon Apr 27 11:26:38 2015 From: gert at space.net (Gert Doering) Date: Mon, 27 Apr 2015 11:26:38 +0200 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1002571430125916@web2h.yandex.ru> References: <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> <1605979109.20150425165206@infinitytelecom.ro> <20150425210717.GJ54385@Space.Net> <329311430068171@web6j.yandex.ru> <20150426191201.GQ54385@Space.Net> <553DF386.9000506@v4escrow.net> <1002571430125916@web2h.yandex.ru> Message-ID: <20150427092638.GY54385@Space.Net> Hi, On Mon, Apr 27, 2015 at 12:11:56PM +0300, Petr Umelov wrote: > As we see some people decided to ignore others who want to tell their opposition opinion and welcome those, who agree. I thought the RIPE NCC is community, expressing all people position. But I was wrong. In general, we don't ignore voices opposing a proposal. In this particular case, when we aim to make particular behaviour more uninteresting, it is expected that people that make a profit from this particular behaviour will not like the change - we do hear the arguments, but "I want to keep doing what the rest of the community considers abusive, because I make a profit from it!" is not a very strong argument here. If everyone else would just shrug their shoulders and say "well, we don't care", such opposition would be sufficient - but if there are strong voices in favour of going ahead, the WG chairs needs to make a judgement - and we will, at the end of the review phase, and explain to the group why we decided. 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 mueller at syr.edu Mon Apr 27 16:59:31 2015 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 27 Apr 2015 14:59:31 +0000 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <743864634.20150423144119@infinitytelecom.ro> <015101d07dbc$7d127670$77376350$@a2b-internet.com> <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> Message-ID: I asked: > > Erik: > Have you responded to the analysis of Vladimir Andreev which > shows that the impact of this practice is minimal? You replied: > I know most of the brokers in the community ... and I agree with > Vladimir in his analysis .. this has less than minimal impact ... ( as I see it > with a broker hat on .. ) But you added: > The fact that Vladimir points out that the policy CURRENTLY may not be > abused as much as one might think ... that does not mean that for the > cases where it is clearly abused... it didn't happen. OK, no one questions whether it happened. I guess follow-up questions would be: - if this proposal does not pass, do you think this loophole will be used more frequently in the future? To the point where it materially impacts the intent of the policy to reserve IPv4s for startups? In other words, is the current loophole user a pioneer who might start a land rush, or a minor unintended side effect? - Might this loophole actually benefit some small startups who quickly discover they need more than a /22? - Will the addition of a new restriction create enforcement issues or other unforeseen complications for companies using the policy? I think the proposed policy does clarify and enforce the original intent of the final /8 policy, and I don't really oppose it. I am just trying to keep things evidence based and in the proper perspective. I think the drama surrounding this is a bit over the top. From mueller at syr.edu Mon Apr 27 17:02:17 2015 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 27 Apr 2015 15:02:17 +0000 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <20150427091345.GB35191@cilantro.c4inet.net> References: <1579994104.20150423131841@infinitytelecom.ro> <011d01d07db9$83f6b670$8be42350$@a2b-internet.com> <20150427091345.GB35191@cilantro.c4inet.net> Message-ID: This is a good example of a potential bad side effect of the policy > -----Original Message----- > In all the recent 'upheaval' it may have escaped notice that the > proposal *still* does not address the non-speculative case of a LIR > being bought / merged before the 24 month holding period expires. > > rgds, > Sascha Luck > From ip at infinitytelecom.ro Tue Apr 28 02:12:41 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Tue, 28 Apr 2015 03:12:41 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1002571430125916@web2h.yandex.ru> References: <93adac05882046f09e903dde75bc021f@EX13-MBX-13.ad.syr.edu> <02ce01d07de3$3b557990$b2006cb0$@a2b-internet.com> <465190781.20150425131345@infinitytelecom.ro> <3121571429968135@web8m.yandex.ru> <20150425132825.GH54385@Space.Net> <1605979109.20150425165206@infinitytelecom.ro> <20150425210717.GJ54385@Space.Net> <329311430068171@web6j.yandex.ru> <20150426191201.GQ54385@Space.Net> <553DF386.9000506@v4escrow.net> <1002571430125916@web2h.yandex.ru> Message-ID: <914553914.20150428031241@infinitytelecom.ro> Hello, This is the question: "Could any of you have your company survive with only a /22 (and 10-15 $/IP extra, 256/512/1024 packs towards 15$/IP) ? " I am sorry if i upset Elvis or someone else ! I will come in person at next meeting to expres my point of view.. Thank you. -- Best regards, Gabriel Voitis -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuenzler at init7.net Tue Apr 28 05:09:26 2015 From: kuenzler at init7.net (Fredy Kuenzler) Date: Tue, 28 Apr 2015 05:09:26 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: Message-ID: <553EF9E6.8020907@init7.net> All, as we are doing a daily diff of ftp://ftp.ripe.net/ripe/stats/membership/alloclist.txt we observed that something happens right now which was probably not forseen and not inteded by the policy. I thought to make the working group aware. Regards, Fredy / Init7 -------- Weitergeleitete Nachricht -------- Betreff: [allocdelta] New or removed allocations Datum: Tue, 28 Apr 2015 05:00:36 +0200 Von: allocdelta at init7.net * ru.ibulavkin25 Bulavkin Ivan Aleksandrovitch [ADD] 20150224 185.89.104.0/22 ALLOCATED PA [ADD] 20150217 2a03:7f60::/32 * ru.ibulavkin26 Bulavkin Ivan Aleksandrovitch [ADD] 20150217 185.88.96.0/22 ALLOCATED PA [ADD] 20150216 2a03:7da0::/32 * ru.ibulavkin29 Bulavkin Ivan Aleksandrovitch [ADD] 20150409 185.95.100.0/22 ALLOCATED PA * ru.ibulavkin33 Bulavkin Ivan Aleksandrovitch [ADD] 20150422 185.97.76.0/22 ALLOCATED PA * ru.ibulavkin35 Bulavkin Ivan Aleksandrovitch [ADD] 20150414 185.95.228.0/22 ALLOCATED PA * ru.srv2013 Bulavkin Ivan Aleksandrovitch [ADD] 20140930 185.71.144.0/22 ALLOCATED PA [ADD] 20141119 185.77.136.0/22 ALLOCATED PA [ADD] 20141121 185.78.76.0/22 ALLOCATED PA [ADD] 20141031 185.75.132.0/22 ALLOCATED PA [ADD] 20141020 185.73.180.0/22 ALLOCATED PA [ADD] 20141020 185.73.216.0/22 ALLOCATED PA [ADD] 20130626 185.29.124.0/22 ALLOCATED PA [ADD] 20141217 185.81.172.0/22 ALLOCATED PA [ADD] 20130527 2a00:90a0::/32 [ADD] 20141216 185.81.144.0/22 ALLOCATED PA [ADD] 20141001 185.71.212.0/22 ALLOCATED PA [ADD] 20141113 185.76.240.0/22 ALLOCATED PA [ADD] 20141120 185.77.216.0/22 ALLOCATED PA [ADD] 20140624 185.61.220.0/22 ALLOCATED PA [ADD] 20140903 185.68.244.0/22 ALLOCATED PA [ADD] 20141217 185.81.184.0/22 ALLOCATED PA [ADD] 20140604 185.59.232.0/22 ALLOCATED PA [ADD] 20141201 185.79.132.0/22 ALLOCATED PA [ADD] 20140521 185.58.112.0/22 ALLOCATED PA [ADD] 20141128 185.79.76.0/22 ALLOCATED PA [ADD] 20141201 185.79.136.0/22 ALLOCATED PA [ADD] 20140624 185.61.216.0/22 ALLOCATED PA [ADD] 20140829 185.68.184.0/22 ALLOCATED PA [ADD] 20141216 185.24.108.0/22 ALLOCATED PA [ADD] 20141128 185.79.48.0/22 ALLOCATED PA [ADD] 20141120 185.77.220.0/22 ALLOCATED PA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ip at infinitytelecom.ro Tue Apr 28 07:13:21 2015 From: ip at infinitytelecom.ro (Infinity Telecom SRL) Date: Tue, 28 Apr 2015 08:13:21 +0300 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <553EF9E6.8020907@init7.net> References: <553EF9E6.8020907@init7.net> Message-ID: <1146891946.20150428081321@infinitytelecom.ro> Hello Fredy, Personally i dont understand this list, can you explain more ? Thank you. -- Best regards, Gabriel Voitis -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Tue Apr 28 07:25:16 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 28 Apr 2015 07:25:16 +0200 (CEST) Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <1146891946.20150428081321@infinitytelecom.ro> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> Message-ID: On Tue, 28 Apr 2015, Infinity Telecom SRL wrote: > Hello Fredy, > > > Personally i dont understand this list, can you explain more ? The person is starting a lot of LIRs and getting a /22 for each LIR, and then transfering the /22:s to ru.srv2013 LIR. Exactly the kind of behaviour the new proposal that you're objecting to, is trying to make more costly and thus less attractive. -- Mikael Abrahamsson email: swmike at swm.pp.se From tom at kebab.org.pl Tue Apr 28 07:29:47 2015 From: tom at kebab.org.pl (-TOM-) Date: Tue, 28 Apr 2015 07:29:47 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <1146891946.20150428081321@infinitytelecom.ro> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> Message-ID: <553F1ACB.6090201@kebab.org.pl> This means, thatdealings with opening multiple LIR's, get their /22 allocation and merge this 'new lir's' with other 'host lir' is now in progress at full throttle :( Best regards Tomasz ?l?ski W dniu 2015-04-28 o 07:13, Infinity Telecom SRL pisze: > Re: [address-policy-wg] Hoarding /22 out of 185/8 Hello Fredy, > > > Personally i dont understand this list, can you explain more ? > > Thank you. > > > /-- > Best regards, > Gabriel Voitis / From frettled at gmail.com Tue Apr 28 07:28:58 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 28 Apr 2015 07:28:58 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <1146891946.20150428081321@infinitytelecom.ro> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> Message-ID: On Tue, Apr 28, 2015 at 7:13 AM, Infinity Telecom SRL wrote: > Hello Fredy, > > > Personally i dont understand this list, can you explain more ? > As I understand it, his concern is that an organization with the same contact person, "Bulavkin Ivan Aleksandrovitch", got allocated 30ish /22 nets, nearly a /17, or around 2? (0.2%) of 185/8. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Tue Apr 28 07:52:34 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 28 Apr 2015 07:52:34 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <553F1ACB.6090201@kebab.org.pl> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> Message-ID: <20150428075234.16d44154@echo.ms.redpill-linpro.com> * -TOM- > This means, thatdealings with opening multiple LIR's, get their /22 > allocation and merge this 'new lir's' with other 'host lir' is now in > progress at full throttle :( Indeed, this person appears to be using the LIR merger procedure, *not* the transfer procedure, to gather the /22s in his main LIR. At least I could not find any of the blocks in question mentioned on . That in turn means that 2015-01 will have no preventive effect at all. Tore From petr at fast-telecom.net Sat Apr 25 17:55:59 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sat, 25 Apr 2015 18:55:59 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations Message-ID: <102641429977359@web18g.yandex.ru> Hi everybody. Let me tell some words about current proposal. Many providers (among them is our company) need to get (e.g.) /20 subnet (not 4 x /22). If we ask the RIPE NCC to allocate 4 x /22, we can get next variants: 1. /20 2. 2 x /21 from different subnets 3. /22, /21, /22 There is only one chance to get /20 100% - make request for 7 x /22 (if the tickets will be processed together). But in this case we will have unwanted 3 x /22 which we can transfer to other LIRs to minimize our expenses. And also we can get different separate 4 x /22 (the worst case) and we have to transfer such blocks and make new request. If this proposal will be agreed, many providers (new and old) will have material losses. So I can't support this proposal. --? Kind regards, Techincal Director FastTelecom Petr Umelov From petr at fast-telecom.net Sat Apr 25 18:05:09 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sat, 25 Apr 2015 19:05:09 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations Message-ID: <115191429977909@web18g.yandex.ru> Hi everybody. Let me tell some words about current proposal. Many providers (among them is our company) need to get (e.g.) /20 subnet (not 4 x /22). If we ask the RIPE NCC to allocate 4 x /22, we can get next variants: 1. /20 2. 2 x /21 from different subnets 3. /22, /21, /22 There is only one chance to get /20 100% - make request for 7 x /22 (if the tickets will be processed together). But in this case we will have unwanted 3 x /22 which we can transfer to other LIRs to minimize our expenses. And also we can get different separate 4 x /22 (the worst case) and we have to transfer such blocks and make new request. If this proposal will be agreed, many providers (new and old) will have material losses. So I can't support this proposal. -- Kind regards, Techincal Director FastTelecom Petr Umelov From cfriacas at fccn.pt Tue Apr 28 08:13:14 2015 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 28 Apr 2015 07:13:14 +0100 (WEST) Subject: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: Support. +1 Regards, Carlos Fria?as On Tue, 14 Apr 2015, Marco Schmidt wrote: > > Dear colleagues, > > A proposed change to RIPE Document "IPv6 Address Allocation and Assignment Policy" > is now available for discussion. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-02 > > We encourage you to review this proposal and send your comments to > before 13 May 2015. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > From cfriacas at fccn.pt Tue Apr 28 08:24:20 2015 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 28 Apr 2015 07:24:20 +0100 (WEST) Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <102641429977359@web18g.yandex.ru> References: <102641429977359@web18g.yandex.ru> Message-ID: Hello, Noone (in the RIPE/NCC service region) is able to get more than a /22, according to current policies, or did i miss something? If someone is asking (and actually getting) more than a /22, those allocations need to be revoked -- i honestly thought current policy already included that... Regards, Carlos On Sat, 25 Apr 2015, Petr Umelov wrote: > Hi everybody. > > Let me tell some words about current proposal. > > Many providers (among them is our company) need to get (e.g.) /20 subnet (not 4 x /22). If we ask the RIPE NCC to allocate 4 x /22, we can get next variants: > 1. /20 > 2. 2 x /21 from different subnets > 3. /22, /21, /22 > > There is only one chance to get /20 100% - make request for 7 x /22 (if the tickets will be processed together). But in this case we will have unwanted 3 x /22 which we can transfer to other LIRs to minimize our expenses. > And also we can get different separate 4 x /22 (the worst case) and we have to transfer such blocks and make new request. > > If this proposal will be agreed, many providers (new and old) will have material losses. So I can't support this proposal. > > --? > Kind regards, > Techincal Director FastTelecom > Petr Umelov > From ggiannou at gmail.com Tue Apr 28 08:27:11 2015 From: ggiannou at gmail.com (George Giannousopoulos) Date: Tue, 28 Apr 2015 09:27:11 +0300 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> Message-ID: The main issue here isn't the amount of IPs someone got by abusing the policy. Sure the 2? (0.2%) of 185/8 is negligible, but what would happen if we all did the same? Do you think you are the only ones needing IPs and you are the only ones who worry about their company survival? On the other side, there a people who try to deploy IPv6 and try to overcome the IPv4 exhaustion. This is the way you should also move forward, instead of trying to get more "cheap" IPv4. Remember that for every single /22 you get by abusing the policy, you prohibit a new company to start business in the near future, since the required /22 won't be available any more. Apparently the proposal can't solve all the issues and can't block all kinds of abuse, but I believe it's in the right direction. George On Tue, Apr 28, 2015 at 8:28 AM, Jan Ingvoldstad wrote: > On Tue, Apr 28, 2015 at 7:13 AM, Infinity Telecom SRL < > ip at infinitytelecom.ro> wrote: > >> Hello Fredy, >> >> >> Personally i dont understand this list, can you explain more ? >> > > As I understand it, his concern is that an organization with the same > contact person, "Bulavkin Ivan Aleksandrovitch", got allocated 30ish /22 > nets, nearly a /17, or around 2? (0.2%) of 185/8. > -- > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at quick-soft.net Tue Apr 28 08:28:58 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Tue, 28 Apr 2015 09:28:58 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <102641429977359@web18g.yandex.ru> Message-ID: <1815941430202538@web20h.yandex.ru> Hello! Petr means opening multiple LIR's and requesting /22's for all these LIR's at once. if you are lucky RIPE NCC will process you requests one after another and allocate you adjacent range of IP's. 28.04.2015, 09:24, "Carlos Friacas" : > Hello, > > Noone (in the RIPE/NCC service region) is able to get more than a /22, > according to current policies, or did i miss something? > > If someone is asking (and actually getting) more than a /22, those > allocations need to be revoked -- i honestly thought current policy > already included that... > > Regards, > Carlos > > On Sat, 25 Apr 2015, Petr Umelov wrote: >> ?Hi everybody. >> >> ?Let me tell some words about current proposal. >> >> ?Many providers (among them is our company) need to get (e.g.) /20 subnet (not 4 x /22). If we ask the RIPE NCC to allocate 4 x /22, we can get next variants: >> ?1. /20 >> ?2. 2 x /21 from different subnets >> ?3. /22, /21, /22 >> >> ?There is only one chance to get /20 100% - make request for 7 x /22 (if the tickets will be processed together). But in this case we will have unwanted 3 x /22 which we can transfer to other LIRs to minimize our expenses. >> ?And also we can get different separate 4 x /22 (the worst case) and we have to transfer such blocks and make new request. >> >> ?If this proposal will be agreed, many providers (new and old) will have material losses. So I can't support this proposal. >> >> ?-- >> ?Kind regards, >> ?Techincal Director FastTelecom >> ?Petr Umelov --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From cfriacas at fccn.pt Tue Apr 28 08:33:13 2015 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 28 Apr 2015 07:33:13 +0100 (WEST) Subject: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: References: Message-ID: Support. +1. I've read the "Arguments opposing the proposal", and i don't believe fragmentation will significantly increase as a result of this policy. Anyway some people already fragment more than they should... :-) Regards, Carlos On Mon, 9 Mar 2015, Marco Schmidt wrote: > > Dear colleagues, > > > The Review Period for the proposal 2014-03, "Remove Multihoming Requirement for > AS Number Assignments" has been extended until 19 May 2015. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-03 > > > We encourage you to review this policy proposal and send your comments > to . > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > From cfriacas at fccn.pt Tue Apr 28 08:42:41 2015 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 28 Apr 2015 07:42:41 +0100 (WEST) Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1815941430202538@web20h.yandex.ru> References: <102641429977359@web18g.yandex.ru> <1815941430202538@web20h.yandex.ru> Message-ID: On Tue, 28 Apr 2015, Vladimir Andreev wrote: > Hello! Greetings, > Petr means opening multiple LIR's and requesting /22's for all these LIR's at once. "Opening multiple LIR's" == workaround, as in "a way to cheat the system". > if you are lucky RIPE NCC will process you requests one after another and allocate you adjacent range of IP's. It shouldn't be a matter of luck... As you say "allocate you", that implies ONE organization. And ONE organization should only get ONE /22... ;-) Regards, Carlos > 28.04.2015, 09:24, "Carlos Friacas" : >> Hello, >> >> Noone (in the RIPE/NCC service region) is able to get more than a /22, >> according to current policies, or did i miss something? >> >> If someone is asking (and actually getting) more than a /22, those >> allocations need to be revoked -- i honestly thought current policy >> already included that... >> >> Regards, >> Carlos >> >> On Sat, 25 Apr 2015, Petr Umelov wrote: >>> ?Hi everybody. >>> >>> ?Let me tell some words about current proposal. >>> >>> ?Many providers (among them is our company) need to get (e.g.) /20 subnet (not 4 x /22). If we ask the RIPE NCC to allocate 4 x /22, we can get next variants: >>> ?1. /20 >>> ?2. 2 x /21 from different subnets >>> ?3. /22, /21, /22 >>> >>> ?There is only one chance to get /20 100% - make request for 7 x /22 (if the tickets will be processed together). But in this case we will have unwanted 3 x /22 which we can transfer to other LIRs to minimize our expenses. >>> ?And also we can get different separate 4 x /22 (the worst case) and we have to transfer such blocks and make new request. >>> >>> ?If this proposal will be agreed, many providers (new and old) will have material losses. So I can't support this proposal. >>> >>> ?-- >>> ?Kind regards, >>> ?Techincal Director FastTelecom >>> ?Petr Umelov > > --? > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 > From swmike at swm.pp.se Tue Apr 28 08:46:43 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 28 Apr 2015 08:46:43 +0200 (CEST) Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <20150428075234.16d44154@echo.ms.redpill-linpro.com> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> Message-ID: On Tue, 28 Apr 2015, Tore Anderson wrote: > * -TOM- > >> This means, thatdealings with opening multiple LIR's, get their /22 >> allocation and merge this 'new lir's' with other 'host lir' is now in >> progress at full throttle :( > > Indeed, this person appears to be using the LIR merger procedure, *not* > the transfer procedure, to gather the /22s in his main LIR. At least I > could not find any of the blocks in question mentioned on > . > > That in turn means that 2015-01 will have no preventive effect at all. But 2015-01 at least says you need to keep the LIR open for 24 months, correct, meaning you have to pay the yearly LIR fee 3 times (one initial and 2 recurring). At least that was my understanding of the proposal. At least the above is what I would like to achieve. -- Mikael Abrahamsson email: swmike at swm.pp.se From vladimir at quick-soft.net Tue Apr 28 08:51:02 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Tue, 28 Apr 2015 09:51:02 +0300 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <102641429977359@web18g.yandex.ru> <1815941430202538@web20h.yandex.ru> Message-ID: <1940291430203862@web20h.yandex.ru> I already expressed my opinion about multiple LIR's in details in previous letters. "Allocate you" means "you" as contact person. You are not required to have only one organisation. You can open some amount of legal person and then open LIR's for each. After that request /22's for your LIR's as mentioned earlier. 28.04.2015, 09:42, "Carlos Friacas" : > ?On Tue, 28 Apr 2015, Vladimir Andreev wrote: >> ??Hello! > ?Greetings, >> ??Petr means opening multiple LIR's and requesting /22's for all these LIR's at once. > ?"Opening multiple LIR's" == workaround, as in "a way to cheat the system". >> ??if you are lucky RIPE NCC will process you requests one after another and allocate you adjacent range of IP's. > ?It shouldn't be a matter of luck... > > ?As you say "allocate you", that implies ONE organization. > ?And ONE organization should only get ONE /22... ;-) > > ?Regards, > ?Carlos >> ??28.04.2015, 09:24, "Carlos Friacas" : >>> ??Hello, >>> >>> ??Noone (in the RIPE/NCC service region) is able to get more than a /22, >>> ??according to current policies, or did i miss something? >>> >>> ??If someone is asking (and actually getting) more than a /22, those >>> ??allocations need to be revoked -- i honestly thought current policy >>> ??already included that... >>> >>> ??Regards, >>> ??Carlos >>> >>> ??On Sat, 25 Apr 2015, Petr Umelov wrote: >>>> ???Hi everybody. >>>> >>>> ???Let me tell some words about current proposal. >>>> >>>> ???Many providers (among them is our company) need to get (e.g.) /20 subnet (not 4 x /22). If we ask the RIPE NCC to allocate 4 x /22, we can get next variants: >>>> ???1. /20 >>>> ???2. 2 x /21 from different subnets >>>> ???3. /22, /21, /22 >>>> >>>> ???There is only one chance to get /20 100% - make request for 7 x /22 (if the tickets will be processed together). But in this case we will have unwanted 3 x /22 which we can transfer to other LIRs to minimize our expenses. >>>> ???And also we can get different separate 4 x /22 (the worst case) and we have to transfer such blocks and make new request. >>>> >>>> ???If this proposal will be agreed, many providers (new and old) will have material losses. So I can't support this proposal. >>>> >>>> ???-- >>>> ???Kind regards, >>>> ???Techincal Director FastTelecom >>>> ???Petr Umelov >> ??-- >> ??With best regards, Vladimir Andreev >> ??General director, QuickSoft LLC >> ??Tel: +7 903 1750503 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From tore at fud.no Tue Apr 28 09:05:55 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 28 Apr 2015 09:05:55 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> Message-ID: <20150428090555.4f8db6b6@echo.ms.redpill-linpro.com> * Mikael Abrahamsson > But 2015-01 at least says you need to keep the LIR open for 24 months, > correct, meaning you have to pay the yearly LIR fee 3 times (one initial > and 2 recurring). At least that was my understanding of the proposal. Yes, but it only does this for "normal" transfers per ripe-643 section 5.5. It does not change anything for ?Mergers and Acquisitions?, because that's not regulated in policy, it is an operational procedure made by the RIPE NCC. https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/mergers-and-acquisitions Since the blocks Fredy posted are gathered in a single LIR, yet absent from the table of published transfers, I can only surmise that the person in question is using the M&A procedure to accomplish his goals and not ripe-643 section 5.5 one. > At least the above is what I would like to achieve. 2015-01 unfortunately falls short of the mark, but I don't know it could be fixed since the M&A procedure isn't policy and thus out of scope for the APWG (as I understand it anyway). I'm hoping that the NCC's IA will point out that the M&A loophole remains and maybe advise on how we might go about closing it. Tore From raymond.jetten at elisa.fi Tue Apr 28 09:09:45 2015 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Tue, 28 Apr 2015 07:09:45 +0000 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1940291430203862@web20h.yandex.ru> References: <102641429977359@web18g.yandex.ru> <1815941430202538@web20h.yandex.ru> <1940291430203862@web20h.yandex.ru> Message-ID: <4047358bd352420babd4ec071216c4a0@SEMC001.acc.master.epnet> Hello All, This discussion is not solving its self or going anywhere. It's time to stop. The only thing it does at the moment is showing and explaining people publically how to cheat / mislead / misuse resources. Is anyone else interested in how to break which rule "because we can" Breaking laws or rules is perhaps considered a cool thing to do in some people's minds? The majority has a different opinion. My point or question? What will the RIPE NCC do with cases that can be proven to be abusive? Rgds, Ray. -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Vladimir Andreev Sent: 28. huhtikuuta 2015 9:51 To: Carlos Friacas Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Transfer Requirements for IPv4 Allocations I already expressed my opinion about multiple LIR's in details in previous letters. "Allocate you" means "you" as contact person. You are not required to have only one organisation. You can open some amount of legal person and then open LIR's for each. After that request /22's for your LIR's as mentioned earlier. 28.04.2015, 09:42, "Carlos Friacas" : > ?On Tue, 28 Apr 2015, Vladimir Andreev wrote: >> ??Hello! > ?Greetings, >> ??Petr means opening multiple LIR's and requesting /22's for all these LIR's at once. > ?"Opening multiple LIR's" == workaround, as in "a way to cheat the system". >> ??if you are lucky RIPE NCC will process you requests one after another and allocate you adjacent range of IP's. > ?It shouldn't be a matter of luck... > > ?As you say "allocate you", that implies ONE organization. > ?And ONE organization should only get ONE /22... ;-) > > ?Regards, > ?Carlos >> ??28.04.2015, 09:24, "Carlos Friacas" : >>> ??Hello, >>> >>> ??Noone (in the RIPE/NCC service region) is able to get more than a /22, >>> ??according to current policies, or did i miss something? >>> >>> ??If someone is asking (and actually getting) more than a /22, those >>> ??allocations need to be revoked -- i honestly thought current policy >>> ??already included that... >>> >>> ??Regards, >>> ??Carlos >>> >>> ??On Sat, 25 Apr 2015, Petr Umelov wrote: >>>> ???Hi everybody. >>>> >>>> ???Let me tell some words about current proposal. >>>> >>>> ???Many providers (among them is our company) need to get (e.g.) /20 subnet (not 4 x /22). If we ask the RIPE NCC to allocate 4 x /22, we can get next variants: >>>> ???1. /20 >>>> ???2. 2 x /21 from different subnets >>>> ???3. /22, /21, /22 >>>> >>>> ???There is only one chance to get /20 100% - make request for 7 x /22 (if the tickets will be processed together). But in this case we will have unwanted 3 x /22 which we can transfer to other LIRs to minimize our expenses. >>>> ???And also we can get different separate 4 x /22 (the worst case) and we have to transfer such blocks and make new request. >>>> >>>> ???If this proposal will be agreed, many providers (new and old) will have material losses. So I can't support this proposal. >>>> >>>> ???-- >>>> ???Kind regards, >>>> ???Techincal Director FastTelecom >>>> ???Petr Umelov >> ??-- >> ??With best regards, Vladimir Andreev >> ??General director, QuickSoft LLC >> ??Tel: +7 903 1750503 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From ghenry at suretecsystems.com Tue Apr 28 09:13:13 2015 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 28 Apr 2015 08:13:13 +0100 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1940291430203862@web20h.yandex.ru> References: <102641429977359@web18g.yandex.ru> <1815941430202538@web20h.yandex.ru> <1940291430203862@web20h.yandex.ru> Message-ID: Hi all, I'm not sure if this model has been mentioned in a RIPE meeting or via the list, but here in the UK, Ofcom (http://www.ofcom.org.uk/ telco regulator) allocates telephone numbers to communication providers. These are free and can be thought of kind of like IPv4. For the bigger cities you get 10k blocks, for the smaller cities you get a 1k block (think like a /22). Now there are 20+ cities that are running out of telephone numbers so in order to get more you have to present a business case, customer purchase order and also show your utilisation figures. For these 20+ cities you also get charged ?0.40 per number per year for any you hold. If you port them to a new company or the customer moves to another provider, this comes down to ?0.20. It is a weird system but does slow down the usage and forces others not using to return them. It doesn't solve the long term problem of them running out, but that is being solved by requiring the full area code being dialled not just the local part (will explain offlist if anyone is interested). I know big network operators would just pay a cost, but does any of above seem relevant to getting things returned to the pot? I know it doesn't solve them running out and similar things have been discussed, but I thought I'd mention it in case it stimulates any ideas. Thanks, Gavin. From ripe-wgs at radu-adrian.feurdean.net Tue Apr 28 10:51:21 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Tue, 28 Apr 2015 10:51:21 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <20150428075234.16d44154@echo.ms.redpill-linpro.com> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> Message-ID: <1430211081.3007387.259535301.2227D55A@webmail.messagingengine.com> On Tue, Apr 28, 2015, at 07:52, Tore Anderson wrote: > * -TOM- > > > This means, thatdealings with opening multiple LIR's, get their /22 > > allocation and merge this 'new lir's' with other 'host lir' is now in > > progress at full throttle :( > > Indeed, this person appears to be using the LIR merger procedure, *not* > the transfer procedure, to gather the /22s in his main LIR. At least I > could not find any of the blocks in question mentioned on > . Which probbaly means revising the text of 2015-01, and/or adding something similar to the merger procedure. Then again, some basic "needs checking" (checking that the requestor DOES NEED an allocation) would probably help too. From cfriacas at fccn.pt Tue Apr 28 11:25:23 2015 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 28 Apr 2015 10:25:23 +0100 (WEST) Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <1430211081.3007387.259535301.2227D55A@webmail.messagingengine.com> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <1430211081.3007387.259535301.2227D55A@webmail.messagingengine.com> Message-ID: On Tue, 28 Apr 2015, Radu-Adrian FEURDEAN wrote: > On Tue, Apr 28, 2015, at 07:52, Tore Anderson wrote: >> * -TOM- >> >>> This means, thatdealings with opening multiple LIR's, get their /22 >>> allocation and merge this 'new lir's' with other 'host lir' is now in >>> progress at full throttle :( >> >> Indeed, this person appears to be using the LIR merger procedure, *not* >> the transfer procedure, to gather the /22s in his main LIR. At least I >> could not find any of the blocks in question mentioned on >> . > > Which probbaly means revising the text of 2015-01, and/or adding > something similar to the merger procedure. > Then again, some basic "needs checking" (checking that the requestor > DOES NEED an allocation) would probably help too. "Need" shouldn't be a criteria anymore, as we're in "scarcity-mode"/"run-out" mode... One idea could be: ?If the LIR doesn't have any other IPv4 allocation made by the RIPE/NCC (before the run-out phase) besides the /22, if a merge process is needed, the /22 is automatically returned to the pool?. Cheers, Carlos From tore at fud.no Tue Apr 28 11:29:57 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 28 Apr 2015 11:29:57 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <1430211081.3007387.259535301.2227D55A@webmail.messagingengine.com> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <1430211081.3007387.259535301.2227D55A@webmail.messagingengine.com> Message-ID: <20150428112957.42509d6a@echo.ms.redpill-linpro.com> * "Radu-Adrian FEURDEAN" > On Tue, Apr 28, 2015, at 07:52, Tore Anderson wrote: > > * -TOM- > > > > > This means, thatdealings with opening multiple LIR's, get their /22 > > > allocation and merge this 'new lir's' with other 'host lir' is > > > now in progress at full throttle :( > > > > Indeed, this person appears to be using the LIR merger procedure, > > *not* the transfer procedure, to gather the /22s in his main LIR. > > At least I could not find any of the blocks in question mentioned on > > . > > Which probbaly means revising the text of 2015-01, and/or adding > something similar to the merger procedure. > Then again, some basic "needs checking" (checking that the requestor > DOES NEED an allocation) would probably help too. The thing is, since /22 is the minimum allocation size, the requestor only has to need a single - 1 - IPv4 address in order to "need enough" to get a /22. That's the way it has always been - the so-called ?no need? proposal didn't really change this; current policy does still require that the requestor intends to make at least 1 assignment from the allocation, and an "assignment" is defined as something that goes into an operational network. Anyway. I think that an LIR is willing to game the policy by creating multiple LIRs and only to merge them, creating this minimum level of "need" for oneself is trivial to do as well. So I'd be very wary of creating policies that are ineffectual at actually preventing the abuse they seek to, while at the same time create pointless overhead and extra paperwork for the vast majority of non-abusive members of the community. Tore From ck-lists at cksoft.de Tue Apr 28 11:30:50 2015 From: ck-lists at cksoft.de (Christian Kratzer) Date: Tue, 28 Apr 2015 11:30:50 +0200 (CEST) Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <1430211081.3007387.259535301.2227D55A@webmail.messagingengine.com> Message-ID: Hi, On Tue, 28 Apr 2015, Carlos Friacas wrote: > "Need" shouldn't be a criteria anymore, as we're in "scarcity-mode"/"run-out" > mode... yes exactly. > One idea could be: ?If the LIR doesn't have any other IPv4 allocation made by > the RIPE/NCC (before the run-out phase) besides the /22, if a merge process > is needed, the /22 is automatically returned to the pool?. Defining a policy to stop hoarding while allowing legit. usage is the hard part. Even if you insist that you want to see the prefix in the global routing table and want pingable targets brokers will full any of those requirements with ease. There is propably no way to stop hoarding without also hurting legitimate business. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck at cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From ripe-wgs at radu-adrian.feurdean.net Tue Apr 28 11:39:18 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Tue, 28 Apr 2015 11:39:18 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <1430211081.3007387.259535301.2227D55A@webmail.messagingengine.com> Message-ID: <1430213958.3017949.259548357.6A8E8A90@webmail.messagingengine.com> On Tue, Apr 28, 2015, at 11:25, Carlos Friacas wrote: > "Need" shouldn't be a criteria anymore, as we're in > "scarcity-mode"/"run-out" mode... "Need" should be a criteria again, exactly because we're in run-out mode. Again, "need" starts and ends with "if needed", *withOUT* the "as much as you need" part. > One idea could be: ?If the LIR doesn't have any other IPv4 allocation > made by the RIPE/NCC (before the run-out phase) besides the /22, if a > merge process is needed, the /22 is automatically returned to the pool?. One pretty BAD idea. Not only the small players have a difficult time, but if some of them merge together, this makes sure they stay small. Renumbering is generally delicate for acess customers, and goes to very difficult (adminstratively and process-wise), sometimes limit impossible to running server and services plafroms. The idea is to prevent address hoarding in the first place, not to impose insane limitations on already running things. From cfriacas at fccn.pt Tue Apr 28 12:05:57 2015 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 28 Apr 2015 11:05:57 +0100 (WEST) Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <1430213958.3017949.259548357.6A8E8A90@webmail.messagingengine.com> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <1430211081.3007387.259535301.2227D55A@webmail.messagingengine.com> <1430213958.3017949.259548357.6A8E8A90@webmail.messagingengine.com> Message-ID: On Tue, 28 Apr 2015, Radu-Adrian FEURDEAN wrote: Hi, > On Tue, Apr 28, 2015, at 11:25, Carlos Friacas wrote: >> "Need" shouldn't be a criteria anymore, as we're in >> "scarcity-mode"/"run-out" mode... > > "Need" should be a criteria again, exactly because we're in run-out > mode. > Again, "need" starts and ends with "if needed", *withOUT* the "as much > as you need" part. We agree to disagree :-) >> One idea could be: ?If the LIR doesn't have any other IPv4 allocation >> made by the RIPE/NCC (before the run-out phase) besides the /22, if a >> merge process is needed, the /22 is automatically returned to the pool?. > > One pretty BAD idea. Not only the small players have a difficult time, > but if some of them merge together, this makes sure they stay small. They would need to remain a LIR in order to keep its /22. What i don't like is the ability for someone to create a new LIR knowing it will be decommissioned later, because the only intent is to "catch" a /22. > Renumbering is generally delicate for acess customers, and goes to very > difficult (adminstratively and process-wise), sometimes limit impossible > to running server and services plafroms. Yes, if one organization feels it needs to run away from renumbering, the solution is to become a LIR and get/use its own /22. It will have to do it once, but it will be the last time, provided they always keep their LIR up & running. > The idea is to prevent address hoarding in the first place, not to > impose insane limitations on already running things. Shouldn't be a problem if the LIR wasn't created with the original intent of closing it down after some time... Cheers, Carlos From apwg at c4inet.net Tue Apr 28 12:15:33 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 28 Apr 2015 11:15:33 +0100 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <20150428090555.4f8db6b6@echo.ms.redpill-linpro.com> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <20150428090555.4f8db6b6@echo.ms.redpill-linpro.com> Message-ID: <20150428101533.GC35191@cilantro.c4inet.net> On Tue, Apr 28, 2015 at 09:05:55AM +0200, Tore Anderson wrote: >* Mikael Abrahamsson > >> But 2015-01 at least says you need to keep the LIR open for 24 months, >> correct, meaning you have to pay the yearly LIR fee 3 times (one initial >> and 2 recurring). At least that was my understanding of the proposal. > >Yes, but it only does this for "normal" transfers per ripe-643 section 5.5. > >It does not change anything for ??Mergers and Acquisitions??, because >that's not regulated in policy, it is an operational procedure made by >the RIPE NCC. So it appears I was in error assuming that this proposal affects M&A - I partially blame ripe-628 in being confusing and mixing transfers due to M&A and s5.5 transfers in the same doc. I note though that s3.3 of ripe-628 mandates that the full membership fee for the transferring member in the year the transfer takes place in must be paid by the receiving member. This proposal would, at best, add another year's fee to the cost. >I'm hoping that the NCC's IA will point out that the M&A loophole >remains and maybe advise on how we might go about closing it. Given the above and the not inconsiderable paperwork, I can't but think that this really is an edge case. I can't think of any way of closing this without regulating into members' business decisions, maybe someone else can... rgds, Sascha Luck From apwg at c4inet.net Tue Apr 28 12:21:15 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 28 Apr 2015 11:21:15 +0100 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <1430211081.3007387.259535301.2227D55A@webmail.messagingengine.com> <1430213958.3017949.259548357.6A8E8A90@webmail.messagingengine.com> Message-ID: <20150428102115.GD35191@cilantro.c4inet.net> On Tue, Apr 28, 2015 at 11:05:57AM +0100, Carlos Friacas wrote: >What i don't like is the ability for someone to create a new LIR >knowing it will be decommissioned later, because the only intent is to >"catch" a /22. You can't prove this intent and creating a company with the expectation that it will be bought by someone else is a perfectly legitimate business model. rgds, Sascha Luck From Piotr.Strzyzewski at polsl.pl Tue Apr 28 12:14:40 2015 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Tue, 28 Apr 2015 12:14:40 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <1430211081.3007387.259535301.2227D55A@webmail.messagingengine.com> <1430213958.3017949.259548357.6A8E8A90@webmail.messagingengine.com> Message-ID: <20150428101440.GH7900@hydra.ck.polsl.pl> On Tue, Apr 28, 2015 at 11:05:57AM +0100, Carlos Friacas wrote: Hi > What i don't like is the ability for someone to create a new LIR knowing it > will be decommissioned later, because the only intent is to "catch" a /22. And this is nothing new. Some time ago, during the AP-WG meeting in Tallinn, ICANN representative suggested the same for me. The only intent behind that was to "catch" another v6 /32. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From woeber at cc.univie.ac.at Tue Apr 28 13:00:57 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Tue, 28 Apr 2015 13:00:57 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <1430211081.3007387.259535301.2227D55A@webmail.messagingengine.com> Message-ID: <553F6869.1030902@cc.univie.ac.at> On 2015-04-28 11:30, Christian Kratzer wrote: [...] > Even if you insist that you want to see the prefix in the global routing table "We" may *want* to see it in the global routing table, but like with all the other prefixes, there's no good reasoning for that expectation. TCP/IP is a technology and that technology is *not* exclusively used for the global Internet. We had that "wish" and discussion in the past (e.g. in the AS# application and PI-"need".) It never worked, neither technically nor admin-wise. That's a non-starter... Wilfried. > and want pingable targets brokers will full any of those requirements with ease. > > There is propably no way to stop hoarding without also hurting legitimate business. > > Greetings > Christian > From mschmidt at ripe.net Tue Apr 28 14:00:40 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 28 Apr 2015 14:00:40 +0200 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) Message-ID: Dear colleagues, A proposed change to the RIPE Document "IPv6 Address Allocation and Assignment Policy" now is open for discussion. The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-03 We encourage you to review this proposal and send your comments to before 27 May 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC From cfriacas at fccn.pt Tue Apr 28 14:09:17 2015 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 28 Apr 2015 13:09:17 +0100 (WEST) Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: <1940291430203862@web20h.yandex.ru> References: <102641429977359@web18g.yandex.ru> <1815941430202538@web20h.yandex.ru> <1940291430203862@web20h.yandex.ru> Message-ID: On Tue, 28 Apr 2015, Vladimir Andreev wrote: > I already expressed my opinion about multiple LIR's in details in previous letters. > > "Allocate you" means "you" as contact person. You are not required to have only one organisation. > You can open some amount of legal person and then open LIR's for each. After that request /22's for your LIR's as mentioned earlier. I don't see a problem in one person managing multiple LIRs. Really, i understand that managing LIRs for 3rd parties can be a service. A big company can own dozens of other small companies and get a /22 from each of them -- but it shouldn't. In the case it wants to merge, it should return all the /22s to the NCC pool except one. If the "well-known workaround" can't be fixed (and wrong-doings reverted) then the policy is useless. ps: I've always been a strong supporter of v6 deployment, but i never agreed with the idea that we should run-out v4 aggressively. Regards, Carlos From aleheux at kobo.com Tue Apr 28 14:02:36 2015 From: aleheux at kobo.com (Alex Le Heux) Date: Tue, 28 Apr 2015 12:02:36 +0000 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <20150428075234.16d44154@echo.ms.redpill-linpro.com> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> Message-ID: On 2015-04-28, 07:52 , "Tore Anderson" wrote: >* -TOM- > >> This means, thatdealings with opening multiple LIR's, get their /22 >> allocation and merge this 'new lir's' with other 'host lir' is now in >> progress at full throttle :( > >Indeed, this person appears to be using the LIR merger procedure, *not* >the transfer procedure, to gather the /22s in his main LIR. At least I >could not find any of the blocks in question mentioned on >pv4-transfers/table-of-transfers>. > >That in turn means that 2015-01 will have no preventive effect at all. It does mean that the RIPE NCC can make changes to the LIR merger procedure to fix this abuse without having to go through the PDP... Alternatively, members could petition the RIPE NCC board to raise the New LIR sign-up fee to 10 or 15 times the current level. That should stop this in its tracks as well and would still not be a huge barrier to new entrants. Alex From james.blessing at despres.co.uk Tue Apr 28 14:19:56 2015 From: james.blessing at despres.co.uk (James Blessing) Date: Tue, 28 Apr 2015 13:19:56 +0100 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: On 28 April 2015 at 13:00, Marco Schmidt wrote: > > > The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. > https://www.ripe.net/participate/policies/proposals/2015-03 Support at current stage - may change after seeing IA J -- James Blessing 07989 039 476 From apwg at c4inet.net Tue Apr 28 14:36:36 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 28 Apr 2015 13:36:36 +0100 Subject: [address-policy-wg] Transfer Requirements for IPv4 Allocations In-Reply-To: References: <102641429977359@web18g.yandex.ru> <1815941430202538@web20h.yandex.ru> <1940291430203862@web20h.yandex.ru> Message-ID: <20150428123636.GE35191@cilantro.c4inet.net> On Tue, Apr 28, 2015 at 01:09:17PM +0100, Carlos Friacas wrote: >A big company can own dozens of other small companies and get a /22 >from each of them -- but it shouldn't. In the case it wants to merge, >it should return all the /22s to the NCC pool except one. 1) Again, this can be a perfectly legitimate business case. 2) A holding company can own many subsidiaries and there is no (and neither should there be a) requirement to even inform the NCC of this fact as long as no merging of LIRs is required. 3) a requirement to return all but one /22 in case of a merger is unrealistic and would mean an infringement on, again perfectly legitimate, business transactions between LIRs. 4) Since the M&A procedure is not a matter of address policy, this is the wrong place to debate it anyway. rgds, Sascha Luck From niels=apwg at bakker.net Tue Apr 28 14:41:43 2015 From: niels=apwg at bakker.net (niels=apwg at bakker.net) Date: Tue, 28 Apr 2015 14:41:43 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> Message-ID: <20150428124143.GA68351@excession.tpb.net> * ggiannou at gmail.com (George Giannousopoulos) [Tue 28 Apr 2015, 08:28 CEST]: >Remember that for every single /22 you get by abusing the policy, you >prohibit a new company to start business in the near future, since the >required /22 won't be available any more. I believe this argument was dismissed in the previous threadby one of the perpetrators as tragedy of the commons. -- Niels. From apwg at c4inet.net Tue Apr 28 14:58:37 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 28 Apr 2015 13:58:37 +0100 Subject: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: <20150428125837.GF35191@cilantro.c4inet.net> On Tue, Apr 28, 2015 at 02:00:40PM +0200, Marco Schmidt wrote: >The proposal aims to expand the criteria for evaluating initial >IPv6 allocations larger than a /29. The RIPE NCC would consider >additional aspects beyond only the number of existing users and >extent of the organisation's infrastructure. 1) I've some issues with the language of the proposal, namely the idea of "mitigating wastefulness" by prescribing or proscribing certain concepts and practices either by the NCC or the community. I believe that everyone runs their own network at the end of the day and neither the NCC, the membership nor the apwg community are qualified to judge individual members' network design decisions. 2) There is some issue with transparency if the text is removed as proposed insofar as there is, then, no guidance whatsoever on how an alloc request >/29 is judged. Perhaps this can be addressed in the NCC Impact Statement. 3) I'm inclined to support this proposal, however, if these issues are addressed. rgds, Sascha Luck rgds, Sascha Luck From serek at walcz.net Tue Apr 28 16:15:02 2015 From: serek at walcz.net (Sergiusz Paprzycki) Date: Tue, 28 Apr 2015 15:15:02 +0100 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> Message-ID: <553F95E6.9060006@walcz.net> On 28/04/15 13:02, Alex Le Heux wrote: > Alternatively, members could petition the RIPE NCC board to raise the New > LIR sign-up fee to 10 or 15 times the current level. That should stop this > in its tracks as well and would still not be a huge barrier to new > entrants. Hi Alex, Is this really a solution??? I am quite convinced that this will also stop _a lot_ of legitimate companies from becoming LIRs.. RIPE region covers area with very different economical landscapes. ?20,000 (or even ?30,000) is not a small sum for a start-up in the "rich" side of the region, at the same time it is very prohibitive sum not only for start-up on the "not so rich" side. Just my 2c. -- Sergiusz Paprzycki From ripe at opteamax.de Tue Apr 28 19:37:50 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Tue, 28 Apr 2015 19:37:50 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <553F95E6.9060006@walcz.net> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <553F95E6.9060006@walcz.net> Message-ID: <553FC56E.3080204@opteamax.de> On 28.04.2015 16:15, Sergiusz Paprzycki wrote: > On 28/04/15 13:02, Alex Le Heux wrote: >> Alternatively, members could petition the RIPE NCC board to raise the New >> LIR sign-up fee to 10 or 15 times the current level. That should stop >> this >> in its tracks as well and would still not be a huge barrier to new >> entrants. > > Hi Alex, > > Is this really a solution??? I am quite convinced that this will also > stop _a lot_ of legitimate companies from becoming LIRs.. RIPE region > covers area with very different economical landscapes. ?20,000 (or even > ?30,000) is not a small sum for a start-up in the "rich" side of the > region, at the same time it is very prohibitive sum not only for > start-up on the "not so rich" side. > I fully agree with Sergiusz... I think the policy should maybe be adjusted in a way that the only legitimate reason for taking over IP-space is taking over existing customers and continue the service which is running on the IP-Space. The normal procedure of closing a LIR must be withdrawing all resources assigned to that LIR and only if you can present good arguments why a renumbering of customers is not possible, you might keep the address-space. I mean, I also needed to renumber my about 2000 used IPv6-PI addresses when I became LIR as I had to return the IPv6-PI (I know, now there's a proposal on the way to stop that for V6, but that's different thing). -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From ak at list.ak.cx Tue Apr 28 19:50:09 2015 From: ak at list.ak.cx (Andre Keller) Date: Tue, 28 Apr 2015 19:50:09 +0200 Subject: [address-policy-wg] Hoarding /22 out of 185/8 In-Reply-To: <553FC56E.3080204@opteamax.de> References: <553EF9E6.8020907@init7.net> <1146891946.20150428081321@infinitytelecom.ro> <553F1ACB.6090201@kebab.org.pl> <20150428075234.16d44154@echo.ms.redpill-linpro.com> <553F95E6.9060006@walcz.net> <553FC56E.3080204@opteamax.de> Message-ID: <553FC851.9030905@list.ak.cx> Hi Jens, On 28.04.2015 19:37, Opteamax GmbH wrote: > I fully agree with Sergiusz... I think the policy should maybe be > adjusted in a way that the only legitimate reason for taking over > IP-space is taking over existing customers and continue the service > which is running on the IP-Space. I was involved in a few mergers and we were always asked to provide documentation. To quote my conversation with the customer service: > Please also submit the following documents: > > - an agreement between both companies proving that the network was > taken over by ... In our case (which did not involve networks from the last /8) we were taking over the whole infrastructure from a datacenter site of the former LIR, but did not have an agreement that specifically said so. So we made an additional agreement to fulfill the RIPE NCCs request. So do you really think it is hard to provide such documentation, even if you did not really take over some equipment and/or customers? > The normal procedure of closing a LIR must be withdrawing all resources > assigned to that LIR and only if you can present good arguments why a > renumbering of customers is not possible, you might keep the > address-space. People who *want* to abuse the system, will just come up with bullshit documentation. How do you propose RIPE NCC does validate if they really need the IPs? Based on what information? Regards Andr?